Redp 4993

Front cover
Discovering the Decisions

within Your Business Processes
using IBM Blueworks Live
Uncover the decisions within your

business processes
Learn to use IBM Blueworks Live to

discover and document decisions
Leverage decisions to create

smarter business processes
Margaret Thorpe
Juliana Holm
Genevieve van den Boer
ibm.com/redbooks Redpaper
International Technical Support Organization
Discovering the Decisions within Your Business

Processes using IBM Blueworks Live
January 2014
REDP-4993-00
Note: Before using this information and the product it supports, read the information in Notices on page v.
First Edition (January 2014)
This edition applies to IBM Blueworks Live, an IBM Software-as-a-Service (SaaS) offering, accessible at
https://www.blueworkslive.com
This document was created or updated on January 29, 2014.
Copyright International Business Machines Corporation 2014. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Chapter 1. Introduction to decision discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Operational decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Decision discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 The anatomy of a decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Decisions and business processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Relationship between decisions and business processes . . . . . . . . . . . . . . . . . . . 6
1.2.2 Benefits of documenting the decisions within your business processes. . . . . . . . . 7
1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapter 2. Introduction to IBM Blueworks Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Collaborative platform for discovering and documenting business processes . . . . . . . 10
2.2 Decision discovery with Blueworks Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Decisions within business processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Capturing key decision characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Composing a decision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Viewing a decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 Collaborating on decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.6 Validating decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.7 Tracking changes to decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.8 Finding and sharing decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 3. Getting started with decision discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Start with the business process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1 Review of key process elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Identify the decision points in the business process . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Consider the business goals and pain points . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Closely examine gateways, activities, milestones, and participant hand-offs . . . . 26
3.2.3 Review related processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Identify and prioritize decisions for further discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Document high-level decision characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 The importance of the subject matter expert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Model the decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Capture the fundamentals of the decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 Identify the information required to make the decision . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Identify any required sub-decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4 Document the decision logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5 Modeling decisions for understanding, validation, and communication . . . . . . . . 36
3.5 Validate the decision and establish any necessary governance practices . . . . . . . . . . 37
Copyright IBM Corp. 2014. All rights reserved. iii

3.5.1 Decision validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2 Decision governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 4. Bringing it all together: The AIC decision discovery project . . . . . . . . . . . 41

4.1 Introducing An Insurance Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Step 1: Starting with the business process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Step 2: Identifying the decision points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Look at the gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Look at the activity names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3 Look at the milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.4 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Step 3: Identify and prioritize decisions for further discovery . . . . . . . . . . . . . . . . . . . . 51
4.4.1 Compose a decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.2 Capturing key decision characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Business metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4.4 Decision change dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.5 Preparing for in-depth decision discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.6 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Step 4: Model the decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.1 Capturing the fundamentals of the decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.2 Documenting the decision inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5.3 Documenting the decision logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.5.4 Reviewing the decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.6 Step 5: Validate the decision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.6.1 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.6.2 Revising and refactoring decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.6.3 Versioning decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.6.4 Sharing decision information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.6.5 Formal validation of decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.6.6 Next steps at AIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Appendix A. Automation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Operational Decision Management and Business Process Management . . . . . . . . . . . . . 122
Decision automation: Some considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Identifying candidates for automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Decision management technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Transition from decision discovery to automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Process improvement and automation: Some considerations . . . . . . . . . . . . . . . . . . . . . . 129
Identifying candidates for automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Business Process Management technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Service-oriented architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Transition from process discovery to automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

IBM Blueworks Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Decision Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Decision Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Business Process Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
iv Discovering the Decisions within Your Business Processes using IBM Blueworks Live
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 grant 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 websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites 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.
Any performance data contained herein was determined in a controlled environment. Therefore, the results
obtained in other operating environments may vary significantly. Some measurements may have been made
on development-level systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
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.
Copyright IBM Corp. 2014. All rights reserved. v

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:
Blueworks Live Redbooks WebSphere
IBM Redpaper
ILOG Redbooks (logo)
The following terms are trademarks of other companies:
Adobe, the Adobe logo, and the PostScript logo are either registered trademarks or trademarks of Adobe
Systems Incorporated in the United States, and/or other countries.
Microsoft, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates.
Other company, product, or service names may be trademarks or service marks of others.
vi Discovering the Decisions within Your Business Processes using IBM Blueworks Live
Preface
In todays competitive, always-on global marketplace, businesses need to be able to make

better decisions more quickly. And they need to be able to change those decisions
immediately in order to adapt to this increasingly dynamic business environment. Whether it
is a regulatory change in your industry, a new product introduction by a competitor that your
organization needs to react to, or a new market opportunity that you want to quickly capture
by changing your product pricing. Decisions like these lie at the heart of your organizations
key business processes.
In this IBM Redpaper publication, we explore the benefits of identifying and documenting
decisions within the context of your business processes. We describe a straightforward
approach for doing this by using a business process and decision discovery tool called
IBM Blueworks Live, and we apply these techniques to a fictitious example from the auto
insurance industry to help you better understand the concepts.
This paper was written with a non-technical audience in mind. It is intended to help business
users, subject matter experts, business analysts, and business managers get started
discovering and documenting the decisions that are key to their companys business
operations.
Authors
This paper was produced by a team of specialists from around the world working at the IBM
International Technical Support Organization (ITSO), Austin Center.
Margaret Thorpe is a Product Manager for IBM Blueworks Live. She has over 25 years of
experience in the software industry, and has been working on Business Rule and Decision
Management systems since the early 1990s. As Director, and later Vice President of Product
Management at IBM ILOG, she was instrumental in establishing ILOG JRules as the
market-leading Business Rule Management Systems (BRMSs). With the acquisition of ILOG
in 2009, Margaret joined IBM, contributing to the evolution of what is now the IBM
Operational Decision Manager product. She is currently working on software for business
process and decision modeling in the IBM Smarter Process product portfolio.
Juliana Holm has been working in decision management and expert systems since 1992.
She has worked with frame-based, cased-based and, since 1997, rule-based reasoning.
Juliana began work as a Business Policy Analyst for ILOG in 2006, and continued to work
with JRules and ODM after ILOG was acquired by IBM. In addition to her technical
experience, she has done extensive technical writing, including developing training materials
for a number of employers, including IBM. Juliana has also been a trainer, including business
analyst training on JRules 7. She is a certified developer for JRules 6 and 7, and an IBM ODM
consultant and project manager.
Genevieve Van Den Broer is a BPM Consultant for IBM Canada. With over 20 years of
experience in the software industry, she has spent the past nine years working with BPM
technology and defining practices and methodology. She holds a degree in Applied Science
from the University of British Columbia at Vancouver. Her areas of expertise include BPM
discovery, analysis and design, as well as business performance monitoring and
management.
Copyright IBM Corp. 2014. All rights reserved. vii

Thanks to the following people for their contributions to this project:
Chris Walk, former IBM Blueworks Live Product Management

Damon Lundin, IBM Blueworks Live Lead Developer
Sharan Patel, IBM Blueworks Live QA Lead
Axel Buecker, IBM ITSO Project Manager
Now you can become a published author, too!

Heres an opportunity to spotlight your skills, grow your career, and become a published
authorall at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
Find out more about the residency program, browse the residency index, and apply online at:
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 email 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
Stay connected to IBM Redbooks

Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on Twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
viii Discovering the Decisions within Your Business Processes using IBM Blueworks Live
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Preface ix
x Discovering the Decisions within Your Business Processes using IBM Blueworks Live
1
Chapter 1. Introduction to decision

discovery
In todays competitive, always-on global marketplace, organizations need to be able to make
better decisions more quickly. And they need to be able to change those decisions
immediately in order to adapt to this increasingly dynamic business environment. Whether it
is a regulatory change in your industry, a new product introduction by a competitor that you
need to react to, or a new market opportunity that you want to quickly capture by changing
your product pricing. Decisions like these lie at the heart of your key business processes. And
the ability to automate these decisions can give organizations the ability to do this at scale,
gaining a competitive edge. Business Rule Management Systems (BRMSs) and Decision
Management platforms have typically been the technology of choice for decision automation.
Now decisions are becoming increasingly important in Business Process Automation, as well
as, the value of smarter processes becomes more widely understood.
In this Redpaper publication, we explore the benefits of identifying and documenting

decisions within the context of your business processes. We describe a straightforward
approach for doing this by using a business process and decision discovery tool called
IBM Blueworks Live, and we apply these techniques to a fictitious example from the auto
insurance industry to help you better understand the concepts. In the Appendixes, we briefly
explain the topic of automation if you are interested in how you can go about automating
decisions once they have been documented. Although it is our intention to enable you to get
started immediately discovering and documenting the decisions within your business
processes, we have also provided links to additional resources at the end if you want to gain a
broader and deeper understanding of this subject.
This paper was written with a non-technical audience in mind, which is a little unusual for an
IBM Redpaper publication. It is intended to help business users, subject matter experts,
business analysts, and business managers begin to discover and document the key decisions
within their business processes using IBM Blueworks Live. However, the paper should also
prove informative for IT readers looking for a quick introduction to the topic. For a deeper dive
into some of the more technical aspects of decision modeling and implementation, there are a
number of excellent resources referenced at the end of the paper for you to explore.
So let us get started.
Copyright IBM Corp. 2014. All rights reserved. 1

1.1 Decisions
Decisions are foundational assets in most business operations. Decision discovery is the
process of identifying and documenting the key business decisions within an organization. In
this chapter, we introduce decisions and decision discovery and explore the relationship
between decisions and business processes.
1.1.1 Operational decisions

Decisions are everywhere. They are made constantly in organizations both large and small.
Regardless of whether they belong to the private, public, or non-profit sector, the success of
an organization depends on the quality of its decisions. There are many different types of
decisions. Some decisions are more strategic in nature and while they may have a significant
impact on the business, they are made relatively infrequently. These strategic decisions are
usually one-offs that require intensive data analysis, human interaction, judgment, and
expertise, and sometimes intuition. For example, the decision by a manufacturing company to
build a new distribution center at a particular location can have a huge impact on lead times,
fulfillment of orders, customer satisfaction, and other key business objectives. But it is not a
decision that is made very often, and when it is, it likely involves a lot of analysis and
discussion at high levels of the organization in order to reach a decision. Or take the example
of the decision by a mortgage lender to introduce a new, innovative loan product to the
marketplace. This decision could also have a major impact on the success of the company by
enabling them to capture a new segment of the market, increase revenue and profitability, and
reduce risk exposure. But, once again, this decision is made relatively infrequently and likely
involves human creativity, intensive collaboration, and much analysis before a go or no-go
decision is reached.
Operational decisions, however, tend to be more tactical and focused. They have a limited
scope, but are repeatable and are often made quite frequently. The decision by an auto
insurance company to pay or reject a particular claim is a good example of this. The decision
by an online retailer to offer a special discount to a particular customer for a specific product is
another good example. They are called operational decisions because they are critical to the
effective operation of an organization. It is often the quality and timeliness of these
operational decisions that determines whether an organization meets its business objectives
or not. Because operational decisions are often made very frequently, the benefits can really
add up when they are of a high quality, even though the value of each individual decision may
be relatively small. For example, assessing whether or not a credit card purchase might be
fraudulent may not have much of an impact when we are considering a single $23.29 gas
purchase transaction. But when we are evaluating hundreds of thousands of transactions a
day, the impact to a company's bottom line can be substantial!
1.1.2 Decision discovery

Decision discovery is the process of identifying and documenting the key business decisions
that are made regularly within a given business. The first step on the decision discovery
journey is to understand the decisions that are currently being made within an organization.
Often this knowledge is hidden in an expert's head, in existing code, and in corporate
documents, which is why it must be discovered. By extracting it and documenting it, you can
gain insight into what is driving your key business operations. Only then can you begin to
analyze, improve, and potentially automate some or all of these decisions as shown in
Figure 1-1 on page 3.
2 Discovering the Decisions within Your Business Processes using IBM Blueworks Live
Business User Subject-matter Business Analyst IT Architect Developer System Admin Business User Subject-matter
expert expert
Discover Model Refine

R fi & Automate
A Manage
M
Governance
Figure 1-1 Decision discovery through automation
When identifying the key business decisions being made within your organization, it is helpful
to think of them as answers to important business questions. Is this applicant eligible for
automobile insurance? What annual premium should we charge this applicant for this policy?
Is this vehicle eligible for coverage? Certain keywords can tip you off to the potential presence
of a decision. Phrases that use verbs like assess, determine, evaluate, identify, validate,
analyze, establish, diagnose, select, choose, calculate, and others like this may indicate
candidate decisions. These same phrases can be used effectively to name your decisions
when documenting them: Assess Applicant Eligibility, Calculate Premium, Determine Vehicle
Eligibility.
Once you have identified a decision worth documenting, there are a number of key pieces of
information about the decision that are best captured early on. These are a few of them:
What is the business motivation behind this decision?
Document the key business objectives that the decision seeks to achieve. This can be
very helpful when assessing which decisions to tackle first in a discovery initiative. If the
documented business objectives have a significant impact on the overall project goals, the
decision may be a high priority for further discovery.
Who are the subject matter experts?
Capture the names and titles of the people that have knowledge of this business decision.
These people will likely prove indispensable during the discovery process. And, in some
cases, the existence of experts may influence your discovery plan. For example, the lack
of experts may be reason not to tackle a particular decision until later in the project, when
the team has more experience with the process. Or, the planned retirement of experts may
motivate an entire project to document the decisions that those experts have knowledge of
so that it can be retained after their departure.
Are there definitive sources of knowledge for this decision?
Capture any regulatory guides, corporate documents, work aids, and other authoritative
documents describing the decision. These documents may become very important during
the discovery process.
What are the key performance indicators (KPIs)?
Document any business metrics that are used to assess the quality and outcome of this
decision. These will likely be related to the business motivation captured earlier. KPIs will
be necessary to measure any resulting improvements to the business operations and to
analyze the effectiveness of this decision in relation to specific business objectives.
Is this decision made frequently?
High-volume decisions may be good candidates for automation using Decision
Management technology because the potential for significant ROI exists.
Chapter 1. Introduction to decision discovery 3

Does the decision logic change frequently?
Capture the change dynamics of the decision. Decisions that must be changed frequently
or quickly are often good candidates for automation using Decision Management
technology.
Once this high-level information has been documented for the key decisions in the business
area of focus, the decision discovery team will be able to evaluate and prioritize their efforts.
Then they can get to work documenting the details of each of the decisions that have been
selected for discovery.
1.1.3 The anatomy of a decision

What exactly is a decision? For the purposes of this paper, a decision is the act of determining
a wanted business outcome by applying specialized business knowledge to relevant
information. A decision consists of the following factors:
The decision output: The conclusion reached, the option selected
Any number of decision inputs: The facts to be considered
The decision logic: Describes how the conclusion is reached, based on these facts.
Decision logic is usually expressed using decision tables, business rules, analytic models,
or other such formalisms as shown in Figure 1-2.
Figure 1-2 Structure of a simple decision
If you are new to decision discovery, you may occasionally come across the term business
rules and wonder how these relate to decisions. A business rule is a rule that defines or
constrains the structure or operations of a business. Business rules are often expressed as
if-then statements. When a group of business rules is used together to determine a single
outcome, they are typically organized into decision tables. Decision tables are a very
compact, effective, and intuitive means of documenting and understanding decision logic.
When business rules are organized this way, we refer to them as decision rules. Each row in a
decision table is essentially a decision rule. For example, Figure 1-3 on page 5 shows the
decision logic for the Validate Offer Compliance decision, which determines whether or not
the salary proposed for offer to a potential new hire is compliant with corporate salary
guidelines. Each row in the decision table is a decision rule.
Figure 1-3 Example of a decision rule
You may also see business rules used together to enforce business policies across a set of
business processes. Unlike decision rules, these enforcement rules do not together
determine a single outcome. Rather, they typically express a constraint or requirement on
some element of the business. For example, an auto rental company might have a business
policy in place which states that Depreciation of rental cars must be minimized. In order to
enforce this policy, there may be a number of business rules that will need to be applied at
different points in the car rental company's business processes. For example:
When a rental car is being assigned to a customer, this business rule should be applied:
The assigned rental car should be the available car with the lowest mileage in the
requested car group.
When a customer requests an extension to their rental by phone, this business rule should
be applied: A rental cannot be extended by phone if the car is within 500 miles of its next
service mileage.
In this paper, you learn to use decision rules in the form of decision tables to document your
decision logic because this is the easiest way to get started discovering and documenting
decisions. Once you have become comfortable working with basic decision rules, you may
want to explore additional techniques for describing other sorts of business rules and decision
logic. There are some additional resources referenced at the end of this paper that will help
you, should you decide to delve more deeply into these topics.
1.2 Decisions and business processes

Because decisions and processes are complementary and often tightly intertwined, it is
important to understand a bit about your business processes before you begin to discover
and document your decisions.

1.2.1 Relationship between decisions and business processes
To understand how decisions and processes relate to each other, let us begin by reviewing
some basic definitions:
What is a business process?
A business process represents the sequence of activities taken by various participants

to repeatedly achieve a business goal.
A process does not represent the steps taken to perform a task once, such as a project. A
process occurs over time, and may involve a number of participants. The process
definition may include a number of milestones indicating phases, or stages, within the
process. While there may be some tasks within a process that occur in parallel, a process
is fundamentally understood and envisioned as a sequence of activities over time.
What is a decision?
A decision is a conclusion reached in response to a set of facts.
Decisions generally occur at a specific point in time, at which point the facts are gathered
and a conclusion is drawn from them. Sometimes decisions appear to occur over time, but
it is not really that the decision logic is being applied over time; rather it is the facts that are
gathered over time. The final decision is made once all of the facts have been gathered.
There are also occasionally decisions in which sub-decisions have to occur in a particular
order, which would seem to imply that they occur over time. However, even in these cases,
decisions are fundamentally understood and described as conclusions reached at a point
of time in response to a set of facts.
What is a decision point?
A decision point is a place within a business process where a decision is made.
Most processes contain decisions. For example, in a process to issue an insurance policy,
there will be points in the process where a determination will need to be made as to
whether to go ahead and issue the policy, or whether to deny the coverage to the
applicant. Each of these points in the process is a place where some form of decision is
made; it is a decision point, as shown in Figure 1-4 on page 7.
Figure 1-4 Decision points within a process
Most operational decisions take place within some form of business process. These decisions
usually require that some form of information be provided as input to the decision. These
inputs are typically prepared by defined steps in a process prior to the decision point.
Decisions produce some form of output. The information that is the output of a decision may
be used by the process to determine whether to continue the process flow. An example of this
type of output would be the decision whether to accept or reject an applicant. A decision to
accept would indicate that the process flow should continue with the application. The output
of a decision can also be the information that is required by steps defined in the process
following the decision point. For example, a decision may be used to calculate a price for a
policy. This price could then be used by steps later in the process to define a contract for the
insurance policy.
1.2.2 Benefits of documenting the decisions within your business processes

Even when automation is not the goal, discovering and documenting decisions during
process discovery can result in a number of benefits:
Clearer, more accurate understanding of the business process
Most business processes make decisions. Documenting these decisions explicitly leads to
a better understanding of how a process is actually being carried out within an
organization or system. Highlighting these decisions may provide insight into common
areas of your enterprise. Once you begin discovering the decisions, you may find that you
use a similar decision in a different process. By documenting these decisions, you can
standardize the decision and apply it consistently across the different situations. You can
then use the same decision everywhere, rather than having multiple decisions that vary
slightly from process to process. This insight, when leveraged for automation purposes,
can lead to the execution of repeatable decisions, even across disparate processes.
Simpler, more efficient business processes
Extracting the decision logic out of the processes, when appropriate, can reduce the
process complexity and lead to a more streamlined process. Many process variations
relate to regional or divisional differences. Capturing these variations in the form of
decisions, rather than detailing them through complicated branches in the process makes

the overall solution easier to understand. By isolating the variations from the process, you
will be left with a foundational process that can be standardized across your enterprise.
Smarter, more agile business processes
Business processes that are designed to ensure that the right decisions are made at the
right time can provide a real competitive advantage. In general, processes tend to be more
stable than decisions, which tend to change more frequently. When you pull the decision
logic out of a process, you can update the decisions and processes independently. This
results in processes that are more responsive to changing business conditions, and
systems that can be changed in days rather than weeks or months.
The result is increased agility, where the time to get new changes implemented is
significantly faster than what would be required if the decision logic was buried in the
process. Processes where the decision logic has been encapsulated in this way are not
only more flexible and dynamic, they are also more repeatable. Since a process
standardized in this way is still able to deal with exceptions, the same process definition
can apply in multiple business situations. This leads to broader usage and applicability.
Transparent, more manageable business processes
Defining the decision logic separately from the process can improve overall management
of your operations. For example, if you clearly capture the conditions under which a
process meets certain milestones in the form of a decision, you will have explicit
acceptance criteria with which to manage those transitions. Most enterprises have some
form of audit requirements that they need to meet. Documenting the decision logic apart
from the process can provide visibility into the inputs, or necessary facts; and outputs, or
outcomes, of a decision, as well as the decision structure and logic. This creates
transparency in how you conduct your business.
1.3 Summary
In this chapter, you have seen what decisions are, how pervasive and fundamental they are to
the operation of any business, and the value of discovering and documenting the decisions
that are buried within business processes.
2
Chapter 2. Introduction to IBM Blueworks

Live
Decision discovery is usually best performed in the context of the business processes where
the decisions are being made. Because of this, it is helpful to have a common set of tools with
a single repository to document both processes and the decisions that use them.
IBM Blueworks Live is such a tool, and is used throughout this paper to discover and
document decisions. In this section, we introduce some of the capabilities of Blueworks Live
that are useful for discovering and documenting decisions.

2.1 Collaborative platform for discovering and documenting
business processes
IBM Blueworks Live is a collaborative platform for process discovery in the cloud. It provides
a rich set of tools for discovering and documenting important process knowledge. Easy to
use, and highly collaborative, it enables subject matter experts and business analysts to work
together to capture and refine their process discovery maps and process models. Teams can
easily leverage knowledge and expertise from across the organization to analyze and improve
their business processes once they have been captured in Blueworks Live.
Blueworks Live provides an easy-to-use environment for the rapid discovery, definition, and
documentation of business processes and their associated decisions and policies. Its
graphical design and visualization tools are specifically designed to make it easy for business
owners, business users, and subject matter experts to engage directly in the analysis and
improvement of their business processes. Business processes can be outlined or
brainstormed with the ease of creating a bulleted list and Business Process Model and
Notation (BPMN) diagrams are automatically generated from them. Processes can be viewed
on a shared whiteboard. And two or more users can work on the same process at the same
time; all changes are shown instantly to all users.
Blueworks Live provides the single, shared repository where all stakeholders can find the
single version of truth about any process. In this way, Blueworks Live helps facilitate
successful process improvement projects by enabling all users on the process improvement
team to get aligned on process goals, problems, and areas for improvement. When the BPM
team is ready to inventory, discover, and analyze the details of their processes, Blueworks
Live can be used as the system of record for storing and sharing the detailed information for
all of the business processes. As processes and improvement opportunities change over
time, the details can be documented in Blueworks Live so that there is a single spot where all
users can go to access the latest up-to-date information. And Blueworks Live directly
integrates with IBM Business Process Manager so business processes that are documented
in Blueworks Live can be implemented, executed, and optimized.
2.2 Decision discovery with Blueworks Live

Blueworks Live also provides the ability to discover and document the decisions within
business processes. Decisions can be modeled graphically, enabling users to compose, view,
and collaborate on decision diagrams. Key characteristics of decisions can be captured, and
the decision logic documented using decisions tables. Changes to decisions can be tracked,
and previous versions of decisions restored. Decisions of interest can be easily located, along
with the business processes that are using those decisions. Decision documentation can be
shared by printing decision diagrams, exporting decision information to MS Word and MS
Excel, and sharing links to decisions.
2.2.1 Decisions within business processes

In Blueworks Live, a decision is associated with a Decision Task in the Process Diagram. A
Decision Task is equivalent to a Business Rule Task in BPMN 2.0, and uses the same
graphical notation and icon, as shown in Figure 2-1 on page 11 and Figure 2-2 on page 11.
Figure 2-1 Decision Task Element Icon
Figure 2-2 A decision task, and its associated decision, within a business process
2.2.2 Capturing key decision characteristics

Many of the key decision characteristics described in the earlier part of this paper can be
documented explicitly in Blueworks Live using the Details tab on the Decision panel (see
Figure 2-3 on page 12). Additional details can be captured using the Documentation tab, and
if needed, documents can be attached to the decision using the Attachments tab.
Chapter 2. Introduction to IBM Blueworks Live 11

Figure 2-3 Documenting decision properties
2.2.3 Composing a decision

The Blueworks Live decision diagram is based on the principles and style proposed in the
draft OMG DMN (Decision Model and Notation) 1.0 specification. Figure 2-4 depicts the main
graphical elements of the Blueworks Live decision diagram.
Figure 2-4 Decision diagram
When composing a decision, you begin in a top-down fashion, beginning with the root
decision. You give the decision output a meaningful business name, and add any data inputs
or sub-decisions that this decision may depend on. Then you move down to the next level in
the decision diagram and do the same for any required sub-decisions. This is usually
repeated for each sub-decision until the decision structure is complete, although it is also
possible to go back and forth between the various levels and sub-decisions in the diagram
refining them iteratively until they are all complete. Figure 2-5 shows a composed decision.
The Add Sub-Decision and Add Data Input buttons and menu items automatically lay out
the diagram as the corresponding elements are added.
Figure 2-5 Composing a decision
Once the decision inputs and the output for a decision or sub-decision have been defined, the
decision logic can be defined on the Decision tab. Blueworks Live generates a skeleton
decision table based on the inputs and output from the decision diagram, or the user can opt
to create their own decision table from scratch. In either case, the user can re-arrange and
re-label the columns. Once they are satisfied with the structure of the decision table, they can
begin populating it. When working with decision tables that have more than a few rows, the
editor productivity tools, like copy and paste (CTRL-C, CTRL-V), can be very helpful for
populating new rows or blocks of rows.

Figure 2-6 shows the decision table editor.
Figure 2-6 Documenting decision logic
2.2.4 Viewing a decision

In View mode, the user can navigate between the different elements of the decision diagram,
with the details appearing in a separate pane on the right side of the window. When a
sub-decision is selected in the diagram, this pane shows all of the details of that sub-decision
including any decision tables, documentation, attachments, or comments. When a data input
is selected, the description associated with that data input in the Blueworks Live glossary is
shown. Figure 2-7 shows the root decision selected and its details displayed in the pane on
the right of the window.
Figure 2-7 Navigating a decision
2.2.5 Collaborating on decisions
There are many useful collaboration features available in Blueworks Live. Particularly useful
when working with decisions is the Activity Stream. Here, the user can see all of the changes
made to their decisions, and who made them. They can communicate with their team through
posting to the stream, or adding comments to decisions that they are collaborating on. They
can also interact through live chat with their teammates, sharing links to the processes and
decisions that they are viewing, as depicted in Figure 2-8.
Figure 2-8 Collaborating on decisions
2.2.6 Validating decisions

Once a decision has been fully documented, it will typically need to be validated by experts
and stakeholders. Blueworks Live has some lightweight process automation features that are
very useful for automating decision review and approval workflows. Reviewers and approvers
can manage their tasks within Blueworks Live and receive automatic email notifications when
there are tasks awaiting their response. The overall status of review and approval workflows
can be monitored in Blueworks Live.

Figure 2-9 shows an example of a request for decision review and approval.
Figure 2-9 Validating a decision
2.2.7 Tracking changes to decisions

When modeling a decision, the ability to revert to a previous state of the decision can be very
helpful during early discovery stages. This can also be very useful for managing changes to
decisions and for viewing past versions of decisions for audit and compliance purposes. In
Blueworks Live, the user can take a snapshot of a decision at any point in time as well as
restore to a previous (or future) version of a decision. Of course, they can also undo the last
change to a decision by using the Undo button if they made a simple mistake in which they
need to back out.
The revision history feature is shown in Figure 2-10.
Figure 2-10 Managing decision changes with snapshots

2.2.8 Finding and sharing decisions
Decisions in the Blueworks Live library can be found by using the search and filter
capabilities. And their relationships to other process artifacts can be explored by using the
Where Used feature. Links to decisions in Blueworks Live can be included in emails and
documents. Decision diagrams can be saved as PDF files or printed. And all of the details of a
decision can be exported by using Microsoft Excel. Figure 2-11 illustrates some of these
capabilities.
Figure 2-11 Finding a decision and where it is used
Figure 2-12 also shows details of a decision by using MS Word, MS Excel, and Adobe PDF.
Figure 2-12 Sharing decisions via MS Word, MS Excel, and Adobe PDF
2.3 Summary
This chapter introduced you to the decision discovery capabilities of Blueworks Live. This tool
is used later in this paper to discover and document decisions at AIC, a fictitious auto
insurance company. By the time you have finished the paper, you will be quite familiar with
Blueworks Live. You may even want to use it as you walk through this decision discovery
scenario to learn to do some of the things described in the paper.
Note: For more information about Blueworks Live, including how to try it, see the following
site:

3
Chapter 3. Getting started with decision

discovery
In previous chapters, we discussed decisions, and the value of identifying and documenting
them during process discovery. We introduced IBM Blueworks Live, a tool for discovering and
documenting business processes and decisions. In this chapter, we provide an overview of
some of the key activities that take place during decision discovery, along with some of the
techniques used to discover, document, model, and validate decisions.

3.1 Start with the business process
To discover and document the decisions within a process, you need to have a process
definition to begin with. If you do not already have a process diagram for the business area of
focus, you will need to initiate a process discovery workshop to discover and document the
process related to the decisions that you want to discover. For example, if you are having
issues with pricing of insurance policies, you will want to discover the process related to
pricing policies to find the appropriate decisions. This kind of decision-driven process
discovery effort can take as little as a few days of working sessions with the process owner
and other process experts. It is important to also invite decision experts to the workshop to
facilitate the discovery and initial documentation of the decision points within the process.
Once you begin decision discovery, you may find that you need more process information to
appropriately identify the decision points. It is essential to continue to engage the process
experts to expand the process until the key decision points can be highlighted.
Your decision discovery effort may also take place as part of a full scale process improvement
project with the goals of process improvement and automation. This type of project involves
extensive process documentation and analysis, and will likely follow a process improvement
lifecycle like the one shown in Figure 3-1.
Figure 3-1 Process improvement lifecycle
As you can see in Figure 3-1, process discovery in a process improvement project consists of
four stages:
1. Identify: This stage requires a few hours to interview the process owner and create the
initial process definition in IBM Blueworks Live.
2. Assess: This stage requires a few days to conduct a Process Improvement and Discovery
Workshop and propose a solution to the process owner and other stakeholders.
3. Document: This stage requires a couple of weeks of workshops with the process owner
and participants to model the current state process and validate any integration or
technical requirements.
4. Analyze: This stage involves a few more weeks of workshops to analyze the current state
process and design the future state process in IBM Blueworks Live. The Analyze stage
ends with a validation of the proposed solution in the form of a Playback - a formalized
walk-through of the potential process solution conducted by the process owner and other
process experts.
Often, in a process-driven improvement effort, it is not until the Analyze stage, during the
analysis of the current state process, when the process team discovers that decisions may be
an important source of the process issues. At this point, the process documentation will be at
a sufficient level of detail to facilitate effective decision discovery.
For more information about discovering your business processes, see the IBM Redbooks
publication Scaling BPM Adoption: From Project to Program with IBM Business Process
Manager, SG24-7973.
3.1.1 Review of key process elements

There are a number of useful techniques for finding where the decisions are made in your
business processes. We look at these in the next section. But before doing that, we review
some of the fundamental process elements and naming conventions that you will need to pay
particular attention to when applying these techniques. Processes in IBM Blueworks Live are
drawn using Business Process Model and Notation (BPMN). Within that notation there are
constructs to represent different elements within a process. This is not intended as a
comprehensive overview of all the BPMN constructs, but merely an introduction to those
constructs relevant to decision discovery.
Milestones
Milestones represent important stages within the process, as shown in Figure 3-2. Milestones
are not a BPMN construct, but they are used in both Blueworks Live and the IBM Business
Process Manager process definition tool, Process Designer. Activities that occur within a
milestone are usually related in some way, and the entities they act upon may transform from
one milestone to another. For example, an insurance application received in a milestone
Application is simply an initially filled out insurance application. During the Qualification
milestone, the application is validated, so it becomes a validated insurance application. Later
in the process, there might be a Contracting milestone, where the insurance application is
transformed into an insurance contract.
Figure 3-2 Milestone
Activities
An Activity is a task that cannot be broken down further, as shown in Figure 3-3. When
naming an activity, it is important to follow a standard naming convention in the form: Action
(verb) Entity (noun). For example, with this convention, Document Review means document
the review and Review Document means review the document. Beware of using generic
action verbs, such as perform, produce, complete, as they do not precisely describe the
action taking place in the task. Without precise action names, it is hard to identify decision
points in a process from task names alone.
Figure 3-3 Activity
Chapter 3. Getting started with decision discovery 23

Here is an easy formula to remember for naming your activities: Activity name = action +
entity
Or:
[action verb] + [business object]
Embedded subprocess
An embedded subprocess is an activity that can be broken down further into a collection of
tasks represented by a process, as shown in Figure 3-4.
Figure 3-4 Embedded subprocess
Decision tasks
Decision tasks are a special kind of activity in Blueworks Live. They are an activity that
invokes a decision. In BPMN 2.0 this type of activity is known as a business rule task, and
represents a task that performs some kind of automated decision, usually through calling a
decision service as shown in Figure 3-5.
Figure 3-5 Decision task
Gateways
There are three types of gateways represented in BPMN: Exclusive, Inclusive, and Parallel.
Exclusive gateway
An exclusive gateway includes one or more input paths and multiple output paths. It
represents a point in the process where the process flow can continue only along one of the
specified output paths. It typically represents a form of choice, the outcome of which
determines which output path to follow, as shown in Figure 3-6.
Figure 3-6 Exclusive gateway
Inclusive gateway
An inclusive gateway includes one or more input paths and multiple output paths. It
represents a point in the process where the process flow can continue along any number (one
or more) of the specified output paths. It typically represents a form of choice, the outcome of
which determines which output paths to follow, as shown in Figure 3-7.
Figure 3-7 Inclusive gateway
Parallel gateway
A parallel gateway includes one or more input paths and multiple output paths. It represents
a point in the process where the process flow will continue along all of the output paths in
parallel, as shown in Figure 3-8. A parallel gateway differs from other gateways in that it does
not represent a choice. All output paths are always followed.
Figure 3-8 Parallel gateway
Additional information: For a complete overview of BPMN constructs supported in IBM

Blueworks Live, see the following section in the Blueworks Live help:
https://www.blueworkslive.com/scr/help/usingblueworkslive.html
3.2 Identify the decision points in the business process

As described earlier, every decision discovery exercise begins with the operational business
context that the decision is made in. This is documented and communicated in the form of a
business process diagram. Once we have this process diagram, we begin looking for the
places in the business process where decisions are being made: the decision points. There
are a number of clues that can tip you off to the fact that a decision may be hiding in the
business process. This section describes some techniques for finding those decisions.

3.2.1 Consider the business goals and pain points
If you suspect there are decisions in your process, a good place to start is to examine the
goals, or objectives, and the problems, or pain points, of the process. If these align with
decision management, you may find there are some key decisions that you should be
identifying in the process.
Goals
If the goals of the process improvement project that produced the process diagram involve
increased business agility or improved change management, there is a good chance that the
project will need to look at decisions to meet those goals. Goals like dynamicity, governance,
manageability, flexibility, repeatability, effective change, or audit-able updates are all
indicators that decisions might need to be discovered, documented and possibly automated
to achieve those goals. In this case, you will want to examine the process, using the
techniques described below, to locate the decision points that relate to these goals.
Problems
If the business problems documented during process discovery point to difficulties making
and managing change, or difficulties producing consistent results, that may indicate the need
to uncover the related decisions. Problems like unknown updates, technical barriers to
change in business policy, inflexible conditions, inconsistent or non-repeatable results may
indicate that there is a decision somewhere in the process step where the pain point is
documented. If the pain point is not documented for a specific step, or activity, in the process,
but instead is noted for a milestone, or the entire process, look for an activity that relates to
the topic of the pain point topic within the milestone, or process. If you cannot find one, you
will need to add an activity to represent the decision that is taking place. Examine these parts
of the process using the techniques described below to locate the decision points that relate
to these pain points.
3.2.2 Closely examine gateways, activities, milestones, and participant

hand-offs
There are a number of process elements that can help you find decisions. In particular,
gateways, activities, milestones, and participant hand-offs in the process diagram should be
examined closely.
Gateways
Gateways represent branches in the process flow. These branches are often the result of
answers produced by decisions. Look for the tasks prior to the gateway for the work that is
performed to determine the answers. These are usually decision points. Sometimes, the
gateway itself represents the question and answer, and no task is captured to represent the
work performed to answer the question. In this case, you will need to add a task to represent
the decision.
Activities
You can also find decisions by looking directly at the names of the activities in the process
flow. If activities are named following the standard naming convention of action entity, you can
examine the action verbs for decision or computation keywords. Table 3-1 on page 27 lists
key action verbs that indicate that a decision or calculation is taking place. An activity with one
of these verbs in its name is usually a decision point.
Table 3-1 Decision keywords
Decide Calculate
Adjudicate Apply
Agree On Appraise
Analyze Appraise
Appraise Calculate
Approve Categorize
Assess Classify
Change Combine
Choose Compute
Compare Construct
Conclude Construct
Contrast Derive
Decide Estimate
Detect Formulate
Determine Price
Differentiate Produce
Discriminate Reconstruct
Distinguish Revise
Evaluate Solve
Gauge Weigh
Identify n/a
Qualify n/a
Reckon n/a
Resolve n/a
Review n/a
Settle n/a
Validate n/a
Verify n/a
Milestones
You can examine the milestones in your process to find decision points. Milestone boundaries
may be decision points. If you pass a milestone in a process, there might be some criteria that
you need to meet before moving onto the next milestone. Determining whether this criteria is
met could be a decision. Look for activities at the end of a milestone, are they checking that
you are ready to proceed to the next milestone? This is a decision point. Look for tasks at the
start of a milestone. Are they validating that data is complete or correct before continuing?
This is a decision point. Sometimes, not all the tasks in a process are captured or the tasks

are high-level and generic. In this case, you can review the milestone documentation to find
possible decision points, by asking the following questions:
Is the scope of the milestone defined? Decision points identify if the boundary of the
milestone is reached.
Are entry and exit conditions defined? Decision points validate entry and exit conditions.
Are goals defined? Decision points determine if goals are achieved.
If you find that any of the above conditions are not described by an activity in the process flow,
you need to add an activity to the process to represent the decision point.
Participant hand-offs
When you see a hand-off from one participant to another, this is often an indication that a
decision is taking place. This decision may be one that is checking to ensure that the
information is complete before handing it over to the next participant in the process flow. Look
for activities around the participant hand-off to see if one of them may be or may contain a
decision. Again, as with milestones, you might find that you need to add another activity to the
process to represent the decision point.
3.2.3 Review related processes

At this point, you may have already identified some decision points in your current process.
Perhaps, you feel that these decisions may not be unique. That is, you think they may be used
elsewhere in your enterprise. If you already have a process inventory, you may find it useful to
extend your search to other related processes, where you may find one of the following
scenarios.
Similar processes, different decision

Look for business processes that appear to be very similar, except for a few variations. If the
variations relate to different decisions, there may be an opportunity to simplify your process
inventory. You can redefine the process as a single definition that uses different decisions,
depending on the scenario.
Similar decisions, different processes

Look at different business processes that use a similar decision. There may be another
opportunity to simplify your decision inventory by reusing a decision service. The following are
some sample scenarios of decisions that frequently get reused across an enterprise:
Do you do similar types of validation on user inputs?
Do you use standard calculation models, for example for taxes?
Do you do similar types of reviews of client information, such as applications?
Do you reuse a standard pricing model across many processes?
When you discover these similar decisions in different processes, you can redefine the
processes to use the same decision that you now need to define only once.
Localized exceptions
Often, processes that appear different are in fact very similar, but they really differ only by
some form of localized exceptions. Localized exceptions are where each part of your
enterprise, for example a country, division, or product group, may have defined its own
exceptions to a global standard. For better, more effective, business process management, it
is a recommended practice to define these processes according to the single standard. Then,
determine if any of those differences can be eliminated. For any that must remain, for
example those based on different regional laws, it is recommended to manage those
conditions governing the exceptions through decisions. Identify the places in the process
where variations, or exceptions, occur, and for each place, if no activity exists that represents
an appropriate decision, add one to your process to capture the alternatives.
3.3 Identify and prioritize decisions for further discovery

Once you have identified the potential decision points in your processes, it is time to prioritize
and plan the detailed decision discovery activities. Not all of the identified decision points will
necessarily be worth the time and effort that is required to further discover and document
them. You need to capture some additional information about these decisions in order to
make this assessment. They need to be reviewed and prioritized in light of your specific
business goals and some general suitability criteria. Once this is done, you can plan the
detailed decision discovery work for each of them and create your decision discovery
roadmap. This roadmap lays out a plan for conducting the decision discovery workshops that
are the foundation of any decision discovery project.
3.3.1 Document high-level decision characteristics

Any decision that your organization needs a better understanding of can be a good candidate
for in-depth discovery. Any decision that will likely be automated can be a good candidate for
in-depth discovery. The specific business goals and pain points that your project seeks to
address will ultimately have the greatest influence on the selection of decisions for further
discovery. But there are also some more general questions to consider when reviewing your
list of candidate decision points. The best practice is to quickly capture some of the high-level
characteristics of these decision points, just enough to enable you to answer the following
questions:
How complex is this decision? If it is very simple, you might not really need to discover and
document it further.
How often does the decision change? Decisions that change frequently may be good
candidates for automation by using Decision Management technology. If automation is
ultimately the goal, it is likely that you will want to discover and document these decisions.
Does the decision have to be changed quickly? If there is a lot of time pressure to comply
with related policy changes, for example, then the decision may be a good candidate for
automation.
Who has knowledge and expertise related to this decision? If they are within the IT
organization, this may not really be a business decision, in which case other
software-oriented requirements gathering techniques may be more appropriate. If the
knowledge is in the business organization, going though this kind of decision discovery
exercise may prove invaluable.
Who owns this decision? Who ultimately determines how the decision is made? If it is a
computer programmer, once again, other software-oriented requirements gathering
techniques may be more appropriate. If, however, the person who owns the decision is
responsible for working directly with customers (processing their applications and claims,
for example), going through this kind of decision discovery exercise may be very
worthwhile.
Are there really strict guidelines around who can make changes to the decision logic? If
you need a lot of control over the way a decision is changed, it may be a good candidate
for automation and management using Decision Management technology. If this is the
case, you will definitely want to discover and document it.
Are there audit requirements related to the decision? If there is a need to know, after the
fact, exactly how a specific decision was made, it may be a good candidate for automation

and management using Decision Management technology. If this is the case, you will
definitely want to discover and document it.
Complex decisions that change relatively frequently, must be changed quickly, are owned by
the business, require robust change control or governance, or must be auditable, are great
candidates for automation with Decision Management technology. If automation is a goal of
your project, you will likely want to discover and document most of the decision points that
meet these criteria.
Many other factors may determine the order in which you decide to discover and document
these decisions: The skills of the decision discovery team, the availability of subject matter
experts, and the relationship between decisions in a process are some of them. Once you
have laid this out in your decision discovery roadmap, it is time to assemble the team and
begin the detailed discovery work.
3.3.2 The importance of the subject matter expert

When assembling the decision discovery team, make sure to include one or more subject
matter experts, which are people who possess in-depth knowledge of the decisions being
discovered. It is important to ensure their participation by identifying them up front, securing
the commitment of their management, and involving them early on in the discovery process.
Often, you will find the business knowledge related to a decision documented in some kind of
manual or even within an existing computer program. It is best to always involve a human
source during decision discovery, even when you are relying heavily on documentation to
understand the details of the decision. Deconstructing code can be time consuming,
especially if the original programmers are no longer around to help, many changes have been
made, and the documentation is lacking. Policy and procedure manuals often describe the
business knowledge in a way that best suits the needs of the policy maker, not necessarily the
person that is tasked with applying the policy. As a result, the person applying the policy
usually relies on their own knowledge to supplement whats in the policy manual and to figure
out how to understand and use the knowledge presented in it. The organizational context
often has a significant effect on how the business knowledge is applied, so having a
knowledgeable person involved is essential for effective decision discovery. As illustrated in
Figure 3-9 on page 31, the best sources for decision discovery are always the people with
direct knowledge of the decision.
Figure 3-9 Of all the sources of decisions, the most reliable are people
It is not always easy for subject matter experts to articulate their knowledge. After years of
working in a particular area, knowledge and expertise may become unconscious and
automatic. Often an examples-based approach can be a great way to begin the interview
process. Using this approach, you provide the expert with some examples of real business
situations where the decision is being made and have them explain out loud how they would
go about making the decision in each of the cases. It is important to have somebody on the
team with good interview and elicitation skills to guide these discussions. A good business
analyst will typically have these skills, but there may be other qualified individuals in your
organization that you can enlist.
3.4 Model the decision

Once the decision discovery roadmap has been created and the decision discovery team
assembled, you are ready to begin conducting the decision discovery workshops. In these
sessions, the team will leverage the subject matter experts and other important knowledge
sources to understand and document, in depth, how the decision is made. This is called
decision modeling and during this activity you will identify and document:
What the decision is, and what it is that is being decided
Any information that is required in order to make the decision
Any other decisions that this decision depends on in order to reach a conclusion
The logic that describes how the decision reaches a conclusion that is based on these
inputs
3.4.1 Capture the fundamentals of the decision

If you have not already done so, give the decision a name and a description, typically a couple
of sentences, but definitely less than a paragraph. And define the decisions output.

Decision output
Consider what exactly is being decided, and succinctly document that as the decisions
output. Sometimes it can be helpful to phrase this as a question that the decision answers.
For example, Driver eligible for insurance? is a good name for the output of the Validate
Driver decision. Driver eligibility or Driver Eligible? would also be fine, although these
names are not quite as descriptive. This is an example of a decision that produces a boolean
resultthe output must be one of two values: yes or no. This is a very effective way to model
a decision output because it is very clear and easy to understand.
However, some decisions cannot be modeled this way, and in these cases an enumerated set
of values or a number may be a better way to define the decision output. For example, take a
decision called Determine Vehicle Theft Risk that determines whether the vehicle theft risk is
High, Medium, or Low. A good name for this decision output may simply be Vehicle Theft
Risk. Another example would be the Price Policy decision, which calculates the price of the
premium. A good name for this decision output might simply be Premium Price.
When defining the decision output, try to choose a name that is clear, concise, easy to
understand, and that accurately conveys the business meaning of what is being decided.
3.4.2 Identify the information required to make the decision

When interviewing the subject matter experts and reviewing your other knowledge sources,
identify any information that is needed to make the decision. It may involve data coming from
corporate databases, the contents of fields in forms or questionnaires, information in
spreadsheets, data from an online feed, or any other form of information. The best practice
involves documenting this at a higher level of granularity as inputs to the process activity that
the decision is associated with (the decision task). Then, the data inputs needed by the
decision are documented at a lower level of detail. So, for example, in a process that issues
an auto insurance policy there might be a qualification activity that takes place. As part of that
qualification activity, a decision is made as to whether or not the applicant qualifies for
insurance. Following this best practice, the Insurance Application and the applicants DMV
Report would be documented as inputs to the qualification activity in the process. Whereas in
the decision, the actual fields from the Insurance Application (age, ZIP (or postal) code,
gender, and so on) and the DMV Report (number of moving violations in the last five years,
number of accidents in the last five years, and so on) that are used to make the decision
would be documented as data inputs to the decision.
3.4.3 Identify any required sub-decisions

Often, decisions are based on the results of other decisions. For example, Marie's driving
record may be evaluated by a decision that calculates some sort of driving score based on
her driving record. With no accidents or tickets in the past five years, and as a 43-year old
woman, Marie's driving record might score 100%, for example. A decision by an auto
insurance company whether or not to provide Marie with auto insurance may depend on that
driving score, which is the result of another decision, plus some additional information about
the cars she owns. Let us assume that this insurance company does not like to insure antique
performance cars, but is very happy to insure current hybrids. In that case, her score along
with the information about her cars might result in a decision to insure only the Hybrid ABC, or
the decision to insure both cars, with a surcharge for the Antique XYZ.
3.4.4 Document the decision logic
The next step is to document the logic that the decision uses to reach its conclusion. In
Blueworks Live, we do this with decision tables, as shown in Figure 3-10, which organize the
logic into rows and columns. Decision tables are a very straightforward and intuitive way to
document decision logic, as many people are familiar with spreadsheet applications and so
are comfortable both documenting and understanding this kind of tabular representation. If
you would like to understand more about the logical structure of decision tables and how we
use them in this paper, read the next section. Otherwise, it is fine to skip this for now and learn
more about decision tables when you get into the AIC example that is presented later in the
paper. To learn more about decision tables in general, there are some excellent references in
the appendix that you can leverage, should you want to explore this topic further.
Figure 3-10 Example of a decision table containing decision rules
Decision table conventions

There are several different types of decision tables, and various options for documenting and
interpreting them. In this paper, we use unique, single-hit, and rules as rows decision tables
because these are usually the easiest to understand and work with in the beginning. We will
also follow some best practices of decision design to ensure that both the decisions and
decision rules described in these decision tables are atomic and readable.
The decision table conventions followed in this paper are described below:
Column headers in a decision table

The facts to be considered (the considerations) and the conclusion reached (the conclusion)
are identified in the column headers of the table:
The considerations in the decision table typically map one-to-one to the decision inputs
that are documented in the Blueworks Live decision diagram. However, sometimes a

consideration may be derived from one or more decision inputs, in which case it will not
map directly to a single decision input.
A consideration column heading may contain a decision input or any combination of
addition, subtraction, multiplication, division, and exponentiation of decision inputs and
literals.
By definition, a decision has a single output (that is, reaches a single conclusion). There
must be a single conclusion column in the decision table that maps directly to the decision
output in the Blueworks Live decision diagram. In some cases, you may choose to create
an additional conclusion column to capture a key piece of information related to the
conclusion (typically a message column, describing the reason the conclusion was
reached in natural language business-friendly text). But only one of these conclusion
columns can be designated as the decision output in the decision diagram.
Cells in a decision table

We have to look at two types of cells:
Each cell in a consideration column contains some sort of expression that is applied to the
consideration identified in the column header:
These condition cells typically contain operators such as =, !=, <, <=, >, >= that test the
consideration in the column header against a literal, another decision input, a range, or
a list of these. You can express these operators in natural language, or use the
symbols. Do whichever produces the most understandable decision table for your
organization.
When a cell is left empty, it means that any value for that consideration will cause the
condition to be evaluated to true.
If there is no operator in a populated cell, then we assume the operator to be =.
Each cell in a conclusion column contains some sort of expression that is used to assign a
value to the conclusion identified in the column header (that is, the decision output):
These conclusion cells often contain a simple literal or numeric value, but can also
compute a numeric value using arithmetic operators (+, -, *, /, and so on) and decision
inputs.
Rows in a decision table

Each row in the decision table represents a decision rule.
Each decision rule has a single path to the conclusion. In other words, the cells in a row are
implicitly ANDed together to reach the conclusion. ORs are not supported between columns.
Decision table best practices

In addition to following the above conventions, the decision tables in this paper are
documented with the following best practices in mind:
It is a good idea to limit the number of consideration columns for readability purposes. If
you find yourself with more than seven or eight consideration columns, you might want to
consider breaking the decision up into sub-decisions.
Each decision rule should be unique in that no more than one decision rule should be able
to evaluate to true for any given set of inputs. In other words, there should not be overlap
between rules.
There should be no implied order of evaluation in a decision table, no notion of sequence.
Rather, your decision tables should be organized in the way that most clearly reflects the
business knowledge, and is easiest to understand.
A decision table should be as complete as possible.
A decision table should be as easy to understand as possible. For readability purposes,
we sometimes make an exception to these last three guidelines. It can become quite
tedious filling out endless rows of a decision table just to make sure that every possible
combination has been accounted for explicitly. Similarly, it can sometimes be hard to read
such a decision table:
When it makes sense, we may use empty cells, rather than creating a decision rule for
every single possible combination of considerations. In these cases, we may relax the
uniqueness constraint described above.as long as the overlapping decision rules all
reach the same conclusion. The Analyze Driving Record decision table in Figure 3-11
shows an example of how you might document a decision table like this in Blueworks
Live.
Figure 3-11 Making a decision table more readable by using empty cells

When it makes sense, we may create an exception table for a decision table that
provides an else, or otherwise clause. This way, the decision table does not have to be
cluttered with many decision rules that essentially have the same meaning. The
Validate Salary decision table in Figure 3-12 shows an example of how you might
document a decision table like this in Blueworks Live.
Figure 3-12 Making a decision table more readable by using an Otherwise clause
3.4.5 Modeling decisions for understanding, validation, and communication

When documenting a decision in Blueworks Live, focus on making it easy to understand and
easy to explain to others. Aim for it to be complete and correct from a business standpoint
when you are done modeling and validating it. But do not expect to create a rigorous and
formal decision model that can be automatically translated into executable code. Blueworks
Live does not currently enforce the necessary semantics or support the necessary data
modeling constructs required for automation. Instead, approach Blueworks Live as a tool for
documenting the business requirements that are associated with a decision.
If the decision is going to be automated, these requirements will have to be transformed into a
precise, formal, unambiguous specification. A formal data model will have to be created to
describe the information that the decision will need to access when it executes. The decision
logic will have to be translated into some sort of language that can be executed on a
computer. Business analysts that are skilled in creating UML models and documenting
business rules using formal languages like BAL (the IBM Business Action Language),
SBVR-based languages (Semantics of Business Vocabulary and Business Rules from OMG),
or others, will need to get involved. Developers that are skilled in designing and integrating
decision services and orchestrating the rule sets within them will need to get involved.
Decision automation: See Appendix A, Automation considerations on page 121 for a
brief overview of some of the tasks that are required to automate a decision that has been
documented using Blueworks Live.
If you do a good job modeling, documenting, and validating the business requirements
associated with the decision, these other tasks become much more straightforward. Also,
traceability can be maintained between the decision requirements as documented in
Blueworks Live and the decision services as implemented in your organizations software
applications.
3.5 Validate the decision and establish any necessary

governance practices
It is important for the organization to be able to rely on the accuracy and timeliness of
documented decisions. If they are out-of-date, incomplete, or fail to accurately reflect the
organizations knowledge, they will never become a trusted, single source of truth and they
will be of limited value. Engaging the right subject matter experts, and doing a good job of
analyzing and documenting their knowledge will go a long way towards producing a good
result. Engaging a broader set of experts and stakeholders to get different perspectives and
help reconcile conflicting views will ensure that the decision truly reflects the knowledge of
your organization, rather than just a select few.
The introduction of a formal decision validation process will raise awareness of and visibility
into the decision throughout the organization. It will also ensure ownership and buy-in up the
management chain. And the incorporation of some change control and management
practices can help ensure that the decision always reflects the current state of the business,
and that it can be relied upon in the future. The establishment of naming conventions for
decisions and decision versions can help with both decision validation and decision
governance. But it is important to put some thought into how your organization will manage
decision validation and governance, up front.
3.5.1 Decision validation

Decision discovery is a highly interactive, iterative process that involves a lot of collaboration
between team members and other participants. Validation occurs informally on an ongoing
basis as team members review each others work and solicit feedback from other experts and
stakeholders. This feedback typically results in frequent reworking and revision of the
decision, especially in the early stages of the project.
Once a decision has been fully documented, it should be formally validated by a wider group
to ensure that it is complete and correct. In addition to the core decision discovery team
members, you may want to request validation by subject matter experts from adjacent or
impacted business areas. If the decision is related to specific corporate business policies, you
might want to ask the person in charge of defining or documenting those policies to validate
the decision. If the goal is to automate the decision, somebody from the information
technology group responsible for implementing it should be involved in validation. Basically,
any stakeholders that have a strong interest in and knowledge of the decision should be part
of the formal validation process. The business owners and the owner of the decision
discovery project should not only review, but also approve the final decision.

It is a good idea to log the following formal validation activities:
The names and roles of participants in the validation process.
The feedback received from them.
The dates the decision was reviewed and approved.
Feedback from the formal validation process may result in additional changes being made to
a decision. However, at this point, changes should be minimal because the informal validation
that took place earlier should have identified most issues. Once any necessary feedback has
been incorporated, and the final decision approved, it should be clearly identified as the
current validated version. In this way, when future changes in the business require that the
decision be updated, these changes can be applied to the current version and they can be
tracked. This is often necessary to satisfy compliance or audit requirements. But it is also
considered a basic best practice for change control and management of decisions, also
known as decision governance.
3.5.2 Decision governance

Once a decision has been validated, it is important to govern (that is, manage) any changes
made to it. What this means is that:
There should be a well understood lifecycle for decision changes.
For example, as a result of a decision change request, a decisions status may change
from valid to under revision, from under revision to out for review, and once all required
approvals have come back, it may change from out for review to valid. Of course, a
decisions status could also go from out for review to under revision.
The specific individuals or organizational roles should be identified that are allowed to
make direct changes to a decision.
If the decision is only intended to be viewed by a limited group of individuals or roles within
your organization, they should also be clearly identified.
The validation process for decision changes should be defined.
It may be the same as the validation process for the original decision, or you may decide to
streamline the review and approval process and involve fewer people. In either case, the
individuals or organizational roles that are designated to review and approve the decision
should be documented.
The lifecycle of changes should be logged.
You should log the following details:
What was the change that was made?
Why was it made?
Who was it made by?
When was it made?
Who reviewed and approved it?
What feedback did they have?
With some basic processes and tools in place to manage the decision validation and
governance processes, the results of your decision discovery efforts will likely be of
significantly more value to your organization.
3.6 Conclusion
In this chapter, we provided an overview of some of the key activities and techniques involved
in conducting a decision discovery exercise. We saw how important it is to start with the
business process and to identify the decision points before planning the decision discovery
roadmap. We touched upon some of the key activities that take place once the decision
discovery workshops begin and the decisions are documented and modeled. We emphasized
the importance of validating and setting up some kind of governance around decisions once
they have been modeled and documented. Together, this set of practices provides a
framework for conducting decision discovery. In the next chapter, we see how to apply this
framework to a fictional example at An Insurance Company.

4
Chapter 4. Bringing it all together: The AIC

decision discovery project
In Chapter 1, Introduction to decision discovery on page 1 you learned about decisions, and
the value of identifying and documenting them during process discovery. In Chapter 2,
Introduction to IBM Blueworks Live on page 9, you were introduced to IBM Blueworks Live,
a tool for discovering and documenting business processes and decisions. Chapter 3,
Getting started with decision discovery on page 21 provided an overview of how to
approach decision discovery, and some of the important things to consider when discovering
and documenting decisions. This chapter brings all of these elements together and delves
into the details of how to discover and document decisions with Blueworks Live, based on the
experiences of a fictitious auto insurance company, An Insurance Company (AIC), with their
first decision discovery project.

4.1 Introducing An Insurance Company
Sue, the head underwriter of An Insurance Company (AIC), was expecting someone to walk
into her office that morning, but was surprised that it was Ginny.
So, you found another one? Ginny asked.
Yes, Sue replied. A senior citizen, living in one of the retirement communities. Here, take a
look.
No accidents on her record except somebody backed into her last winter.they probably
slipped on the ice. Her premium went up about $100 more than my calculation said it should
have.
Ginny sighed. As director of IT, her whole last year had been dominated by not-at-fault
accidents. Three years ago, a very public court case had been argued, and a competing
insurance company had paid a very large fine for raising the rate on customers whose only
accidents had been ones where they were not at fault; accidents that occurred when they
were parked, when they were stopped at a light, hit and run accidents. Paul, the CEO of An
Insurance Company had sent down an order that the company should remove any calculation
that used not-at fault accidents to calculate rates.
This had been a nightmare. Their systems were old, legacy systems that used a lot of
database tables to calculate rates. But the kind of logic that Paul wanted them to remove was
not in the tables; it was in the old code. And it was not documented. It had been a year's work
for the best minds of their IT department to find and change all the places where this logic
was, and in the process they found that their systems did not always work the way they
thought they did. Personally, Ginny was proud of the efficiency of her programmers, rooting
out all the places where this was used by the calculation.
Except, of course, they had not. Yes, most of the calculations were now fine, but every now
and then they ran into a situation where the system was still increasing the rates incorrectly.
Sometimes this was program logic that they had missed. Sometimes it was old code, so
messy that they had not been able to figure it out. Sometimes it was bugs they had introduced
inadvertently. They had recruited the underwriters, who were manually checking a selection of
the statements as they were generated to help them find issues. Now, half a year after
implementing their solution, another issue had been found. Ginny really hoped that this was
the last one.
But today, Ginny was here to try to rethink how they were doing their work. You know, Sue,
she said, we have had a terrible time with this in IT.
Yes, Sue replied, I know.
I've recently been to a conference and learned a little bit about decision management. I want
to propose a project to you.
Me? On an IT project? I do not think so, Ginny. I know just about everything there is to know
about underwriting, but I have trouble when I use anything more complex than presentations
and spreadsheets on my computer.
That is OK, Sue. Ginny smiled. I do not want you to become a programmer. But this whole
painful process has taught us that we really do not know exactly what our systems are doing,
and whether it is exactly what they should be doing. I mean, we do not know what the
decisions are that they are making. I think we need to identify what our decisions are, not in
the code, but from a business standpoint. I think we need to identify and document what
decisions we should be making, and how those decisions should be made, not based on the
code, but based on the policies of this company.
That makes sense, but I am not sure how I can help.
Well, you know the underwriting decisions better than anyone. And you and Frank in
accounting, between you, understand the pricing best of anyone in this company. Don't you
think that is true?
I suppose so.
Well, I'd like you to spend some time helping us figure out and document those decisions so
we all understand them. It will be useful in a number of ways, but I think it will be particularly
important as we bring this new web interface online. It is using the legacy systems, but we
need to be able to explain to customers why we make certain decisions, especially if they can
see them on the web page.
This sounds a little like the work we were doing on the process. Is that what you have in
mind?.
Yes, and no, but there are a lot of similarities. In fact, we are going to use the same software
tool we are using for the process work. You've worked with that, haven't you?
Yes. I have looked at the process models that your group has created, and even edited them
once or twice. It seemed pretty simple to me.
Great. I am going to talk to Paul about this, but I think we will start with what the process
team has developed, and begin to try to discover our decisions using it as our starting point.
In the meantime, why don't you start thinking about how you make these decisions, and we
can gather on Thursday for a kickoff meeting. Please invite anyone on your team who you
think might have knowledge about this. OK?
Sure, Ginny. We are glad to help.
Insurance is an area where policy and decisions drive a significant business value, and
therefore deserve significant attention. The importance, complexity, and quantity of the
decisions make insurance applications an important place where decision discovery and
automation can be of great value. Most insurance companies conduct yearly re-evaluations of
their policies, which are based on their claim experience. Insurance is also heavily affected by
legal decisions and governmental regulations. Policy changes required in response to a
shifting regulatory environment may need to be implemented quickly. There is often a need
for decisions to be audited by outside agencies, and to be understood by employees in
customer-facing roles, so visibility is a significant goal in most cases. And, of course, these
policies and decisions originate with people who understand the insurance business and
industry, rather than people who are more technical.
For all these reasons, we are going to follow the initiative that An Insurance Company is
kicking off to discover and document their decisions, as they begin to put together their web
project. Will they use Decision Management technology to automate these decisions? They
do not know, and we do not know, although many insurance companies have found this to be
very beneficial to their business. Whether or not they do that, however, understanding the
decisions they make, and how they make them will be of value to the company and to their
work, and will provide insights that will enable them to streamline their efforts. The process
discovery work that was previously done at AIC had already helped make their operations
more efficient. They will leverage this work to help drive their decision discovery initiative.
Chapter 4. Bringing it all together: The AIC decision discovery project 43

4.2 Step 1: Starting with the business process
Most decision discovery initiatives begin with at least a general idea of what decisions the
project team will need to focus on. I want to look at the decision about who qualifies for
insurance, and the decision as to how to price that insurance correctly, says Sue of AIC.
The process discovery work that Ginny referred to would be the starting point for this decision
discovery project. The process improvement team had been using Blueworks Live to discover
and document the processes in a project related to setting up a new web interface for
customers to conduct business with AIC. When the team started doing process discovery,
they found a lot of inconsistencies in the way that they were doing pricing. The team decided
to first focus on improving the pricing process used internally, before exposing it via the web
to their external clientele.
During the analysis of the current state process, the process team started to drill down into
the validation, pricing, and contracting areas. As the team dove deeper and deeper into these
process activities with more extensive analysis, Ginny realized that they did not need to know
more about the process steps sequence at that point, but instead needed to understand the
decisions made within the process. For this, she brought Sue and Frank on board for their
underwriting and financial knowledge.
Sue had been involved with the earlier process discovery project, but it had been in the role of
an underwriter with the perspective of tasks and sequence, that is, identifying the activities in
the process and determining their order in the process flow. Now she was going to participate
as a decision expert and use her underwriting knowledge to help find the decision points in
the process and discover and documents how those decisions were made at AIC.
The Process Diagram

As we saw in Chapter 3, Getting started with decision discovery on page 21, the first step in
any decision discovery exercise is to understand the operational business context that a
decision is made in. Spend some time thinking through and understanding the business
process before focusing on the decisions in any depth. This will help clarify exactly what the
decisions are that you need to discover and document. The easiest way to identify decisions
is to start with a process diagram.
The process discovery phase of a process improvement project begins with the Identify and
Assess stages. You can begin this work in Blueworks Live by creating a space and capturing
your project goals. These goals will be central to defining the direction and objectives of your
project, but they may also be useful for identifying important decisions that need to be
examined. Once you have set up a space, create a Discovery Map in Blueworks Live.
Determine the major milestones, or stages, in the process. Then, in each milestone you can
list out the tasks that are performed. You do not have to worry about sequence at this stage.
Once you feel you have a good representation of the milestones and activities in the process,
you can create a Process Diagram from the Discovery Map in Blueworks Live. At this point,
you will focus on the sequence of the activities and on capturing the details of each activity:
the participant, or role, that performs the task; the inputs to the activity and its outputs, and a
number of other properties. From this, you will be able to see how the process flows from one
activity to the next and from one participant to another. You can capture lots of information
about each activity, but it is particularly important in a process improvement effort to capture
the problems, or pain points, for each activity. This information will help later when you are
looking for decisions. To learn how to do process discovery with Blueworks Live, consult the
additional resources provided in the appendix.
The AIC process improvement team had already done quite a bit of process discovery, and
was in the Analyze stage of their process improvement project when Sue and her team were
brought in to start focusing on decisions. Figure 4-1 shows the process diagram that they had
created.
Figure 4-1 AIC Issue Auto Insurance process
In this process there are five milestones: Application, Qualification, Pricing, Underwriting, and
Contracting. The process improvement team had many discussions around the application
steps and how much pre-qualification they did for each applicant. They had also looked at
qualification to understand what sort of validation was taking place after the driving record
was requested. As the process team tried to document the activities in these areas, they
struggled with the best way to document this logic in the process flow. They realized that
documenting the details of qualifying eligible applicants was not something they could do
easily with a process diagram that focused on human actors. They needed some kind of
visibility into how the systems were applying eligibility criteria and pricing. To clarify their
thinking, they converted the Enter Insurance Application and Determine Qualification
activities into subprocesses so they could explore them in more depth. It was at this point that
they realized there was more complexity there than they were prepared to deal with. That is
when Ginny attended the decision management workshop, and decided that they needed to
do some decision discovery.

As Sue studies the process diagram and the documentation, she makes note of these two
areas for further investigation. She suspects that decisions are involved, and that the logic would
be better documented in the decisions than in the process model. In fact, Sue thinks there are at
least three decisions there. They need to look at both the car and the driver information to
determine whether or not they would cover them. AIC does not cover drivers under 18 on their
own policies, and they do not cover performance cars like hot rods, or trucks. If they do not
make some kind of decision about that before requesting the driving record, they will end up
paying for the driving record of customers that they already know they cannot insure.
Now that Sue has familiarized herself with the process diagram, she is ready to dive in to start
finding the decision points in the process.
4.3 Step 2: Identifying the decision points

As discussed in Chapter 3, Getting started with decision discovery on page 21, there are a
number of clues that can tip you off to the fact that a decision may be hiding within a business
process. Now we use the techniques that were described in that chapter to find the decision
points in the AIC Issue Insurance Policy process. We start with the process diagram created
by AICs process improvement project as shown in Figure 4-2.
Figure 4-2 The AIC AS-IS business process
4.3.1 Look at the gateways
In Chapter 3, Getting started with decision discovery on page 21 we learned that the
gateways in the process diagram are a good place to start looking for decision points.
In the AIC process diagram, Sue finds the first gateway in the Enter Insurance Application
subprocess, which is shown in Figure 4-3. This is an exclusive gateway, which we learned
about in Chapter 3, Getting started with decision discovery on page 21. The gateway asks a
simple Yes/No question: Does the Driver appear to qualify? If the answer is Yes, the
process continues, if the answer is No, the process ends.
Many gateways are binary, that is, they test for a Yes or No, True or False value and have only
two exits. However, gateways can be more complex with any number of choices and exit
paths, especially where more complex decisions are involved. The gateway itself does not
usually represent a decision. More typically the gateway is just testing the value of an output
from a previous activity to determine what the next step in the process should be. It is not
actually making the decision that sets that value. However, if the gateway is assessing a
whole set of information that has been collected in previous steps of the process, it may
indicate that the decision is hidden in the gateway itself. If the gateway is checking a simple
value, trace backward from the gateway to find a process activity that produced this output.
This is likely where you will find the decision.
Sue traces backwards from the first gateway in this subprocess and sees the Prequalify
Driver activity. This activity determines whether or not the driver qualifies, at this early stage
in the process. While it is very common to find the activity that makes a decision just before
the gateway that consumes it, it is also possible that the decision may occur earlier in the
process. If you do not find the process immediately in front of the gateway, keep tracing
backwards until you either find it, or reach the beginning of the process.
Figure 4-3 Decisions can often be found before gateways in a process diagram
If you trace back to the beginning of the process and do not find an activity that makes the
decision that the gateway is testing, then one of two things are true: Either the gateway does
indeed represent a decision, or the gateway is just testing a piece of information, not a
conclusion reached by a decision earlier in the process. If you are in doubt as to what your
gateway is doing, it will not hurt to identify the gateway as a potential decision point and come
back to it later when you have more information.

Once you have identified a decision point, you will need to create a Decision Task in
Blueworks Live to represent it. If the decision point was discovered in an existing activity, you
do this by changing the type of the activity to Decision Task in Blueworks Live. If there was no
activity associated with the decision point, you will need to create a new activity of type
Decision Task. To do this, right-click the activity and select these choices from the menu as
shown in Figure 4-4.
Figure 4-4 Create a Decision Task to represent the decision point
Sue has identified two activities that precede gateways and appear to be decision points.
They are Prequalify Driver and Prequalify Vehicle. You can see these activities identified
as decision tasks in Figure 4-5 on page 49.
Figure 4-5 Two decision tasks identified by Sue in association with gateways
4.3.2 Look at the activity names

Decisions do not always drive branching in process diagrams. Sometimes the conclusions of
decisions are simply carried forward and used in a later step of the processwhere a quote is
produced, an invoice generated, a report created, or any number of possible uses. So in
addition to looking for decisions that are associated with gateways, you will need to look for
decisions in other process activities. One way to do this is to look for words that indicate that a
decision is being made. If the verb associated with the process activity is a decision or
calculation verb, then there is a good possibility that a decision is at least part of what is
happening in the activity.
Decision and calculation verbs: For more information, review Chapter 3, Getting started
with decision discovery on page 21, where decision and calculation verbs were discussed
and a list of them was provided.
Sue identifies some process activities later in the process diagram whose names contain
decision and calculation verbs. The verb, validate, in validate driver and validate vehicle
clearly suggests that these activities involve decisions, so she identifies both of them as
decision points. And the verb, price, is in the list of calculation verbs. This, combined with the
fact that inconsistencies in pricing were clearly documented as pain points by the process
improvement team (and highlighted by the CEO in company-wide communications), leads her
to also identify Price Policy as a potential decision point as shown in Figure 4-6 on page 50.

Figure 4-6 Process activities containing decision verbs
4.3.3 Look at the milestones

In your review of the process diagram, you may come across a process activity that is not
associated with a gateway, and whose name does not contain a decision verb, but that you
feel is making some kind of decision. This often occurs at the points in a process where work
is being handed off from one participant to another, or where transitions between milestones
occur. Evaluate the activities immediately before and after a hand-off between participants or
a transition between milestones.
As Sue considers the transitions between milestones in the AIC process diagram, she notes
that the transition between the Pricing and Underwriting milestones likely involves a decision.
As an underwriter, she knows that they never underwrite a policy until it has been priced. And
although there is currently no gateway in the diagram indicating this, based on everything else
she has seen she thinks that this just provides even more evidence that the Pricing activity is
an important decision point.
4.3.4 Summary
In this section we have seen how to identify decision points in several ways:
By examining activities associated with branching and gateways in the process diagram.
By examining activities whose names contain a decision or calculation verb.
By examining transitions between milestones.
After applying these techniques to the AIC Issue Insurance process, Sue feels that she has
identified all of the potential decision points. She has updated the process diagram, which is
shown in Figure 4-7 (the decision points are called out with green check marks).
Figure 4-7 The five AIC decision points
Now she is ready to review these decision points with the rest of the team, and capture some
of their important properties. This information will enable the team to select and prioritize the
decisions that they will document as part of this project, and to lay out their decision discovery
roadmap.
4.4 Step 3: Identify and prioritize decisions for further

discovery
As described in Chapter 3, Getting started with decision discovery on page 21, once you
have identified your decision points, you will need to document some of the important
properties of each of them. This will enable you to assess which decisions should be
discovered and documented in greater depth, create the decision discovery roadmap and
assemble the decision discovery team. We touched on this in Chapter 1, Introduction to
decision discovery on page 1, Chapter 2, Introduction to IBM Blueworks Live on page 9
and Chapter 3, Getting started with decision discovery on page 21. Now we describe how it
is done.
4.4.1 Compose a decision

The AIC decision discovery team identified five decision points in their process diagram and
designated those as Decision Tasks in Blueworks Live: Prequalify Driver, Prequalify Vehicle,
Validate Driver, Validate Vehicle, and Price Policy. As you may recall, decisions are
associated with a process via the Decision Task, and as such may be reused across multiple
activities and processes, if necessary. The first thing Sue is going to do is to create some
decisions to associate with these Decision Tasks so that she can begin to capture the
high-level characteristics of each of them. In Blueworks Live, business artifacts (processes,
decisions, policies, and so on) are organized into what are called Spaces. And while decisions

can also be composed from the Decisions tab of the Blueworks Live Library, Sue goes to her
AIC Online space, as shown in Figure 4-8, to perform this task since she can easily see and
work with all of her project artifacts from here.
Figure 4-8 Creating a new decision in the AIC Online space
Sue presses the Create New button and selects to create a decision. This opens a compose
window for the decision, where she enters the name of the new decision Prequalify Driver, as
shown in Figure 4-9 on page 53. The best practice, in most cases, is to give the decision the
same name as the Decision Task. However, when a decision will be reused in different
activities or different processes, the Decision Task name should reflect the specific context
whereas the name of the decision will be a bit more generic. When naming decisions, we
follow a convention where the decision name = action (decision or calculation verb) + entity
(business object).
Decision and calculation verbs: See Chapter 3, Getting started with decision discovery
on page 21 for a review of decision and calculation verbs.
Figure 4-9 Compose a Decision
Sue goes on to create five decisions, one for each one of the decision points that were
identified previously. In Figure 4-10, you can see these newly created top-level decisions in
the Decisions tab of the Blueworks Live library.
Figure 4-10 Top-level decisions in Blueworks Live

4.4.2 Capturing key decision characteristics
Now Sue is ready to get back together with the team for the next decision discovery
workshop, where they will go through and document some of the important high-level
characteristics associated with each of these decision points:
The basic business description and rationale for the decision (name, description, decision
output, business motivation, business owner)
Sources of knowledge about this decision (experts and other sources)
Important business metrics associated with the decision (KPIs, decision volume)
Change dynamics of the decision (change frequency and latency)
Basic business information

The first thing that you should capture in Blueworks Live are the most fundamental pieces of
business information about the decision: what exactly is being decided (that is, the output of
the top-level decision), a brief description of the decision, the business motivation behind the
decision and the business owner.
Sue begins by opening up the Prequalify Driver decision diagram, and typing Driver
prequalified for Insurance? into the output name pop-up window on the top of the decision
box. Then, she opens the decision details panel as shown in Figure 4-11 to enter a
description of the decision.
Figure 4-11 Opening the decision details panel
She enters a description of the decision on the decision tab, as shown in Figure 4-12 on
page 55.
Figure 4-12 Entering a description of the decision
As Sue considers the business motivation behind this decision, she feels it is twofold: To figure
out if a driver might be eligible and to avoid sending for (and thus paying for) a DMV report for
a driver who is not eligible. So she enters this information into the Business Motivation slot of
the decision details panel.
Sue knows that it is the underwriters who have responsibility for ensuring that this decision is
made in accordance with AICs risk management policies, so she enters the VP of
Underwriting as the Business Owner. While Paul, the VP of Underwriting, himself might not
know all of the details associated with this decision, the underwriters on his team do. And it is
the VP of Underwriting who is ultimately responsibility for ensuring that this decision is being
made correctly.

Figure 4-13 shows where Sue entered this information about the decision details panel.
Figure 4-13 Entering the business motivation and business owner
Sources of knowledge
The next thing to do is to identify the sources of knowledge for this decision. You will need to
identify who knows the details of this decision best. Even if the decision is fully documented
already, in a policy manual, code, or program documentation, you want a person with whom
you can work, someone who can provide you with information that might not be documented.
Most documentation does not fully document decisions. Most of the time, documentation
reflects requirements. Requirements usually reflect what a system is supposed to do.
Decisions are about how a conclusion is reached. Usually, requirements documentation does
not include all of the context or logic that is necessary in order to fully define the decision. It
may not fully describe how a decision is actually applied, how a given piece of information is
used, in what context a decision becomes active, or details about how the conclusion is
actually used. There will almost always be gaps in the decision knowledge that comes from
documentation. That is why we recommend that you identify a person who has expertise in
the particular decision.
In general, there are four main sources of knowledge about a decision:

People
Operational documentation
Regulatory documents and policies
Computer system code
People
People, as previously mentioned, are always needed as a source. In some situations, people
are a source of context, that is, that they will help you understand how the documented
decisions are applied, and how the conclusions are used. In many cases, however, the
decisions might not be automated, and may be only sketchily documented. In this case, the
selection of people as sources is critical.
When identifying a person as a source, find the person who knows the decision best. This is
generally the person who makes the decision on a day to day basis. Usually this is someone
other than a manager. Often managers want to have input into the decision logic, and they
should, but it is the person whose work is to apply and make the decision day to day that will
be the best source of knowledge for the decision. Start with the person who does the work.
In the case of AIC, Sue, the head underwriter, makes underwriting decisions on a daily basis.
As the head underwriter, Sue gets the most difficult cases, and she may bring in another
underwriter to help when she is looking at simpler situations that she does not handle as
frequently. Sue will be an excellent subject matter expert to help document these decisions at
AIC.
Sometimes there is more than one person who does the work. Particularly when the work is
complex and when it is already significantly divided, you may need to identify different people
for different decision points, or even more than one person for a given decision point. Sue
does automobile insurance underwriting, but really is not an expert in real estate insurance. If
the project expands to include real estate insurance underwriting, she will need to bring in
another subject matter expert. In addition, though she knows much about pricing, she will
want to bring in someone from the accounting department to be an expert on that area, which
is not a primary concern of hers.
Managers, team leaders, and supervisors, while they are not primary experts, fill a couple of
really important roles in the process of discovering and documenting decisions. The first
occurs when there is more than one expert. It is almost inevitable that when working with
more than one subject matter expert, there will be a difference of opinion or understanding
discovered between them. It may be a major difference, or it may be a subtle difference of
emphasis. When this happens, it is important to fully gather and document each person's
point of view. Then, if a consensus between the experts cannot be reached, ask a third party
to make a decision as to how to reconcile the disparate views. Typically this is one of the
managers who is responsible for the policy on which the decisions are based.
Managers can also be invaluable as reviewers. Management invariably determines the

business objectives and policies behind a decision. Their staffs usually figure out the details
of how to achieve the business objectives and implement that policy. At AIC, the CEO and the
Board of Directors made the decision that the company would no longer raise rates based on
not-at-fault incidents. However, they did not specifically indicate how that change should be
implemented. Instead Sue and Ginny and their staffs had to figure out what that meant in
terms of the specific decisions. When decisions are clearly documented in plain business
language, managers, especially those who actually make policy, can be invaluable as
reviewers.

So as Sue considers how to document the sources of knowledge for the Prequalify Driver
decision, she realizes that she is the person that knows the most about this decision. But she
remembers that one of her fellow underwriters, Mark, works exclusively on applications from
military families, who have some special considerations, and she knows that she will have to
gather that information eventually. So she enters herself and Mark as the experts for this
decision, as shown in Figure 4-14.
Figure 4-14 Documenting the experts
Operational documentation
Various different types of corporate documents may exist that contain knowledge about a
particular decision. Manuals and work aids used by the people actually doing the work,
computer spreadsheets, memos, and computer program documentation are just a few
examples of operational documents that may describe how a decision is actually being made
and used within the daily operations of the business. They may contain references to, or
sections that describe corporate strategies or policies, but for the most part they support the
day to day operations.
The closer you get to the work of the person who is actually making or managing a given
decision, the higher quality the documentation will typically be. So work aids that are posted
on the walls of the cubicles are most valuable. Manuals and spreadsheets used by people
making decisions are the next. Program documentation is usually preferable to relying solely
on code. But it is often incomplete, incorrect, and may not address the decision directly.
Capture all of the documents, web pages, and other sources that contain knowledge about
this decision in the Sources field on the decision panel in Blueworks Live. You may want to
associate the actual source documents, excerpts from these documents or links to them with
the decision. This can be accomplished using the Documentation and Attachments tab on the
decision panel.
Sue enters the Underwriting Manual (attached) as a source of knowledge as shown in

Figure 4-15 Capturing sources of knowledge
Sue thinks it will be useful to have the entire underwriting manual attached to the decision for
easy reference, so she adds it on the Attachments tab by clicking Add at the lower left of the
dialog and selecting the appropriate file,
AIC_Underwriting_Manual_January_2013.odt, as shown in Figure 4-16.
Figure 4-16 Attaching a source document

In addition, Sue may want to capture an excerpt from Mark's memo on military drivers
because it contains some important information that is not in the Underwriting Manual. To do
this, she simply copies and pastes the memo text into the Documentation tab. If she wants to
provide a link to the memo on the AIC intranet, she can choose to insert a link on the
Documentation tab as shown in Figure 4-17.
Figure 4-17 Entering text and links in Documentation tab
Regulatory documents and policies

Decisions are frequently made in support of policies. Policies represent the more general,
overreaching goals and constraints on a business, and are typically expressed at a higher level
of detail than the decisions that apply them. For example, at AIC, the lawsuits related to
not-at-fault claims resulted in the CEO determining that the company should not raise rates
for not-at-fault accidents. Though it may sound like a decision, this is a policy. It is a very
general statement, and does not describe the details required in order to actually apply the
policy throughout the day to day business operations.
Sometimes, policies describe a legal or regulatory requirement. Often those requirements are
detailed and communicated in publications by government agencies or other legal
documents. Often policies refer to both decisions and process, and the boundaries between
them are not well delineated.
Policies are almost always incomplete, and require some thinking and analysis to identify and
document the decisions that result from them or that may be impacted by them. It is important
to validate documented decisions against any related policies to ensure that they are
consistent. Sometimes we can extrapolate decisions from policy, but not always.
For example, Sue of AIC is the lead underwriter. But she is trying to figure out the policy
regarding at fault or not at fault claims. So she went to talk with Chris, who works in claims
processing, because they are the ones that code the accidents.
Chris, she asked, how do you identify what is at fault and what is not at fault?
Well, Chris replied, as he sat down. Obviously if someone is charged in an accident, they
are at fault. And if the other person is charged they are not at fault.
Is that it? If the other person is charged then the applicant was not at fault? And all others
are at fault?
Not completely, said Chris, there are some situations where there is no other person to
charge and they are not at fault. Hit and run accidents, for example. I cannot tell you how
many people park in a hotel parking lot and wake up to find a big dent in their bumper, or in
their door. It happens all the time. And there is an act of God, like if a tree falls on the car in a
storm. Usually those are not at fault.
Usually? Do you mean there are times when an act of God is someone's fault?
Not the act of God, but the damage. If there is a hurricane coming through, and the person
leaves their windows open, that means they may have some responsibility for the accident.
We pay the claim. Chris smiled. But their insurance might go up. I don't know about the
pricing end though.
Policies like this one are almost always documented. For example, Chris shares with Sue his
policy manual, which contains all of the policies associated with how to determine fault in an
accident. You can document these as sources in Blueworks Live and attach them as
documents, text or links as we saw in the previous section. But if the policy is important,
widely referenced across your organization or related to multiple decisions you may want to
actually capture it as a Policy artifact in Blueworks Live. A policy artifact in Blueworks Live is
defined once, but can be referenced across any number of processes, process activities and
decisions.
A Policy artifact can be created in Blueworks Live from either the Policy tab of the library or
from the Space view. Sue decides that she will create a policy in Blueworks Live to document
the not-at-fault accident policy that so much of this project revolves around. She chooses
Create a Policy from the AIC Online space as shown in Figure 4-18.
Figure 4-18 Creating a new policy

When she presses Create, the policy opens and she is able to add a description and attach
reference documents and links to this policy, as shown in Figure 4-19.
Figure 4-19 Adding a new policy in Blueworks Live
Once a policy has been created in Blueworks Live you can associate it with any number of
processes, process activities, or decisions. And you can associate a process, process activity,
or decision with any number of policies. You can see how Sue has associated this new policy
with the Prequalify Driver decision, as shown in Figure 4-20.
Figure 4-20 Associating a policy with a decision
Computer system code
Last, and most certainly least, is the documentation of decisions in computer system code.
Business decisions are rarely well documented in computer programs. Deconstructing
computer code is a very labor-intensive process, and results in if-then statements that are at a
very low level of detail and are often quite technical. This makes it difficult to separate the
decision logic of the business decision from the technical implementation details. This is a
reverse engineering process that requires technical resources closely paired with business
resources. There are some software tools available to help identify business rules in
computer code in some programming languages, but these are not always as effective as one
might hope. They are also difficult for business people to use.
If you have no other documented source of knowledge for a decision, then you may choose to
identify the computer program as a source in Blueworks Live. You can certainly attach it as a
document to the Documentation tab. However, you will have to go through a completely
different process to analyze and extract the business knowledge from that code in order to
fully document the business decision. This paper does not address any of the techniques
required for such an exercise.
4.4.3 Business metrics

Next, we capture some important business metrics that will help us better understand how the
decision is used and evaluated within the organization.
Key performance indicators

When discovering and documenting decisions, it is important to understand how the business
measures the quality or effectiveness of any given decision. This way you can be on the
lookout during decision discovery for opportunities to improve the decision.
Decisions are made in support of business goals. In order to evaluate the effectiveness of a
decision, you need to be able to measure whether or not it is bringing your organization closer
to the achievement of those business goals. In order to determine this, you must be clear
about what the business goals are. In order to assess the quality or effectiveness of a
decision, you need to be able to measure its outcome in relation to these goals. This is
accomplished by defining the key performance indicators (KPIs).
KPIs are measures that quantify the business performance of an operational decision. In
addition to corresponding to clear business goals, they must be quantifiable. And in order to
compare and evaluate them, corresponding targets should be set for each. Some KPIs may
indicate quantity (for example, number of foreclosed loans over a period). Others may
describe directional measures that indicate whether a situation is improving or worsening (for
example, YoY % increase in sales revenue). And others may indicate progress, how close we
are to reaching a goal (for example, % complete code development).
So make sure and spend some time thinking about the business objectives and KPIs before
diving into the structure and logic of your decisions. And when you are documenting the KPIs,
try to make them as SMART as you can:
Specific
Measurable
Achievable
Result-oriented
Time-bound
Sue understands that one of the main goals of the Prequalify Driver decision is to identify
ineligible drivers early on so that the company does not have to spend money obtaining their

driving record report from the DMV. In essence, AIC is trying to minimize money spent on
obtaining unnecessary driving records. In trying to make the KPI SMART, she rephrases it as
Total cost per quarter of DMV reports requested for ineligible drivers. It seems to her that if
they capture this metric, they will be able to compare it from quarter to quarter in order to
ensure that they are improving. But then she realizes that if they increase their overall
business, and issue insurance policies to significantly more applicants, they may actually
increase the dollar amount spent on these unnecessary driving reports while achieving the
business objective. So she decides that a better KPI for evaluating the quality of this decision
will be Unnecessary driving reports requested per quarter (as a percentage of total driving
reports requested per quarter), and she enters this into Blueworks Live.
Sue also remembers that one of the main motivations behind introducing this prequalification
step was to get a quick quote out to engage applicants and keep them from shopping around
elsewhere while AIC was doing the full validation on the drivers and vehicles. AICs ability to
provide a preliminary quote before its competitors was an important competitive advantage
for the company. Sue feels that there should be a KPI to help them measure whether or not
this decision is being made in a way that is moving them in this direction. After discussing with
Mindy in the Marketing department, she decides to keep it simple. When they implement the
self-service web application, they can define something more sophisticated. For now, they
simply want to maximize the number of preliminary quotes they are making. She types in
Total number of drivers prequalified per quarter as the second KPI. See how Sue defined
these KPIs in Figure 4-21.
Figure 4-21 Entering the KPIs for prequalify driver
You may have noticed that the business goals that these two KPIs are designed to measure
progress towards appear to be in conflict. This is often the case with business objectives and
their related KPIs. In this case, for example, AIC management is trying to maximize profits
while minimizing risk. Measuring these KPIs will give them the information that they need to
better balance these objectives.
Decision volume
Capturing the frequency with which a particular decision is made within the organization can
be helpful for planning & prioritizing decision discovery and automation. If a decision is made
frequently, then it may be worth documenting for better understanding. It may also be a good
potential candidate for automation at some point in the future. Ideally, this metric is
documented as the number of times the decision is made over some period. For example,
twice a day, 300,000 times a week, 1,000 per hour, once a quarter. It can also be a good idea
to document any significant triggers that cause this decision to be made. In some cases, you
may not know the exact number of times the decision is made, but can document the
business events that drive it. For example, reviewing insurance claims for potential fraud may
be something that is done for approximately 10% of claims processed, based on a random
sampling. Blueworks Live also provides a subjective measure of decision volume (High,
Medium, Low). This is useful as a decision volume of 10,000 times a day may not be
considered high when youre talking about a processing a million credit card transactions a
day, but it may be considered very high in another situation where a total of 20,000 new
insurance policies are being issued each day.
Without researching, Sue does not know how many times a day the Prequalify Driver decision
is made, but she does know that it happens once for each application that is processed. She
can follow up later with Operations to find out how many applications are currently processed
per day. She considers a decision volume of once per application to be average, decisions
that occur multiple times per application to be high, and decisions made only on some
applications to be low. She enters this information into Blueworks Live, as shown in
Figure 4-22.
Figure 4-22 Decision volume

4.4.4 Decision change dynamics
The dynamicity of a decision the frequency and speed of change, is an important factor to
consider when identifying potential candidates for automation using Decision Management
technology. If a decision must be changed frequently (a pricing decision that is updated daily,
for example), or if it must be changed very quickly (for example, we have a short overnight
window to make these daily changes to the pricing decision logic), the agility afforded by a
Business Rule Management System or Decision Management platform can be very
compelling.
At AIC, the Prequalify Driver decision does not change very often. It is a pretty stable
decision. And when it does change, it does not have to be changed quickly. They typically
have a lead time of several months to implement significant policy changes that may impact
this decision.
Sue enters this information as shown in Figure 4-23.
Figure 4-23 Change dynamics of the Prequalify Driver decision
But as Sue documents the change dynamics of the Prequalify Vehicle decision, she sees a
very different pattern. Vehicle prequalification happens more frequently, since people can own
more than one vehicle. And Sue knows that there is new information coming out on vehicles
every week, sometimes several times a week. AIC is careful selecting the vehicles they will
insure, and they do not insure those vehicles that have a high likelihood of being involved in
accidents. That means they do not insure fancy hot-rods, or cars that have been converted to
run on a racetrack rather than just on the street. Nor do they insure trucks, only cars. And
while most pickups are considered cars for insurance purposes, some of the larger, more
industrial pickups, and the larger vans are considered trucks. AIC receives this information
from various sources. Sometimes it is in the form of a keyed list of VINs, sometimes a letter
about a model or make. Sometimes it is from a police report, and identified by tag number.
Sue knows that if a change to this decision would cause a car to be rejected rather than
accepted, AIC management wants the change to take effect immediately.
Sue records all this information in the decision details panel of the Prequalify Vehicle decision,
as shown in Figure 4-24.
Figure 4-24 Change dynamics of the Prequalify Vehicle decision
Given how dynamic this decision is, Sue decides to explore the change dynamics for
Prequalify Vehicle a little more deeply. What triggers the change to the decision? What policy
affects this decision? Who determines the need for change? What are the goals of change?
Are there situations that influence this change? At AIC, their rates, and thereby surcharges,
change every year, meaning that the decisions that support pricing change on an annual
basis. In fact, Monica, the accounting supervisor tells Sue that they have to register their
prices with the state insurance board, and cannot do that more than once every six months.
This means that pricing changes can only occur twice a year. And they usually have about a
three-month lead time on implementing these changes.
Changes to how they qualify vehicles and drivers, however, can happen at any time. They can
decide to insure someone or not to insure someone with a little more freedom, as long, Sue
says, as we do not break any non-discrimination rules. We cannot refuse insurance due to
race, creed, color, gender, and so on. But we can change the qualification decisions at any
time, both on people and on cars. Realistically, we do it more with cars. Remember when that
car company had that brake scare? For a couple of months, we required all of the affected
cars to have had the recall work done before we would insure them. That kind of thing is
allowed. So changing decisions about cars is pretty unpredictable. If there is a serious
problem with the car, if we are likely to be dealing with more liability with some models,
whenever we discover this, we change the list of car models that we do not insure.

Sue, don't we change our decisions based on the monthly analysis we do? asked Ginny, as
well. Yes, we get a statistical report from IT every month about our profits by car. Based on
that report, management decides whether we are going to stop insuring certain cars, or
change rates, or start insuring some cars again that are no longer on the bad list. They would
like us to respond immediately to those changes, but it usually takes a few weeks.
Not all decisions have clear triggers, but in this case Sue decides to capture this additional
information about the change triggers for Prequalify Vehicle on the decision Documentation
tab in Blueworks Live, as shown in Figure 4-25.
Figure 4-25 Documenting the change triggers for the Prequalify Vehicle decision
4.4.5 Preparing for in-depth decision discovery

Once Sue has documented the high-level characteristics of each of the five top-level
decisions, she associates them with the decision points in the process that had been
identified in the earlier on in the project. This way the team will be able to navigate directly to
a decision from the decision point in the process diagram. This will be helpful during the
workshop that they are having the next day where they will walk through each of these
decision points to decide which ones they will proceed to document in more detail. She
creates these associations by clicking each decision task in the process diagram, going to the
Decision tab and selecting the appropriate decision, as shown in Figure 4-26 on page 69.
Figure 4-26 Associating the Validate Driver decision task with the Validate Driver decision
Once selected, the decision appears on the Decision tab where it can be clicked to navigate
directly to the decision diagram, as shown in Figure 4-27.
Figure 4-27 The Validate Driver decision task associated with the Validate Driver decision

Selecting decisions for further discovery
In Chapter 3, Getting started with decision discovery on page 21 we discussed a set of
criteria to help identify and prioritize decisions for further discovery. You may want to quickly
review this before continuing on. Detailed decision discovery is a lot of work, so you do not
necessarily want to go ahead and do it for each of the decision points that you uncover. But it
is necessary to capture some high-level information up front about these decision points in
order to make that evaluation.
The AIC decision discovery team has gotten together to review their five decision points and
identify which ones they want to tackle. Sue has Blueworks Live open and projected onto a
screen so everybody can see. She is presenting, walking the team through what she has
captured for each decision point and making recommendations.
Throwing out cars and customers that we do not insure is really a fairly easy decision. We
have a list of the cars that we do not insure, and we only update that every year. Right now
the only customers that we throw out at this point are those who are under 18. While I could
imagine wanting to decide on cars based on something better than just a list, I really do not
think that we are ready for this.so I would say that this one should be a low priority for us
right now.
Deciding whether the driver and car qualify is a really complex decision, based on looking at
all the factors on the application, on the driver's record, and at some of the qualities of the car.
Now we usually only make changes twice a year, but when the state insurance board makes a
change, we usually only have a short time until it becomes effective. It is so difficult to go
back and review all the auto insurance policies that have been issued between the changes
becoming effective and the new code being implemented. Some of this decision is made by
the computer now, but most of it is done manually by the underwriters and the policy
adjusters, and they really understand these decisions well. In fact, sometimes when the
system is wrong they catch it. This one looks like a good choice to me.
Now the pricing decision actually involves three related decisions. We have to figure out a
base price for the car, adjust the price based on many factors, and then perform the actual
pricing calculation. Figuring out the base price for the car just comes from a table. That
usually changes every year, in January. We have this in a database, and it just gets pulled out.
I would say this one is low priority.
Adjusting the price requires consideration of many different pieces of information about the
customer and their driving record to determine what the price should be. Sometimes some
factors override other factors. Sometimes we back things out. I do not completely trust that
the system is doing it right now, but the worksheets to figure the adjustments out are so long,
I hate to keep checking the system answers. And when customers call to ask about their rate,
it would be really nice to know exactly how it is calculated. This looks like a good choice, too.
The calculation is easy once we come up with the base price and applied the adjustments. It
is just math. I think it might be nice to be able to see how it is done, but I am not sure that this
is a great choice.
The team discusses this for a while, and ends up agreeing that the best candidate decisions
for further discovery are Validate Driver, Validate Vehicle, and Adjust Price. However,
because they are not sure that the knowledge for adjusting the price is correct in their
organization, they decide to go ahead and get started with Validate Driver and Validate
Vehicle first. They will come back to Adjust Price after they have gotten more experience
and have had some initial success with their decision discovery efforts.
The decision discovery roadmap
Sue documents the teams recommendation, puts together a high-level project plan, and
packages this up with a PDF of the process diagram and a Word document containing the
decision point details. She sends this Decision Discovery Roadmap out to the management
team for their review, and schedules a meeting convening the stakeholders to review and
approve the project going forward. This will ensure that they have buy-in and visibility across
the organization, as well as the commitment for the team members to continue to invest their
time in this decision discovery initiative.
4.4.6 Summary
In this section, we learned how to capture the high-level characteristics of our decision points
in Blueworks Live, and how to evaluate those decision points to identify decisions that might
be worth additional discovery.
4.5 Step 4: Model the decision

Now that we documented the high-level characteristics of our identified decision points, and
decided which of these decisions to go ahead and document in depth, we are ready to begin
modeling the selected decisions.
As you may recall from Chapter 1, Introduction to decision discovery on page 1 of this
paper, a decision consists of:
An output - the conclusion reached, the option selected
Any number of inputs - the facts to be considered
The decision logic - which describes how the conclusion is reached, based on these facts
Decision modeling with Blueworks Live is an iterative process. We begin by capturing the
fundamentals of the decision: what it is and what it is deciding. Then we model the structure
of the decision: the information that is required to make the decision, and any other decisions
(that is, sub-decisions) that the decision depends on. Once we have a pretty good idea of the
overall structure of the decision, we go on to document the decision logic associated with the
decision and its sub-decisions. In practice, it is quite common to go back and forth between
modeling the structure of the decision and documenting the decision logic. As we delve into
the details of the decision logic we may discover that additional information or sub-decisions
are required to make the decision, in which case we will need to add new decision inputs or
sub-decisions to the decision diagram. This is the iterative aspect of decision modeling.
In this chapter, we see how Sue goes about modeling the Validate Driver decision in our AIC
example. You may find it helpful to refresh your memory by reviewing the concepts and
techniques described in the Model the Decision section of Chapter 3, Getting started with
decision discovery on page 21 before proceeding further.
4.5.1 Capturing the fundamentals of the decision

The AIC decision discovery team already captured basic information about the Validate Driver
decision when they initially documented the high-level characteristics for each decision point.
To refresh her memory, Sue brings up the Issue Auto Insurance process diagram in
Blueworks Live.

In Figure 4-28, you can see that Validate Driver was identified as a decision point in the
process diagram.
Figure 4-28 AIC Process Diagram with Validate Driver highlighted
She navigates to the Validate Driver decision point and opens the Validate Driver decision
task in the process diagram. There she can see that this decision task is associated with the
Validate Driver decision. She clicks the decision as shown in Figure 4-29 on page 73.
Figure 4-29 Navigating to the Validate Driver decision from the process diagram.
Clicking the decision brings up the Validate Driver decision diagram where Sue can see the
name of the decision Validate Driver, and the name of the decision output Driver eligible for
coverage?. When she right-clicks and selects Details from the menu, Blueworks Live opens
the Decision Details panel.

Clicking this Decision tab displays the description of the decision as shown in Figure 4-30.
Figure 4-30 Decision name, description, and decision output for Validate Driver
4.5.2 Documenting the decision inputs

Now that the basics of the decision have been captured, Sue can start modeling its structure.
She begins by identifying the inputs to the top-level decision and documenting them as either
data inputs or sub-decisions. Then she moves down to the next level in the decision diagram
and do the same thing for each of the sub-decisions she created. She continues to do this
until there are no more sub-decisions that need to be decomposed and all of the data inputs
for all of the sub-decisions have been captured. As mentioned earlier, modeling a decision is
a highly iterative process, so she will likely go back and forth between the different levels in
the decision diagram as she discovers additional decision inputs that need to be documented.
Identifying the information required to make the decision

In her review of the original process diagram in Blueworks Live, Sue sees that a couple of
important inputs had been identified for the Validate Driver decision task: The Insurance
Application form and the Drivers DMV report. Sue knows from her experience as an
underwriter that AIC considers a number of items from the application and the DMV report
when deciding whether or not to insure a particular driver. She starts reading the Driver
Eligibility section in AICs Underwriting manual to refresh her memory and makes some
notes about the information that is required to determine whether or not AIC can insure the
applicant or any other drivers that might be listed on the application:
The drivers age: AIC does not insure people under 18 except as additional drivers on their
parents' policies.
The drivers address: AIC does not insure people outside of their geographical coverage
area.
Whether or not the vehicle is kept in a garage: In high crime areas, this is a requirement for
AIC to be able to provide the applicant with coverage.
The drivers driving history: AIC will not insure a driver that does not have a good driving
history. AICs definition of this changes from time to time, but focuses on accidents, major
moving violations like DUI/DWIs and excessive speeding, and more recently, cellphone
driving infractions have been incorporated into this definition.
As she starts to think about how to capture Drivers Age in Blueworks Live, it seems
straightforward, she will just add Driver Age as a data input to the top-level decision, and a
little later, when she defines the decision logic, she will add a decision rule to the Validate
Driver decision table that tests Driver Age to make sure that the driver is at least 18. But then
she realizes that it is going to be a little more involved than that since they make an exception
for children of the policyholder.
Identifying any required sub-decisions

Because of this additional complexity, she decides to create a sub-decision that is called
Check Driver Age that will determine whether or not the drivers age meets AICs guidelines,
and produce a Yes or No result. She adds a sub-decision to Validate Driver by
right-clicking it and selecting Add Sub-Decision as shown in Figure 4-31. She could also use
the Add Sub-Decision button at the top of the diagram.
Figure 4-31 Adding a sub-decision to Validate Driver

She names the new sub-decision Check Driver Age, and types the name of the output,
Driver of Eligible Age? into the pop-up window on the top of the sub-decision, as shown in
Figure 4-32.
Figure 4-32 The Check Driver Age sub-decision
Sue knows that the drivers age from the application will be needed here, so she adds a data
input to Check Driver Age by right-clicking it and selecting Add Data Input, as shown in
Figure 4-33 on page 77. She could also use the Add Data Input button at the top of the
diagram.
Figure 4-33 Adding a data input to Check Driver Age

She adds the Driver Age as a data input. She knows that she will also need the Relationship
to Applicant field from the insurance application in order to determine whether or not the
driver is the applicants child. So she adds another data input for this, creating the decision
diagram that is shown in Figure 4-34.
Figure 4-34 Check Driver Age with its data inputs
Iterating across the decision diagram

Sue moves on to the next decision input she had listed in her notes for the Validate Driver
decision: the drivers address. AIC is a small insurance company and does not provide
insurance coverage everywhere in the country. They cannot issue insurance policies to
applicants that do not reside within their coverage area. Sue knows that their coverage area
has expanded over the years, as the company has grown. But she is not sure where that is
documented, or who is responsible for maintaining it, so she takes a walk down the hall and
knocks on a couple of doors. It turns out that AICs legal counsel is responsible for defining
and documenting the coverage area, and this information is published on the intranet as a
spreadsheet of ZIP codes.
Once again, this is a bit more complex than she originally thought, so she decides to add a
new sub-decision. She calls it Check Geographical Coverage and adds it to the decision
diagram along with the necessary data inputs, as shown in Figure 4-35 on page 79.
Figure 4-35 Validate Geographical Coverage with data inputs and high-level characteristics
Since the knowledge about AICs geographical coverage areas resides in their legal group, is
maintained in a different source document than the most of the other underwriting guidelines,
and has its own update frequency, she decides to capture some additional high-level
characteristics for this sub-decision. When she created the Check Driver Age sub-decision
she did not feel that this was necessary, as that sub-decision shares the same source
documents, business owners, and experts as the top-level decision, Validate Driver, so she
left those empty.

But for the Check Geographical Coverage sub-decision, she captures the additional
characteristics as shown in Figure 4-36.
Figure 4-36 Validate Geographical Coverage sub-decision with high-level characteristics added
Sue looks at her notes and moves on to consider the requirement AIC has for vehicles to be
kept in a garage if the driver lives in a high crime area. This is also a little more complex than
just checking a field from the application so she decides to create another sub-decision to
model it. Vehicle theft has been steadily increasing in recent years, and Sue has heard that
the management team is looking at the whole topic of theft protection more carefully. She
would not be surprised to see some new business policies created in this area in the near
future. Because of this, she decides to give this sub-decision a more generic name, Assess
Vehicle Theft Protection. This way, it will be easy to expand the sub-decision in the future
when new policies are introduced.
Once again, the applicant ZIP code will be needed, so she adds it as a data input. She
notices that Blueworks Live automatically merges the two instances of this data input, so that
applicant ZIP code only shows up once on the decision diagram, but it now has two
connecting lines to it: One from the Validate Geographical Coverage sub-decision, and one
from Assess Vehicle Theft Protection. Sue knows that the fact that a vehicle is garaged or not
comes directly from the application, and it can be either Yes or a No, so she adds this as a
data input to the sub-decision. But she is not sure how to tell if the driver resides in a high
crime area. She makes another visit to her co-worker down the hall in the Legal department
to see if he knows anything about it. It turns out that AIC subscribes to a service on the web
that consolidates and scores data from local law enforcement agencies, the FBI, and the
Department of Justice. You enter a ZIP code, and the website gives you back a High,
Medium, or Low ranking based on a calculated Crime Index. Sue adds a data input for this to
the decision diagram, and calls it Neighborhood Theft Risk, as shown in Figure 4-37 on
page 81.
Figure 4-37 Assess Vehicle Theft Protection added with data inputs (Applicant ZIP code shared)
As Sue looks at the last item listed in her notes, the drivers driving history, she realizes why
she left this one until last, there is a lot going on here. The report that AIC gets from the
Department of Motor Vehicles has a huge amount of information about it about the drivers
prior driving history. As she peruses the sections of the AIC Underwriting manual that
describe how the driving record is considered when deciding whether or not to insure a driver,
she takes some more notes:
AIC does not insure drivers that have more than two accidents that cost their insurance
company more than $500, in the last five years.
AIC does not insure drivers that have had more than one DUI/DWI infraction on their
record in the last five years.
AIC does not insure drivers that have had more than one excessive speeding violation in
the last three years.
AIC does not insure drivers that have had more than two cell phone use infractions in the
last three years.
Before beginning to model this in Blueworks Live, Sue decides to go and talk this through with
one of her fellow underwriters to get another perspective and help clarify her thinking. She sits
down with Mark, one of her fellow underwriters, to talk about it.
Mark, Sue says, the various criteria, accidents, DUIs, speeding tickets, cellphone
infractions, these all have to do with the report we get of the driving record.
Yes, Mark replied, but I have to say I do not think of them that way.
What way?
Well, as separate issues. I see that someone has a good driving record, or a bad driving
record, and all of these things are the contributing factors. And, in fact, some of these factors

may change from year to year. For example, the way we started incorporating cell phone use
infractions last year.
Yes, I think of it that way as well. I guess we need a higher-level decision here, since we
decide to insure someone based on whether or not their record indicates that they are a good
driver. And we consider a number of different factors when determining whether or not to
classify them as a good driver. You bring up a good point in that these factors can change
fairly often. I will keep that in mind when modeling this to make sure that it is easy to change
in the future.
Sounds good, Sue. Just let me know if there is anything else I can help with.
Thanks, Mark. I will definitely be coming back to ask you to review and validate the Validate
Driver decision before I send it out for formal review. Hopefully by the end of this week.
Sue goes back to her office, brings up Blueworks Live and adds the Analyze Driving Record
sub-decision. Rather than making the output a simple Yes, No boolean type, as she has
done with most of the previously defined sub-decisions, she names it Driver Profile. As far
as she is currently aware, there are only two possible values: Good and Poor, but she may
discover there are others or they may add others in the future so she wants to keep it flexible.
You can see how Sue modeled the structure of the additional required sub-decisions in
Figure 4-38.
Figure 4-38 Adding the Analyze Driving Record sub-decision (along with its sub-decisions)
Let us take a closer look at this new section of the decision diagram, with all of the data inputs
expanded (by toggling the Hide/Unhide Data Inputs option in the upper right corner of the
decision diagram), in Figure 4-39 on page 83.
Figure 4-39 The Analyze Driving Record sub-decision (with decision outputs and data inputs expanded)
As you can see, Sue has created a sub-decision called Analyze Driving Record that
determines whether the driver is a good driver or not based on various factors. Each of these
factors is addressed in detail within the four required sub-decisions: Evaluate Accident
History, Evaluate DUI/DWI Violations, Evaluate Speeding Violations, and Evaluate Cell
Phone Use Infractions. These sub-decisions look at the data about accidents, moving
violations, and infractions that comes from the DMV reports and determine how many of them
should be taken into consideration based on time frame, cost, severity, and so on.
Now that Sue has captured most of the information and sub-decisions needed for Validate
Driver, she is ready to start documenting the decision logic.
4.5.3 Documenting the decision logic

As was discussed in Chapter 3, Getting started with decision discovery on page 21,
Blueworks Live uses decision tables as the primary means of documenting decision logic. In
Blueworks Live, decision tables are organized by rows and columns, where each row is a
decision rule. A decision rule consists of one or more considerations and a single conclusion.
A consideration is basically a condition that when tested evaluates to either true or false.
Considerations in a decision table map to the decision inputs defined for a given decision or
sub-decision on the Blueworks Live decision diagram. However, the mapping is not always
one-to-one as a consideration may consist of a more complex expression involving more than
one decision input, rather than just a simple equality test. You may use any number of logical
or arithmetic operators when defining your considerations, and you may spell these out using
natural language rather than symbols if this will make your decision logic easier to
understand.
A conclusion is basically a value that is assigned to the decision output when all of the
conditions in the decision rule have been met (that is, evaluated to true). The conclusion
maps directly to the decision output defined for a given decision or sub-decision on the
Blueworks Live decision diagram.

Sue is not sure where to begin documenting the decision logic. She feels that she could start
with the top-level decision and work her way down, or she could start with the lowest level
sub-decisions and work her way up. Instead, she decides to start with Analyze Driver Record
and its required sub-decisions, as these are still fresh in her mind.
Analyze driver record

Sue opens the Analyze Driving Record by clicking the sub-decision in the Blueworks Live
decision diagram, and goes to the Decision tab to generate a decision table for it. To do this,
she presses the Create table using inputs and output button as shown in Figure 4-40.
Figure 4-40 How to generate a decision table in Blueworks Live
Blueworks Live then generates an empty decision table based on the data inputs and
sub-decisions that Sue recently documented in the decision diagram as shown in Figure 4-41
on page 85.
Figure 4-41 Empty decision table for the Analyze Driving Record sub-decision
Sue plans to put the logic around how to identify and add up the number of relevant
accidents, moving violations and infractions into the individual sub-decisions underneath
Analyze Driving Record. In Analyze Driving Record, she wants to make it very clear how AIC
identifies good drivers. So she looks at her notes and creates a decision rule that determines
when the Driver Profile is Good. To do this in Blueworks Live, she simply starts typing into
the empty cells in the decision table, positioning her cursor with the mouse or using the tab
key. This decision rule is shown in Figure 4-42.
Figure 4-42 Adding a decision rule to the Analyze Driving Record sub-decision

Sue inserts a new blank row into the decision table by pressing the + sign as shown in
Figure 4-43.
Figure 4-43 Inserting a new row into the decision table
She plays around with the decision table editor a bit to familiarize herself with the functionality,
and quickly figures out how to copy and paste rows, as well as drag columns, as shown in
Figure 4-44 and Figure 4-45.
Figure 4-44 The right-click menu for copying and pasting rows in a decision table
Figure 4-45 Dragging and dropping columns in a decision table to change the order of considerations
Sue thinks for a moment about how to document the Poor Driver Profile decision rules. She
knows that if one or more of the documented conditions are not met, then AIC considers the
driver profile to be poor. She does not want to create a decision rule for every possible
combination of values for each consideration, as it will make the decision table hard to read.
She could simply add an otherwise clause to indicate that any other combination of
consideration values leads to a conclusion of Poor. Instead she decides to create a few
decision rules, each one highlighting one of the conditions that will cause the driver to be
viewed negatively. She feels that this will be the clearest way to document this logic, ensuring
that it is well understood by anybody reading it. To accomplish this, she makes use of empty
cells. An empty cell in a decision table indicates that it does not matter what the value is for
that cell; the consideration will always evaluate to true. See Sues completed decision table
in Figure 4-46 on page 87.
Figure 4-46 Adding the decision rules to the Analyze Driving Record sub-decision that reach a Poor conclusion
Sue moves on to define the decision logic for the sub-decisions that Analyze Driver Record
depends on. This involves identifying and adding up the incidents from the DMV report that
will be analyzed in Analyze Driver Record. She is a little unclear on how best to document this
decision logic. She wants to stay focused on the business requirements, and it seems to her
that the logic of counting is really more of an IT requirement that has to take into account the
structure of the data coming from the DMV, how the records are coded for the different
incident types, and so on. She decides to go talk to Ginny about it to see if she can get some
guidance on this.
Ginny, I am not sure what to do with the DMV reports right now.
What is the problem?
Well there are a lot of things that we count, like the number of accidents, cellphone
infractions, DUIs, and speeding tickets. I have created a sub-decision for each type of
incident, but am not sure how best to document the aggregation of them.
What do the inputs and outputs to those sub-decisions look like? asks Ginny, as she opens
the decision diagram in Blueworks Live on her desktop computer.
You can see that the output of each of those sub-decisions is the total number of eligible
incidents: Total number of chargeable accidents, Total number of recent DUI/DWIs, Total
number of recent speeding violations, and Total number of recent cell phone use infractions
says Sue. The data inputs are the dates of the incidences (Accident Date, Violation Date,
Infraction Date), the accident cost, the violation, and infraction types, and so on. Im afraid
that if I get into describing the logic of counting and the coding of the driver records, that it is
really outside of the scope of my expertise and it becomes more about the IT requirements
rather than the business requirements. I would prefer to just identify which incidents need to
be counted.
Actually, Sue, I think that would be just fine. says Ginny, The mechanics of counting are
really something that the developers can address when the time comes to implement the
decision logic, and our systems analysts are quite familiar with how the data in the DMV

records is coded; they deal with it all of the time. You do not need to figure that low level IT
stuff out. Rather than documenting how we should do these things, just focus on documenting
what the business requirement is. We will figure out how to do it. Does that make sense?
Sue smiled. I got it Ginny. Thanks.
When Sue gets back to her office, she documents the decision logic for the Evaluate Accident
History sub-decision in Blueworks Live. Only accidents that occurred in the last five years,
and that cost the insurance company over $500 are considered when they evaluate the
accidents on the DMV report. Sue documents this simply and succinctly in natural language
using a single decision rule, as shown in Figure 4-47.
Figure 4-47 The decision rule for adding up accidents considered when evaluating driving history
The decision logic for the rest of the sub-decisions under Analyze Driving Record are very
straightforward. Sue generates the empty decision tables and documents the decision rules
as shown in Figure 4-48 on page 89, Figure 4-49 on page 89 and Figure 4-50 on page 90.
Figure 4-48 The decision rule for adding up DUI/DWIs considered when evaluating driving history
Figure 4-49 The decision rule for adding up speeding tickets considered when evaluating driving
history

Figure 4-50 The decision rule for adding up infractions considered when evaluating driving history
Validate driver
Now that Sue has finished modeling Analyze Driver Record, she just has the top-level
decision and three more sub-decisions left to complete the decision logic for Validate Driver.
She is curious to see what the decision logic for the top-level decision is going to end up
looking like, so she decides to work on that before documenting the remaining sub-decisions.
This is the top-level decision that will look at all of the different aspects of the decision: The
driving history, drivers age, drivers address, and the vehicle theft protection and decide
whether or not AIC will insure the driver. Sue generates the empty decision table and begins
to enter the decision logic. She enters the first decision rule, which identifies drivers that are
eligible for coverage, and decides to take a similar approach as she did with the Analyze
Driver Record sub-decision. That approach was to not document all of the possible
combinations of cell values, nor use the otherwise clause, but rely on empty cells to highlight
the important considerations. You can see the decision table that Sue created in Figure 4-51
on page 91.
Figure 4-51 The decision logic for the top-level decision: Validate Driver
Check driver age

Next, Sue generates the decision table for Check Driver Age and adds the decision logic. She
creates a decision rule that identifies everybody who is 18 or older as being of eligible age.
She creates another rule to accommodate teen drivers being covered on their parents
policies. Then she creates a final decision rule rejecting anybody under 18 years of age that is
not a child of the applicant. You can see how she defines this in Figure 4-52.
Figure 4-52 The decision logic for Check Driver Age

Check geographical coverage
AIC does not issue insurance policies to applicants that do not reside within their coverage
area. As we learned earlier, the geographical coverage area is defined as a list of ZIP codes
in a spreadsheet maintained by the legal department. As Sue considers how to define the
decision logic for this decision, she knows that she needs to express the business
requirement, rather than the low-level details of extracting ZIP codes from a spreadsheet or
doing a ZIP code lookup operation on a database. A link to the current version of this
spreadsheet has already been captured in Blueworks Live, so it will be very easy for anybody
trying to automate this later to figure out exactly how to do so. Sue creates a simple, clear
decision rule to accomplish this, as shown in Figure 4-53.
Figure 4-53 The decision logic for Check Geographical Coverage
Assess vehicle theft protection

Sue considers the requirement AIC has for vehicles to be kept in a garage if the driver lives in
a high crime area. This is a little complicated, since the determination of an area as a high
crime area is provided by an external service, based on the ZIP code. Once again, she wants
to keep the decision logic focused squarely on the business requirement, rather than getting
into the details of web service calls or database lookups. So she comes up with the
representation shown in Figure 4-54 on page 93.
Figure 4-54 The decision logic for Vehicle Theft Protection
4.5.4 Reviewing the decision

As Sue views her finished diagram in Blueworks Live, she finds the zoom tool and View
mode very helpful. With the zoom tool, which is located in the upper right corner of the
decision diagram, Sue is able to view her entire diagram on the screen at the same time, as
shown in Figure 4-55 on page 94.

Figure 4-55 Reviewing the final decision diagram in Blueworks Live
When she presses the End Edit button, in the upper right corner of the screen, Blueworks
Live switches into View mode. Here, she is able to see the details of any sub-decision or
data input that she selects in a separate pane on the right side of the screen, as shown in
Figure 4-56.
Figure 4-56 Reviewing the final decision diagram in Blueworks Live
As she reviews all of the components of the Validate Driver decision, she feels that she has
captured all of the data inputs, modeled all of the necessary sub-decisions, and documented
the related decision logic. She is now ready to distribute to the team for broader review.
4.6 Step 5: Validate the decision
Engaging subject matter experts and stakeholders in the review and validation of decisions
will help ensure that your documented decisions are correct and complete. Much of this
validation occurs naturally during a decision discovery project as a result of the collaboration
between the different members of the decision discovery team. This process is iterative and
highly interactive and almost always results in changes being made to the documented
decision, especially in the earlier stages of the project. However, it is also important to have
some kind of final, formal validation step where key stakeholders can review and approve the
final documented decision.
In this section, we discuss some tools and techniques that are helpful for working with others
to validate decisions both formally and informally. And we learn about an easy way to use
Blueworks Live to manage and log the formal validation of decisions.
4.6.1 Collaboration
Everybody involved with the decision discovery project at AIC needs to collaborate. They
need to be able to review each other's work, provide feedback related to that work, make
suggestions for how to describe, and document the decisions, make updates directly to the
decision documentation, and sometime even change each other's work. Blueworks Live
provides a number of features that support this kind of collaboration, including:
Activity Stream
Chat
Comments
The activity stream

The activity stream in Blueworks Live provides a dynamic view into the work taking place on a
decision discovery project. The decision discovery team members at AIC can see the details
of changes made to the decisions in the AIC Online space, who made these changes and
when they made them. They can view this information by date or by user, and they can
expand and collapse the changes to show more or less detail. They can also post messages
to the activity stream, which enables them to broadcast important project-related information
to the whole team. The activity stream has quickly become an information hub for the decision
discovery project team at AIC.

You can see some of the information available through the Blueworks Live activity stream in
the left pane of the screen capture, as shown in Figure 4-57.
Figure 4-57 The activity stream
Chat
Ideally, your decision discovery team is co-located in the same general area to facilitate
efficient communication and collaboration. However, in this day and age that is often not
possible. Blueworks Live provides an online chat capability that can help distributed teams
with informal communication and ad hoc collaboration. The AIC team is co-located on the AIC
campus, but they work in different buildings. When Sue is working in Blueworks Live, she
frequently uses the online chat when she needs to ask a teammate a quick question, find a
good time to meet or let a co-worker know that she would like for them to informally review
some of her work. And she often finds herself responding to similar chats from her
teammates. The Chat function can be unwieldy for comprehensive, in-depth communications
and the history of a communication thread is not retained so Chat is best used for quick,
informal interactions. Quick questions, straightforward coordination and notification, and
checking in with teammates are all great uses of the Blueworks Live Chat function.
To initiate a chat, the person you want to communicate with has to be logged in to Blueworks
Live. You can see the names of people that are online at the lower right corner of your
Blueworks Live screen. If you click one of those names, you get a pop-up window, which
shows you what they are currently viewing in Blueworks Live, as shown in Figure 4-58 on
page 97.
Figure 4-58 Opening a chat window
When you start a chat, the chat window opens, as shown in Figure 4-59.
Figure 4-59 The chat window
In addition to being able to type a text message into the chat window, you can send a link to
the page that you are viewing as depicted in Figure 4-60 on page 98. If Ginny clicks the link
that Sue sent her in the chat window, she will automatically navigate to that same page. In the
example below, Sue is making some changes to the Pricing decision diagram that she would
like some informal feedback from Ginny on. When Ginny clicks the link and navigates to the
decision diagram, she will see the changes that Sue is making to the decision diagram in real

time. And, of course, if Ginny makes any changes, Sue will see those in real time. Chat can
be a very effective tool for collaborating dynamically and getting on the same page.
Figure 4-60 Getting on the same page sending a link via online chat
However, for more significant interactions, you will need a permanent, threaded,
context-sensitive way to communicate around decisions that are being documented and
reviewed. Comments, in Blueworks Live, work well for this purpose.
Comments
We have already seen comments in action in Blueworks Live. The advantage of comments is
that they are context-sensitive, that is, the comment is made and attached directly to the
decision, activity, or process being documented or reviewed. Sue can use comments as a
way of leaving notes for herself to help with her work. For example, she may want to remind
herself of some additional tasks she needs to perform or some additional documentation she
needs to obtain before she can finish documenting a particular decision or process activity. But
comments can also be tremendously useful for collaborating with others when reviewing and
validating decisions.
As we saw in the last section, Sue started a chat with Ginny to request some preliminary
feedback on an early draft of the Pricing decision that Sue was beginning work on. When Ginny
reviewed this Pricing decision, she was happy to see that it considered whether or not the
driver had been at fault for accidents that could have an impact on the premium price. When
Ginny reviewed the Validate Driver decision, it did not appear to her that this was being
considered when evaluating the drivers accident history for eligibility purposes.
Thinking that she may have discovered yet another area within AIC where this determination
of fault was not being properly taken into consideration, Ginny immediately brought it to the
teams attention by adding a comment. She navigated to the Evaluate Accident History
sub-decision of Validate Driver, and pressed the Add Comment button in the pane on the
lower right side of the window bringing up the Add Comment dialog, as shown in
Figure 4-61 Adding a comment on the decision diagram
Comments can also be captured on the Comments tab of the Decision Details panel.
Comments are displayed, in context, when a sub-decision is selected in the decision diagram in
View mode, as illustrated in Figure 4-62. They are also displayed in the Activity Stream for the
entire space. And team members can reply directly to a comment wherever they appear.
Figure 4-62 Comments show up in context, when navigating a decision diagram in View mode
4.6.2 Revising and refactoring decisions

Soliciting feedback from others during collaboration, decision review, and validation frequently
results in updates being made to a decision. Sometimes the changes are minimal, other times
major, and the impact of those changes usually needs to be carefully assessed before the
changes are made. Especially once a stable, approved version of the decision exists. This
becomes even more important if the decision has been automated, as the potential negative

impact of the unforeseen side-effects of a change that was not thoroughly thought through
could be significant.
Impact analysis
In the last section, we saw an example of the kind of feedback you might receive during the
informal review of decisions. Ginny left a comment on the Validate Driver decision diagram
asking if the determination of fault was being considered when evaluating accidents on the
drivers record. Sue does not remember, and she is not sure how that was handled in the
Pricing area. So she goes to the Blueworks Live Glossary to do some impact analysis and
refresh her memory.
The Blueworks Live Glossary provides visibility into the values of properties defined for
decisions, processes, spaces, and tags. Particularly useful is the ability to see the values of
all of the inputs and outputs of decisions and process activities. Also very useful is the Where
Used capability, which allows you to see which spaces, processes, activities & decisions any
given input or output value is being used in.
Sue opens the Glossary tab of the Library in Blueworks Live, and types in fault as a Filter
string as shown in Figure 4-63. Blueworks Live shows the number of items that contain the
string fault on the right of the screen, in the blue ovals. She expands the Inputs & Outputs
section and sees the term Driver at Fault along with its definition, which jogs her memory.
She recalls that there is a boolean field on the DMV report for every accident indicating
whether the driver was at fault or not. She is curious as to how and where that is being
referenced within AICs documented business processes, so she selects the Where Used
tool, to the right of the glossary term as shown in Figure 4-63, and learns that the Driver at
Fault term is being used within the Pricing Additions and Subtractions decision. Blueworks
Live lists the actual sub-decision that uses this term as a data input, and provides a link to it,
Figure 4-63 Filtering business terms in the Blueworks Live Glossary, and seeing where they are used
Sue clicks this link and navigates to this sub-decision in the decision diagram, and sees that
the Driver at Fault term is used as a data input. As she reviews the diagram, it is clear to her
how fault is factored into the assessment of accidents used to adjust the premium price. This
decision diagram is shown in Figure 4-64.
Figure 4-64 Linking directly to the sub-decision where the Driver at Fault term is used
Now that she has seen how driver fault has been factored into this pricing decision, she
updates Validate Driver to do the same. This is very straightforward because she only has to
change one sub-decision. She is glad she created a separate sub-decision for each incident
type as it definitely makes it easier to figure out what exactly needs to be changed. It is also
easier to make the change because the impact is isolated to a single sub-decision. She
navigates to the Evaluate Accident History sub-decision, adds Driver at Fault as a data input
and inserts a new column for it in the decision table, as shown in Figure 4-65.
Figure 4-65 Inserting a new column into the decision table for the Driver at Fault data input
Now Sue feels confident that the Validate Driver decision is properly taking fault into
consideration when evaluating the drivers accident history.
Major refactoring of a decision
Sometimes revisions can result in significant reorganization of the structure of a decision. It is
fairly easy to add a sub-decision to a decision diagram if needed, or a data input. But
sometimes structural changes may occur at higher-levels of the decision diagram impacting
the top-level decision, or in the process diagram impacting the decision task.
This happened during the AIC decision discovery project, while Sue was in a review session
with Paul, Megan, and Ginny.
Paul asked, Sue, I understand why we do pre-qualification before we do validation. That is

so we will not spend money on DMV reports when we do not have to. And I understand why
we prequalify drivers before we prequalify vehicles. It is more complex to get the vehicle
information: VIN numbers, dates, and so on. We do not want to ask these questions of
drivers if we are not qualifying them. It is annoying and they leave with a bad feeling. They are
potential future clients, if the issues that currently make them ineligible change. But I cannot
understand why, when we already have all the information, including DMV reports, we validate
drivers before we validate vehicles. Is there something produced by Validate Driver that the
Validate Vehicle decision needs?
I am really not sure, Sue replied. I never thought about that. I just knew we did it that way,
not exactly why. When we are reading the validation report, it is in that order. But I do not
know of anything in Validate Vehicle that requires anything from Validate Driver.
Ginny spoke up, a little sheepishly. Actually, I think I know the answer to this one. When
Steve, one of the original programmers, came back from retirement to help us with the Y2K
updates back in 2000, I took the opportunity to walk through the system and learn some of the
reasons some design choices were made. It happens that these two decisions are
implemented in two different programs that were written by two different programmers. They
just decided it was easier to execute one before the other. There is no dependency that I
know of. We always do both steps, and it does not matter what order they are in.
So what we are really doing is validating the whole application, right? Paul asked.
Right. Sue and Ginny spoke almost in unison.
Sue, Megan asked, Is there any sort of time dependency? Would it work if we validated the
vehicle first?
Yes, Megan, Sue replied, we could do the vehicle first. In fact, sometimes I do when I am
auditing these. We have to validate each driver on the application, and we have to validate
each vehicle on the application. But maybe those should actually be sub-decisions? I guess
the ultimate decision that we are making here is whether or not we are going to approve the
application, and that is not reflected anywhere in the decision discovery work we have done.
That makes a lot of sense. said Paul. Can you go ahead and make those changes?
Oh, sure, said Sue, wondering how she would do it.
As you can see from this interaction, many ideas come into play when collaborating, reviewing
and validating decisions. At AIC, a number of people at different levels of the organization
were involved at different points in the project to collaborate, review work, and provide
feedback. We had the business owner, Paul, the IT director, Ginny, and a peer, Megan, each
with their own point of view. They brought their different perspectives, expertise, and
experience to the table to help ensure that AICs documented decisions were correct and
complete. And they applied the best practices that they had been learning to their decision
discovery work. This is quite typical of what you might actually experience when collaborating,
reviewing, and validating decisions on a real decision discovery project.
So, we follow Sue as she goes about refactoring her decisions to create the new Validate
Application decision.
The first thing she did was to make a copy of the Validate Driver decision, as shown in
Figure 4-66, which she will use as the basis for her new decision. This way, she still has the
original decisions intact and can refer or even revert back to them if she needs to. Because
Sue was a little unsure of what she was doing, she wanted the older decisions to remain as
references. She might archive them later.
Figure 4-66 Copying the Validate Driver decision
Sue renames the copied decision Validate Application and saves it in the AIC Online space,
Figure 4-67 Renaming the copied decision
Sue opens the decision diagram in edit mode, as shown in Figure 4-68 on page 105, and
begins to modify the top level decision, changing the name of the output to Application is
Valid, and updating the high-level characteristics as needed (Description, KPIs, and so on).
She needs to re-create Validate Driver and Validate Vehicle as sub-decisions underneath the
Validate Application decision, and she would like to do this with as little rework as possible.
Figure 4-68 Sue begins to refactor the new Validate Application decision
She adds a new sub-decision under Validate Application as shown in Figure 4-69.
Figure 4-69 Adding a new-sub-decision to Validate Application
She renames the sub-decision Validate Driver and updates the name of the decision output
to Driver eligible for coverage?, as shown in Figure 4-70. Now she will move all of the
sub-decisions that are underneath Validate Application so that they are under Validate Driver,
thus re-creating the same structure that the Validate Driver decision had before it became a
sub-decision of Validate Application.
Figure 4-70 Creating the Validate Driver sub-decision under Validate Application
To accomplish this, she simply drags and drops each sub-decision onto Validate Driver, and it
automatically becomes a sub-decision underneath it. When the border around the dragged
sub-decision becomes green, and the border around the target sub-decision becomes orange
in the Blueworks Live decision diagram, this means that the sub-decision can be dropped, as
shown in Figure 4-71 on page 107.
Figure 4-71 Dragging and dropping one sub-decision onto another
Once the sub-decision is dropped, the decision diagram looks like the figure below. To
remove the extra dependency line Sue right-clicks the orange line and selects Delete as
shown in Figure 4-72.
Figure 4-72 Deleting the extra dependency line from the Analyze Driving Record sub-decision
Once Sue removes the dependency line, the decision diagram looks like Figure 4-73.
Figure 4-73 The refactored Analyze Driving Record sub-decision
Sue continues dragging and dropping the other sub-decisions, and deleting the extra
dependency lines until her diagram looks like Figure 4-74.
Figure 4-74 The refactored Validate Driver sub-decision
Finally, Sue generates the decision table for Validate Driver and enters in the decision rules,
once again, as shown in Figure 4-75.
Figure 4-75 Re-creating the decision table for the new Validate Driver sub-decision
Sue goes through a similar exercise, incorporating the Validate Vehicle decision into this
diagram as a sub-decision of Validate Application. She reviews her work and checks the new
Validate Driver and Validate Vehicle sub-decisions against the original versions to make sure
they are correct.
The final, refactored Validate Application decision is shown in Figure 4-76.
Figure 4-76 Figure x: Refactored Validate Application decision
4.6.3 Versioning decisions

After all of the hard work and collaboration that the AIC decision discovery team has put into
discovering and documenting the Validate Application decision, Sue feels that they finally
have a solid version of the decision that can be sent out for formal review and approval. But
before doing so, she wants to create an official version of this decision that reflects the work
done up to now. And this is the version that she wants the stakeholders to review and
approve.
Blueworks Live has a Revision History feature that enables you to take a snapshot of a
decision at any point in time, and give that snapshot a name. The snapshot is saved in the
Blueworks Live repository and can be previewed at any point. It can also be restored, in which
case it again becomes the current version of the decision.
Throughout the course of the project, Sue has occasionally taken personal snapshots of her
work as backup, in case she made mistakes and needed a way to easily back them out.
Blueworks Live has an Undo button, which lets her back out one change at a time, but
having her personal snapshots made her feel more comfortable when making a large number
of changes. At this point, however, she is ready to create a project snapshot that will be the
version of the decision that everybody reviews and works with going forward. Sue clicks the
Revision History button on her Validate Application decision diagram and creates a
snapshot that she names Version 0.9 Out for Review, as shown in Figure 4-77 on
page 111 and Figure 4-78 on page 111. When she has gotten the official sign-off from the key
stakeholders, she will create a 1.0 version of the decision. Now she is ready to send the
decision out for formal review and approval.
Figure 4-77 Creating a named snapshot in Blueworks Live
Figure 4-78 The new snapshot becomes the new version of the decision
4.6.4 Sharing decision information

There are many situations where it can be useful to access or share decision information
outside of Blueworks Live. For example, Sue may need to work somewhere where she does
not have access to the Internet. She may need to interact with co-workers who do not have
access to Blueworks Live. The AIC team may be holding a decision discovery workshop
where they want to have larger printouts of the decision diagrams up on the walls for
everybody to be able to easily see and discuss. There are several tools in Blueworks Live that
can help with this.
Creating a PDF version of the decision diagram
You can generate a PDF version of any decision diagram in Blueworks Live, then choose to
either share the PDF file or print it. In Figure 4-79, you can see how Sue navigated to the
upper right corner of the decision diagram, and is clicking the Print button.
Figure 4-79 Printing the decision diagram
Blueworks Live will generate a PDF version of the diagram, which she can either save to
distribute or to view later, or she can go ahead and print. She has the option of choosing
various sizes when printing the diagram as shown in Figure 4-80.
Figure 4-80 Printing the PDF
Exporting a decision to Excel

Blueworks Live can also export all of the individual elements that make up a decision to
Excel. This includes everything from the high-level decision properties (KPIs, Decision
Volume, Change Frequency, and so on) to the data inputs, sub-decision outputs, and decision
tables.
As the decision discovery project at AIC nears completion, Ginny schedules a meeting with
her IT lead, Prasad, to discuss the possibility of improving their system by automating some
of the decisions that they have documented. To prepare for this discussion, she exports the
Validate Application decision to Excel by selecting from the drop-down menu immediately to
the right of the decision, as shown in Figure 4-81 on page 113. She can do this from either
the Space view or the Decision tab of the library.
Figure 4-81 Exporting Validate Application Decision information to Excel
There is quite a bit of information available in the exported Excel spreadsheet. In Figure 4-82,
you can see the Decision Tables tab, which Ginny finds particularly useful for her discussion
with Prasad.
Figure 4-82 The exported decision information in Excel
Exporting a decision to Word

Decision information can also be exported in the form of a Microsoft Word document. The
generated Word document is organized more like a report than the Microsoft Excel export, so
can be more suitable when distributing a decision for review.
You can export to a Word document either from the right-click menu of a decision in the
library, or from the upper right corner of the decision diagram, as shown in the Figure 4-83
and Figure 4-84.
Figure 4-83 Exporting to Word from the right-click menu in the library
Figure 4-84 Exporting to Word from the decision diagram
The exported Word document contains all of the decision details.
Getting a link to a decision

Sharing a link to a decision can be very useful because it enables the recipient to navigate
right into Blue works Live and view the decision directly. Of course, the person you are
sharing the link with must have access to Blueworks Live in order to be able to access the
decision diagram. To get a link, right-click the top-level decision, or any sub-decision or data
input on the Blueworks Live decision diagram.
In Figure 4-85, you can see Ginny getting a link to the Validate Application decision. She will
then copy and paste that link into the meeting invite that she sends Prasad so that he can
familiarize himself with the decision before their meeting.
Figure 4-85
4.6.5 Formal validation of decisions

Sue has collaborated with a number of people within AIC throughout the decision discovery
project and some of them have been involved informally validating her work on an ongoing
basis. Now, as she considers who should provide formal validation of the Validate Application
decision, she identifies the following people:
Paul: Her boss and CEO. In this small company, he is also the business owner of this
decision.
Mark and Megan: Fellow underwriters with knowledge of the decision.
Ginny: The head of IT, who is also the owner of the decision discovery project.
Of course, Paul and Ginny are quite busy running AIC and will likely delegate some of their
review. But they are ultimately the ones that will have to sign off on the final decision, thus
assuming ownership and accountability for it.
Decision validation with Blueworks Live

Blueworks Live provides the ability to configure, launch, and monitor simple workflows. Users
can select and configure an existing process template, such as an approval or checklist from
the supplied library. This capability can be very useful for initiating and tracking the review and
approval of decisions. Let us look at how this works.
Configuring a review and approval workflow
The Work page in Blueworks Live is where you go to automate simple processes, see any
tasks assigned to you, and to check the status of any workflows that you initiated. To configure
a review and approval workflow, press the Automate a Process button on the right side of the
Work page as shown in Figure 4-86.
Figure 4-86 Automating a process
You can also do this from the Library or Space view by pressing the Compose New button
and selecting Process App from the drop-down list box. In either case, the following dialog
will appear and prompt you for the name and the type of Process App you would like to
configure. For a review and approval workflow, you select simple workflow as shown in
Figure 4-87.
Figure 4-87 Creating a process app
You will then be asked to configure the Process App and will be presented with a template to
complete. As you can see in the following diagram, we are configuring the Request for
Decision Review process app. Each piece of information required by the template is
described in the callout to the left of each field in Figure 4-88 on page 117.
Figure 4-88 Configuring a process app
Once configured, the process app can be shared and appears as an action on the right side
of the Work page. The name of the action will correspond to whatever action label was
provided in the template. Users can then choose this action to launch the process app to
create, assign, and manage tasks as is described in the following section.
Launching a review and approval workflow
The Request for Decision Review process app has already been pre-configured by
somebody on Ginnys team. Now that Sue is ready to send the Validate Application out for
final validation, she finds this process app in the Team Sandbox space and opens it up for
work, as shown in Figure 4-89.
Figure 4-89 Finding the Request for Decision Review process App
Sue completes the request by providing the decision name, a brief message to the reviewers
and approvers, and a link to the decision (which she copied and pasted from the decision
diagram). She selects the names of the individuals that she is requesting review or approval
from, specifies the deadlines and launches the process app. You can see Sues request in
Figure 4-90 Launching a Decision Review Request
When Sue presses Launch at the bottom of the window, this kicks off the workflow and sends
out task assignment notifications via email to the designated individuals. Once notified, they
can manage their tasks in the Blueworks Live Work pages. Here they can view and complete
tasks that have been assigned to them, leave comments, attach documents, and reassign
their tasks if need be. The other participants will be able to see these comments and
attachments. And Sue can monitor the progress of tasks in this workflow from the Work pages
to make sure that everybody completes their tasks on time, so they can meet their project
deadlines.
Once any reviewer feedback has been incorporated into the decision, Sue will create a
baseline 1.0 version of it and notify the extended team. She feels that this has been a really
interesting project. She has learned a lot, and thinks that having the documented decisions
available along with AICs documented business processes in Blueworks Live will improve
their business operations going forward. And when they are ready to automate those
decisions, she is sure this decision discovery work will prove to be invaluable.
4.6.6 Next steps at AIC

Once a decision has been validated, it is important to govern (that is, manage) any changes
made to it. The next step for AIC, now that they have discovered, documented, and validated
their key decisions, will be to set up some sort of governance framework for the discovered
decisions:
They will need to put in place a well understood lifecycle for future decision changes.
They will need to identify the specific individuals and organizational roles that will be
allowed to make changes to decisions.
They will need to formally define the validation process for future decision changes.
They will need to log and retain a record of updates to their key decisions.
We will not be following AIC on this next step of their journey because this paper is focused on
decision discovery and we have reached the end of that topic.
4.6.7 Conclusion
We hope that this Redpaper publication has equipped you with a basic understanding of
some of the fundamental concepts, techniques, and benefits of decision discovery. We also
hope that you have gained an appreciation for how a tool like Blueworks Live can help
facilitate the decision discovery process.
We began with an overview of decisions, and an introduction to Blueworks Live. You learned
how to identify the decision points in your business processes and how to capture the
high-level decision characteristics. You were introduced to decision modeling and learned
about the importance of decision validation. We followed Sue, the head underwriter at AIC, as
she applied these techniques to the fictitious auto insurance companys first decision
discovery project. We hope that this will enable you to get started discovering the decisions
within your organization.
In the appendix, you will find some references that will provide you with a deeper and broader
understanding of decision modeling, as well as a summary of automation considerations.
Best of luck in your decision discovery journey.
A
Appendix A. Automation considerations

Once your decisions have been discovered and documented, you might become interested in
automating them. Whether it is as part of a Decision Management or a Business Process
Management implementation project, this section provides a very high-level overview of some
of the key considerations.

Operational Decision Management and Business Process
Management
To manage both processes and decisions, there are approaches, or disciplines, that consider
the needs of business process and operational decision governance and administration.
Operational Decision Management and Business Process Management are business

disciplines focused on managing business operations. Business operations include both core
and supporting areas of the enterprise, but it is aligned to the day-to-day running of the
business, rather than setting new direction and strategy.
Operational Decision Management is a business discipline that empowers organizations

to discover, design, automate, optimize, and govern repeatable operational business
decisions.
Business Process Management is a business discipline that enables organizations to

combine people, process, knowledge, and technology to achieve business value.
Figure A-1 on page 123 highlights the confusion, disorder, and rework that can develop in
many organizations due to the interaction of disparate existing systems and multiple business
roles. There are a number of issues that commonly induce process chaos, this diagram
highlights a few of them:
1. Informal tasks and communication (for example, paper or email)
2. Inefficient working environment that spans systems
3. Inconsistent prioritization and decision making
4. Incomplete or inaccurate data flow between systems
5. Lack of control over system and business events (exceptions)
6. Poor visibility into process performance
Figure A-1 Process chaos
Figure A-2 on page 124 illustrates how the application of Business Process and Operational
Decision Management can restore order to this chaos. This is achieved as a result of the
visibility, flexibility, standardization, and control gained through the workflow and decision
automation while continuing to leverage existing systems, roles, and information.
Appendix A. Automation considerations 123

Figure A-2 Process and decisions bring order to chaos
Business Process Management and Operational Decision Management applied together

represent a two-pronged approach to business operations improvement. Table A-1 describes
the perspectives of both approaches.
Table A-1 Comparing Business Process Management and Operational Decision Management
Business Process Management Smart Operational Decision Management Smarter
Focuses on breadth of solution Focuses on depth of solution

Defines and orchestrates the end-to-end Defines and executes specific decision points in
process processes and applications
Combines automation with user Is focused on automating and improving
interaction decisions
Allows for visibility Allows for flexibility
Is fundamentally concerned with the Is fundamentally concerned with the
operational efficiency of the organization operational intelligence of the organization
Business Process Management has a broad focus on orchestration and management of

disparate tasks, actors, and services that comprise the end-to-end operations of
organizations.
Operational Decision Management, however, has a deeper focus on managing automated

decisions at specific points in the process. Operational Decision Management is not simply
about handling routing rules inside a business process, rather it is used to potentially
automate complex, highly-variable decisions at different points in a process, as well as in
other systems that may not be involved in orchestrated processes.
Use Business Process Management and Operational Decision Management together to

create smarter, more agile, and dynamic processes; processes that form an extensible
foundation for future innovation. This foundation enables business agility, and allows
processes to be continually improved over time.
Decision automation: Some considerations

As discussed in the introduction to this paper, automating repeatable, high volume decisions
using Decision Management technology can enable organizations to make better decisions
faster. The potential exists for dramatically improving business outcomes with this technology,
when the right decisions are selected for automation. Whether it is about increasing
profitability, decreasing risk, improving compliance, or achieving many other wanted business
objectives, decision automation projects can produce a significant ROI. In this section, we
touch on some of the key factors to consider when evaluating a decision for potential
automation. And then we take a very high-level look at some of what is involved in taking a
discovered decision through to automation.
Identifying candidates for automation

Not all decisions are good candidates for automation. As discussed earlier in this paper,
strategic, one-off decisions that require intensive data analysis, human collaboration, and
interaction are usually not good candidates. Consider instead automating repeatable
decisions that are made frequently and that may be complex. Decisions where the business
logic changes frequently, or where the time window for making changes is very short, can
also be excellent candidates.
When organizing your decision discovery project, prioritize efforts to focus first on those
decisions that have a high impact on key business objectives: cost, revenue, customer
satisfaction, profitability, quality, and so on, because the potential for a high ROI is there. It
can also be wise to start with decisions where the subject matter expertise is readily
available. With access to experts and high-quality sources of documented business
knowledge, the project's chances of success will be higher and the job of the discovery team
will be easier. It is good to start with some quick wins, as the team ramps up and gains
experience with initial decision discovery efforts. Then, the more challenging decisions can be
tackled later with confidence.
Decision management technology

Decision management platforms, like IBM Operational Decision Manager (ODM), have
become widely used over the last decade to automate decisions. They are perfectly suited for
automating decisions that need to be easily updated and quickly deployed, bringing increased
agility to the business. They provide a rich set of tools for defining, managing, deploying, and
governing decisions. IBM ODM1, for example, consists of:
IBM Decision Center, which features a common repository and tools for business users
and analysts to author, change, and manage business rules.
1
You can learn more about IBM ODM at the following location:
http://www.ibm.com/software/decision-management/operational-decision-management/websphere-operational-
decision-management/about

IBM Decision Server, which provides a robust and scalable runtime environment, along
with an Eclipse-based development environment for developing, managing, and deploying
decision services.
Transition from decision discovery to automation

As shown in Figure A-3, there are a variety of roles, skill sets, tools, and techniques that are
needed at different points in the decision discovery and automation process.
Figure A-3 Decision discovery and automation
Once a decision has been discovered, documented, and validated in Blueworks Live, there
are a number of things that need to happen before it can be automated:
Data analysis must be done to identify the data structures that are required by the
decision, and to map those onto the appropriate enterprise data sources.
The decision logic must be formalized. It needs to be unambiguous and based on a
structured vocabulary and formal language in order for it to be implemented. Decision
logic, when documented in Blueworks Live does not have to follow any formal syntax. It
can be unstructured text, domain-specific pseudo-code, or whatever form is best
understood by the business users documenting, collaborating, and reviewing the decision.
To prepare to automate the decision, that logic must be formalizeda task usually
performed by the business analyst.
The overall solution implementation must be designed. A decision will typically be
implemented as a decision service, and integrated into a business application or process
application (when a Business Process Management System is being used).
A decision service is the encapsulation of a decision. It provides a definition of the

interfaces that will be exposed to consuming applications, and is reusable by definition.
Maintenance of decisions should be considered in advance. Governance and change
management strategies must be defined and put in place so that decisions can be easily
changed and quickly updated once they have been deployed.
A development methodology of some sort is typically used to develop a Decision

Management system. Figure A-4 outlines the steps prescribed by one of the more popular
IBM ODM implementation methodologies: Agile Business Rule Development (ABRD).
Figure A-4 Agile Business Rule Development
From Blueworks Live to IBM ODM

The specifics of implementing a Decision Management system can differ significantly
depending on your choice of technology. Here is a brief overview of some of the steps that are
needed to automate decisions discovered with Blueworks Live using IBM ODM.
1. Define a conceptual model representing the inputs and outputs of the decision.
This is typically done by creating a UML class diagram. This task is performed by a
business analyst.
2. Transform the conceptual model into an execution object model (XOM).

This is the set of Java classes or the XML schema that will be instantiated at runtime. This
task is typically performed by a developer.
3. Define the business object model (BOM) based on the XOM.
This provides a layer of business vocabulary on top of the XOM, so that the rules can be
understood and potentially authored by business users. The business terminology used
should reflect the names of the decision inputs and outputs documented in the Blueworks
Live decision diagram, and described in the Blueworks Live glossary.
4. Define the decision signature.
This is the interface that describes the inputs and outputs to the decision. It is defined by
the rule set parameters that are associated with the rule project.
5. Map the decomposed decision into rule tasks in a rule flow.
This is done using a graphical editor and diagram in IBM ODM that resembles a miniature
(and very simple) process flow.
6. Author the business rules in the Business Action Language (BAL).
These business rules should correspond to the decision rules documented in the decision
tables in Blueworks Live for the decision and its sub-decisions.
7. Deploy the decision service
To do this, a developer extracts a rule set from the rule project and associates it with a
RuleApp. The RuleApp is then deployed to ODM's Rule Execution Server, at which point it
is available for invocation.
8. Manage changes to the decision service.
In order to accommodate future changes to the deployed decision, governance strategies
should be put in place:
Establish a governance strategy for managing changes to the decision. This is focused
on the business lifecycle of decision change:
Who are the business stakeholders with permission to update, review, and approve
changes to decision metadata, structure, and logic?
What are the various states that a decision passes through between the point that
the need for a change has been identified, until a final, valid version of the updated
decision is available?
How do we keep track of these changes, and keep our business artifacts organized
throughout the process?
Establish a governance strategy for managing changes to the decision service. This
will be focused on the IT lifecycle of deploying updates to decision services when
business changes are made to the decision:
This involves setting up and following a safe, controlled, and auditable change
management process for the deployed software artifacts.
This process will need to be synchronized with the business change lifecycle of the
decision, described above. In order to coordinate these lifecycles, it will be very
important for IT and the business stakeholders to collaborate closely.
This was a very high-level summary.
Additional information: If you are interested in reading more about automating decisions
with IBM ODM, the IBM Redbooks publication Making Better Decisions Using IBM
WebSphere Operational Decision Management, REDP-4836, is an excellent resource.
Process improvement and automation: Some considerations
As discussed in the introduction to this paper, automating business processes using business
process management technology can enable processes to become more visible, repeatable,
and manageable. When a business decision is automated, the decision achieves similar
qualities to the process, but it also becomes more flexible. Decision management software
enables quick, easy, yet managed, updates to decision criteria. Processes that have their
decisions extracted and automated separately from the process gain this quality of flexibility.
Automation of processes and decisions with management software can immediately accrue
business value by increasing efficiency, reducing errors, eliminating uncontrolled process
variation, reducing rework, improving decision quality, and enabling managed change, when
the right process and decisions are selected for automation. In this section, we touch on
some of the key factors to consider when evaluating a process for potential automation. Then,
we take a very high-level look at some of what is involved in taking a discovered process, with
its decisions, through to automation.
Identifying candidates for automation

Not all processes are appropriate for automation. A process that has a business case and an
ROI in alignment with enterprise goals is a potential candidate for automation. There are a
number of aspects to examine to determine suitability for analysis and possible automation:
Scope and complexity
Business value
Readiness for change
Scope and complexity

A business process can involve numerous participants, process owners, and experts. It may
have many suppliers, customers, inputs, and outputs and it can use various systems. You can
use the analyze tool in IBM Blueworks Live to estimate the complexity of the process related
to these attributes. A more complex process might not be an ideal candidate for an initial
automation project. For an experienced organization, however, automation of a complex
process may be attempted through a phased approach. In this case, the scope should be
considered so that value can be achieved with a limited scope for each phase.
Business value
A business process selected for automation should provide value to the business. The impact
can involve the elimination of pain points in the current process, and the achievement of
business goals. Assess the pain points and the goals that have been documented for the
process in IBM Blueworks Live to determine if they are attainable through process
improvement and automation.
Readiness for change

A process automation initiative cannot be successful without business support and readiness
for change. Improving the process and decisions means abandoning the status quo. The
relevant process and decision SMEs, participants and experts, need to be available and
engaged, for the project to be successful. Continual improvement through Business Process
Management (BPM) is an on-going journey, so resources need to be committed beyond the
short term.
Change cannot occur without leadership. The process ownership needs to be clearly
identified to successfully and proactively guide the improvements. A process owner provides
stewardship, direction, and oversight, and, most importantly, is the champion for the end

solution. Embarking on a BPM journey without an owner introduces risk; risk that the end
solution will not deliver business value due to a lack of vision and accountability.
Additional information: For more information about selecting processes for analysis and
automation, see the IBM Redbooks publication Scaling BPM Adoption: From Project to
Program with IBM Business Process Manager, SG24-7973.
Business Process Management technology

Business Process Management (BPM) suites, like IBM Business Process Manager, are
generally used to automate process orchestration. BPM suites are appropriate for automating
processes that need to manage people and systems together in cohesive workflows. They
provide a comprehensive set of tools for defining, managing, and deploying processes and
services. IBM Business Process Manager, for example, consists of two major editions:
IBM Business Process Manager Standard provides human-oriented process orchestration
with service integration capabilities.
IBM Business Process Manager Advanced provides both human-oriented process
orchestration and enterprise-level integration capabilities.
Additional information: You can learn more about IBM Business Process Manager here:
http://www.ibm.com/software/integration/business-process-manager
Service-oriented architecture
Service-oriented architecture (SOA) is a business-oriented architectural approach for IT. It
enables your business through integrating business tasks as services. Automated processes
are a form of business task integration. An automated decision task is a form of service, a
decision service. Decision services can be reused, together with other business services,
across multiple automated business processes in a service-oriented architecture.
Additional information: You can learn more about SOA from IBM at the following site:
http://www.ibm.com/software/solutions/soa/what-is-soa.html
Transition from process discovery to automation

Once the business process discovery provides an adequate representation of the business
needs and scope, you can start planning for implementation. In the Implementation phase, a
business process is iteratively developed. It starts as a concept in IBM Blueworks Live and
ends up as a running business process solution.
A key component of a successful BPM implementation project is the employment of a

playback at the end of each development iteration. A playback is an opportunity for the
process owner and other process SMEs to walk through the evolving process solution to
validate that it is meeting their requirements. It is not a demonstration by BPM developers.
Playbacks promote the ownership, sponsorship, and eventual acceptance of the solution by
the business.
In a typical BPM implementation project, there are at least four playbacks. Each playback has
its own specific validation goals.
Playback 0: Validate the design of the analyzed process
Playback 1: Validate the design of the user interface
Playback 2: Validate the definition of the integrations
Playback 3: Validate the cohesive process solution
Figure A-5 Process improvement lifecycle
Figure A-5 shows the planning of the BPM implementation that takes place at the end of the
Discover and Document phase (usually performed in IBM Blueworks Live). The actual
implementation follows the planning and starts after Playback 0. Implementation will require
BPM Developers to participate to build the solution with the BPM suite of software, such as
IBM Business Process Manager.
IBM Business Process Manager provides a Process Center (a central repository for BPM
project assets) and authoring tools: Process Designer (to model, implement, and
demonstrate business processes) and Integration Designer (to implement integrations to
external systems), to support collaborative process and integration service development.
Implementation starts from an initial process model design. Usually this is the process
documented in IBM Blueworks Live. An implementation is built from this process definition.
Then, in the Process Designer tool, you build and refine the process application. At any time
during development, the process application can be run to validate it. This will always be done
during playbacks, but it is also often done to informally demonstrate and discuss the process
application with business users and get their direct feedback on the running solution.

Figure A-6 shows that the build, refine, and demo of the process application is a continuous
cycle of feedback. This occurs over the number of defined iterations, each ending in a
playback, which is identified during the planning phase. Once the overall process application
has been developed, you can test and review it. The outcome of this testing may introduce
changes to the implementation and even to the initial process definition. The final stage is to
install the process application into an environment where it can be deployed to business
users.
Figure A-6 Process implementation
Additional information: For more information about taking your process from discovery
through to automation, see the IBM Redbooks publication Scaling BPM Adoption: From
Project to Program with IBM Business Process Manager, SG24-7973.
Conclusion
In this appendix, we introduced some of the key factors to consider when automating
decisions. We touched on Decision Management and Business Process Management
technology. And we provided an overview of the transition from decision and process
discovery to decision and process automation. For a deeper understanding of these topics,
explore some of the additional resources that are highlighted in the next section.
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 Blueworks Live

To learn more about IBM Blueworks Live:
Sign up for a trial account at no charge at the following site:
Once you have your trial account, you can access various forms of help: Product overview
pages, video tutorials and more at the following Help site:
https://www.blueworkslive.com/scr/help
Decision Modeling
To learn more about decision modeling, decision analysis, and decision tables:
OMG Decision Model and Notation (DMN):
http://www.omgwiki.org/dmn-rfp/doku.php
The Decision Model - by Barbara von Halle and Larry Goldberg of Knowledge Partners
International (book and website):
http://www.kpiusa.com/index.php/The-Decision-Model/the-decision-model.html
Business Rule Solutions provides many resources for learning about Decision Analysis:
http://www.brsolutions.com/publications.php#primers
Jan Vanthienen provides many learning resources for decision tables:
http://www.econ.kuleuven.ac.be/tew/academic/infosys/members/vthienen/default.htm
More on Decision Tables and the Decision Model in Practice by Barbara von Halle and
Larry Goldberg of Knowledge Partners International, which is published in Modern
Analyst:
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleVie
w/articleId/2376/More-on-Decision-Tables-and-The-Decision-Model-in-Practice.aspx

Decision Management
To learn more about IBM ODM and Decision Management:
James Taylor at Decision Management Solutions provides books and other materials for
learning about Decision Management:
http://www.decisionmanagementsolutions.com
IBM ODM Overview:
http://www-01.ibm.com/software/decision-management/operational-decision-managem
ent/websphere-operational-decision-management/about
IBM Redbooks Publication: Making Better Decisions using IBM WebSphere Operational
Decision Management:
http://www.redbooks.ibm.com/abstracts/redp4836.html
Agile Business Rule Development Process, Architecture and JRules examples (Boyer
and Mili, 2011, Springer Press):
http://link.springer.com/book/10.1007/978-3-642-19041-4/page/1
ABRD Eclipse plug-in download site:
http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php
Business Process Management

To learn more about IBM BPM and Business Process Management:
IBM Business Process Manager Overview:
http://www.ibm.com/software/integration/business-process-manager
IBM Redbooks Publication Scaling BPM Adoption: From Project to Program with IBM
Business Process Manager:
http://publib-b.boulder.ibm.com/abstracts/sg247973.html
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services
Back cover
Discovering the Decisions

within Your Business Processes
using IBM Blueworks Live
Redpaper
Uncover the decisions In todays competitive, always-on global marketplace,

businesses need to be able to make better decisions more INTERNATIONAL
within your business
quickly. And they need to be able to change those TECHNICAL
processes
decisions immediately to adapt to this increasingly dynamic SUPPORT
business environment. Whether it is a regulatory change in ORGANIZATION
Learn to use IBM your industry, a new product introduction by a competitor
Blueworks Live to that your organization needs to react to, or a new market
discover and opportunity that you want to quickly capture by changing
document decisions your product pricing. Decisions like these lie at the heart of
your organizations key business processes. BUILDING TECHNICAL
Leverage decisions to INFORMATION BASED ON
In this IBM Redpaper publication, we explore the benefits of PRACTICAL EXPERIENCE
create smarter identifying and documenting decisions within the context of
business processes your business processes. We describe a straightforward IBM Redbooks are developed
approach for doing this by using a business process and by the IBM International
decision discovery tool called IBM Blueworks Live, and we Technical Support
apply these techniques to a fictitious example from the auto Organization. Experts from
insurance industry to help you better understand the IBM, Customers and Partners
concepts. from around the world create
timely technical information
This paper was written with a non-technical audience in based on realistic scenarios.
mind. It is intended to help business users, subject matter Specific recommendations
experts, business analysts, and business managers get are provided to help you
started discovering and documenting the decisions that are implement IT solutions more
key to their companys business operations. effectively in your
environment.
For more information:

ibm.com/redbooks
REDP-4993-00

Redp 4993

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redp 4993

Uploaded by

Copyright:

Available Formats

Front cover

Discovering the Decisions

Uncover the decisions within your

Learn to use IBM Blueworks Live to

Leverage decisions to create

Discovering the Decisions within Your Business

First Edition (January 2014)

This document was created or updated on January 29, 2014.

Copyright International Business Machines Corporation 2014. All rights reserved.

Chapter 1. Introduction to decision discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. Introduction to IBM Blueworks Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 3. Getting started with decision discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Copyright IBM Corp. 2014. All rights reserved. iii

Chapter 4. Bringing it all together: The AIC decision discovery project . . . . . . . . . . . 41

Appendix A. Automation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Copyright IBM Corp. 2014. All rights reserved. v

The following terms are trademarks of other companies:

In todays competitive, always-on global marketplace, businesses need to be able to make

Copyright IBM Corp. 2014. All rights reserved. vii

Chris Walk, former IBM Blueworks Live Product Management

Now you can become a published author, too!

Stay connected to IBM Redbooks

Chapter 1. Introduction to decision

In this Redpaper publication, we explore the benefits of identifying and documenting

So let us get started.

Copyright IBM Corp. 2014. All rights reserved. 1

1.1.1 Operational decisions

1.1.2 Decision discovery

Discover Model Refine

Figure 1-1 Decision discovery through automation

Chapter 1. Introduction to decision discovery 3

1.1.3 The anatomy of a decision

Figure 1-2 Structure of a simple decision

1.2 Decisions and business processes

Chapter 1. Introduction to decision discovery 5

A business process represents the sequence of activities taken by various participants

A decision is a conclusion reached in response to a set of facts.

What is a decision point?

A decision point is a place within a business process where a decision is made.

1.2.2 Benefits of documenting the decisions within your business processes

Chapter 1. Introduction to decision discovery 7

Chapter 2. Introduction to IBM Blueworks

Copyright IBM Corp. 2014. All rights reserved. 9

2.2 Decision discovery with Blueworks Live

2.2.1 Decisions within business processes

2.2.2 Capturing key decision characteristics

Chapter 2. Introduction to IBM Blueworks Live 11

2.2.3 Composing a decision

Figure 2-4 Decision diagram

Figure 2-5 Composing a decision

Chapter 2. Introduction to IBM Blueworks Live 13

Figure 2-6 Documenting decision logic

2.2.4 Viewing a decision

Figure 2-7 Navigating a decision

Figure 2-8 Collaborating on decisions

2.2.6 Validating decisions

Chapter 2. Introduction to IBM Blueworks Live 15

Figure 2-9 Validating a decision

2.2.7 Tracking changes to decisions

Figure 2-10 Managing decision changes with snapshots

Chapter 2. Introduction to IBM Blueworks Live 17

Figure 2-11 Finding a decision and where it is used