You are on page 1of 32

Adaptive BPM

For Adaptive Enterprises

Dr. Rob Walker, Vice President, Decision Management & Analytics
Dr. Setrag Khoshafian, Chief Evangelist and VP of BPM Technology
Executive Summary
The Problem
Enterprises are facing unprecedented economic, competitive and global challenges. Traditional approaches
to incremental cost-cutting and revenue growth are not succeeding. Optimizing the customer experience
to increase customer loyalty and reduce customer defection has become critical. The problem is that
the environment in which enterprises operate is constantly in flux. While adaptive was once merely a
catchy term, it is now a requirement for organizational survival and sustained growth. The challenge is to
continually adapt, leveraging customer transactional data, changes in customer as well as market behavior,
and to create innovation opportunities with iterative and measurable improvements. Enterprises need to
embrace a more holistic approach to adaptability.
The Solution
The solution for organizations is to understand and embrace the seven key capabilities generally found
in adaptive enterprises. These capabilities are not mutually exclusive, yet they are distinct and essential.
Enterprises become adaptive through:
` Continuously monitoring optimized, and measurable business objectives
` Continuously innovating through re-use and specialized, contextual and situational solutions
` Continuously discovering business requirements with iterative enhancements
` Continuously improving automated work and dynamic case management solutions
` Continuously gaining insight, while learning and adapting with better decisions
` Continuously adapting decisioning champions as customer behaviors change
` Continuously visualizing, simulating and optimizing decision priorities
The Benefits
Organizations that have leveraged Pega to become adaptive enterprises have reaped tremendous benefits in
four main areas:
` Generating increased revenue through solutions such as new account opening and cross-sell/up-
sell with incredible speed while innovating with new products and solutions.
` Optimizing the customer experience through continuously monitored and optimized customer
service and decision management. Pega solutions continuously adapt to new market realities
and the customers changing needs, while always focusing on the value of the customer through
communications and offers that fit their requirements.
` Continuously improving efficiencies through eliminating waste and improving speed of execution
while building, executing, or improving customer-centric solutions. The automation of dynamic cases
is the key enabler of continuous efficiency.
` Business transformation through the robust support for different levels of business transformation.
Pega helps organizations achieve a rhythm of change through our unique software and
Figure 1:
BPM Suites
Business Process Management Suites have evolved from a number of disciplines.
Process improvement methodologies, such as Lean Six Sigma, attempt to eliminate
waste in work processing, while increasing the efficiency as well as the quality of
products and services. Process automation has evolved from structured production
workflows to collaborative, unstructured, and dynamic cases. Process intelligence
spans business rules, decisioning, and business events. Architecture patterns such
as service oriented architectures and more recently Web oriented and customer-
oriented architectures are enabled and empowered through BPM Suites. These
disciplines and technologies are evolving to what is called the adaptive enterprise. An
adaptive enterprise can align its business objectives to the operationalized policies
and procedures with complete transparency, visibility and control. More importantly an
adaptive enterprise is agile and proactive in responding to change. The only constant in
business is change!
A BPM Suite is the platform that enables the organization to realize the promise of the
adaptive enterprise. With BPM, stakeholders will have complete visibility and control of
their objectives, which are often expressed in key performance indicators. Stakeholders
can see and understand what is going on with their support, mission critical actions,
and management processes. More importantly, they can be proactive and make
changes to improve them. BPM enables business stakeholders to be in the drivers
seat: monitoring, improving, innovating through new solutions, automating work and
building efficiency throughout. In other words, BPM is about running the business!
BPM Suites
Pega BPM
Lean Six Sigma
Process Automation
Process Intelligence
Process Improvement
Process Architectures
Big Data
Adaptive BPM comprises the platform, solutions, best practices, methodologies
and governance for adaptive enterprises. This paper discusses the seven essential
components of an adaptive enterprise, as illustrated in figure 2:
` Continuously monitoring and optimizing measurable business objectives
` Continuously innovating through re-use and specialized, contextual and
situational solutions
` Continuously capturing requirements with iterative enhancements
` Continuously improving automated work and dynamic case management
` Continuously gaining insight, learning, and adapting with better decisions
` Continuously adapting decisioning champions as customer behaviors change
` Continuously visualizing, simulating and optimizing decision priorities
Figure 2:
Adaptive BPM
Behavior Value
Past Experience Predictive
Insightful and Scalable in
Learning For Better Decisions
Adaption Through Simulation
and Optimization
Continuously Monitored
Business Objectives
Adapt Through Contextual
and Situational Execution
Adapt Through Continuous
Adapt Through Automation
and Dynamic Cases
Continuously Learn Through
Adaptive Decisioning
Adaptive Through Champion
Continuously monitoring measurable key performance indicators and being able to
drill down, improve, and adapt are key characteristics of adaptive enterprises. Due to
BPM automation, the business is able to do real-time activity monitoring. The BPMS
keeps track of the execution of each automated process and maintains an audit trail
of the assigned task, the performance of the operators or workers, the performance
of solutions built in the BPMS, or the performance of individual processes.
Businesses can take any of their key performance indicators, drill down and affect
change: for instance, bulk re-assign the tasks of operators who are not able to keep
up with their service levels.
Figure 3 illustrates the taxonomy of the
type of knowledge or insight we can get
from data and the corresponding business
value. Reports can be sourced from real-
time business activity monitoring or data
warehouses that contain historical data
potentially from multiple sources. BPM
suites are increasingly becoming a key
source of data for both business activity
monitoring (BAM) and data warehouses.
Reports are useful for understanding what
happened (historic) or what is happening
now (BAM). Analysis goes further in data insight and attempts to slice and dice
the data along different dimensions and perspectives. Analytics is a key technology
that enables companies to extract invaluable insight and infuse that insight into key
business decisions. It attempts to discover trends and glean insight from aggregated
data. Dashboards allow business stakeholders to have a role-specific, strategic,
key-performance perspective on their operations. The users can drill down and
potentially act on any detected bottlenecks.
Pega provides extensive and comprehensive support for adapting
through continuously monitoring measurable business objectives. The
Pega business activity monitoring can be summarized as follows:
` Pre-built Reports and Browser Pega BPM provides dozens of out-of-the-
box reports, and Pega Frameworks provide even more functionality. Pre-built
and custom-built reports can be organized, browsed, searched and run from
the report browser.
` Report Viewer The report viewer provides intelligent drill-down,
aggregation, and pivot table behavior, and lets users easily customize, save,
and share reports with title, column, filter, and sorting changes.
` Report Designer This business-friendly tool lets designers create even
complex reports in seconds, selecting data from work tables and external
systems. With easily customizable capabilities such as top/bottom results,
business users can easily create reports that exactly match business needs
without needing DBA or IT help.
Continuously Monitored Business Objectives
Figure 3:
Taxonomy of BPMS data
BAM or Historic
KPI Scorecards
Knowledge Discovery

(Automated in BPMSs)
Predictive Models
Designing and viewing
real-time business
activity monitoring
reports can help
organizations manage
their Pega applications
key performance
indicators, as well
as the workload of
dynamic cases. In a
federated deployment, an
organization often wants
to combine data from Pega systems, legacy applications, Web portals, and other
sources to provide a more complete picture of the business, using data warehousing
for decision support and advanced analytics. To handle complex applications, Pega
stores its data in a compressed XML object format. Pegas Business Intelligence
Exchange (BIX) tool extracts Pega case data into formats suitable for importing
into a consolidated data warehouse or other analytics environment. With BIX, Pega
case date becomes one of the key sources (dimension and/or measure) in a data
warehouse. Analytical Business Intelligence tools can be then used to slice/dice that
data warehouse, involving Pega case data.
Figure 4:
Pega BPM reporting



Data Warehouse
Data Mart
Case Data
Figure 5:
Business Intelligence
Exchange (BIX)
When business applications execute, there needs to be a context or business intent:
the type of the customer, the location or jurisdiction of the customer, or the specific
business productto name a few. All these dimensions need to be used to select and
provide the best policy, user interaction, or information source for a given situation.
Through robust BPM solutions, the adaptive enterprise needs to reflect the way
people manage change in their organization. Businesses need to treat customers
uniquely, based on a particular set of criteria. BPM can provide the context and
specific solutions for their specific customers or lines of business. The BPMS needs
to support optimized re-use and specialization, and then the automatic selection of
the most appropriate specialized asset (policy or procedure) for a given situation.
Using BPM, enterprises should be able to adapt through easily reusing and globally
specializing their business assets. The assets here are BPM assets for execution. The
assets include flow fragments, business rules of different types (decision, constraint,
expression), UI, information, integration etc. The multi-dimensional organization of
BPM assets is the mechanism that enables the adaptive enterprise easily:
` Introduce changes: deltas that capture specific policy or procedure changes
` Customize and specialize so that, for instance, different customers are
treated differently: depending upon who they are, where they are, what type of
product/service they are requesting, when the request is made, etc.
` Organize solutions for optimal reuse across the enterprise and then
specialize for specific locations, customer categories, solution frameworks, or
lines of businesses.
Think of giving special discounts for specific types of customers. The discount
calculation is a specialization and it depends upon the type of the customer. It could
also depend upon specific jurisdictions, locations or timeframe. That is how business
manages specializations.
Through Pega an adaptive enterprise can have common policies and procedures,
and then easily add specializations for specific situations. The Pega BPM engine then
selects dynamically the best policy or procedure for a given context or situation. The
Pega repository supports out of the box versioning, auditing, access control, testing,
search/navigation, and processes for managing change. The Pega BPM assets are
organized in a dynamic multi-dimensional repository.
The repository has several dimensions. This includes temporal versioning,
but other dimensions are equally important. For the adaptive enterprise, the
repository supports central models and constrained customization for branches or
departments, or geographical locations or offices. There can also be a dimension that
addresses the type of customer.
Adapt Through Contextual and Situational Execution
Pega supports a multi-
dimensional repository of
BPM assets that are organized
in specialization layers. At
execution time, the Pega BPM
engine selects the best asset
(UI, process fragment, policy, or
service (integration)) depending
upon the situation.
The enterprise repository can
adapt quickly while reusing
existing solutions. Application
reuse is associated with
assets (flows, business rules,
etc.) specific to an application
and common to more than
a single business unit. The
exceptions to the rule that
normally require extensive
coding or human intervention are handled with a simple specialized layer that captures
the rules for the particular situation. For example, all divisions across an insurance
organization would need some type of policy administration or billing application.
The policy administration applications would all require features to support quoting,
underwriting, binding, and issuing of policies. Specialization or customization can be
for specific business units or global operations (countries or regions).
The ability to organize, reuse, and easily customize existing policies for specific
situations is extremely important in adaptability: managing change across the
enterprise while leveraging reusable practices or frameworks. Pega calls this run-
time specializations and it achieves contextual execution through what we term
Situational Layer Cake. Pega BPMs run-time specialization is a revolutionary
approach that uses dynamic layers that are selected depending on the circumstance.
The exceptions to the rule that normally require extensive coding or human
intervention are handled with a simple specialized layer that captures the rules for
the particular situation.
This is the core of the Pega BPM architecture and provides a robust enterprise
repository of business application assets. Pega BPMs enterprise repository offers:
` A unified repository with advanced tools for all users to speed delivery and
enhance re-use
` Heat maps and other visual tools so designers and analysts can quickly
assess and navigate a Pega BPM application and its components
` Repository controls supporting locking, versioning (including multiple active
versions of the same asset), history, auditing and migration
For adaptive enterprises, the situational layer cake and the core BPM enterprise
repository provide several key benefits, including:
` Speed of development due to re-use of assets
` Handling complex liability limitations across jurisdictions with multivariate
` Ability to quickly pilot and activate across lines of business using the layered
Figure 6:
Situational Layer Cake
Line of Business
Standard Offering
Pega BPM Platform
& Accelerators
Pega Framework
Customer A Customer B Customer C
Elite Service Offering Standard Service Offering Other Service Offering
Pega BPM
Customer Process Manager - (Packaged Contact Center Best Practices)
US & Canada Offering Europe Offering
Value Added Services
Gold Customers Silver Customers
A business is a collection of policies and procedures. Business, IT, and operations
need to have full transparency and visibility to all the elements of a complete
business solution. An adaptive enterprise needs to provide the same consistent
platform as a lingua franca between business and IT. The different platforms for
business and IT approaches have simply failed. The platform should allow different
portal views depending upon the role of the user.
In traditional development, the business starts with a mandate, and then uses
documentation-heavy tools to capture the requirements. The requirement documents
are then used or imported as artifacts with a different tool in order to do a high-level,
and then a detailed specification or business analysis. This could result in voluminous
documentation models or artifacts. At some point, there is a hand off from business
to IT. The business artifacts are then exported and imported into other tools to do
system analysis, high level design, and detailed technical design. Several modeling
and analysis tools could be involved. After a number of exports and imports between
tools, they are finally exported and imported into yet another tool to do coding. With
the code, there are continuous reviews and changes. This inadequate export and
import process and the involvement of many tools is the antithesis of managing
change with agility. Soon enough, the implementation is completely isolated from
the original business requirements. The code becomes the documentation of what is
implemented! There is no round-tripping, and changes have to go through many tools
and phases of export, import, export, import. Enormous discipline and effort need
to be exerted to keeps all the artifacts pertaining to different tools consistent. That
doesnt inspire agility!
We are living in the Web application age. The Web is not just for the business. It is a
robust platform for both business and IT. A unified consistent platform should have
a single representation for each asset in the BPM solution. Agile enterprises need
a thin-client (browser based) unified platform where the business requirements are
discovered, captured, automated, and executed with continuous improvements all
via a single object model through browsers, with no technically heavy thick client
tools involving multiple representations or multiple exports/imports. This should
make it easy for business stakeholders, business analysts, and IT to use the same
platform and deal with the same element throughout the lifecycle of the asset.
Round-tripping is taken for granted: IT, analysts, or the business view and change
the same object. At a minimum this means a single cohesive platform that supports
business process flows, case types, and a complete collection of rule types, decision
management, information model, UI, and integration. In other words all the assets of
a BPM application.
Adapt Through Continuous Discovery
Instead of providing different tools for business and IT, Pega provides the same
consistent platform as lingua franca between business and IT. Traditional, different
tools for business and IT approaches have simply failed. What is needed is a thin client
(browser- based), unified platform where the business requirements are captured,
automated, and executed with continuous improvements. Pega calls this methodology
directly capturing objectives (DCO). Pega provides a unified environment that
automatically generates the solution from requirements without cumbersome hand-
offs, import and export, conversion to execution environments, and rebuilding details in
multiple environments. Change is fast, but controlled, continuous, but orchestrated.
In order to adapt, the enterprise must be able to close the gap between business
objectives and operations. This requires sharing ideas with operations and IT at all
stages of a BPM project to ensure that the solution meets business needs. DCO is the
set of capabilities in Pega BPM that lets business users capture, organize, and manage
information directly in the system instead of using disconnected documents or artifacts
that are obsolete before the solution is delivered. DCO helps avoid requirement gaps
introduced in custom software projects, where business intent is often misunderstood.
Technical changes often obsolete requirements. Long delivery times mean business
needs have changed, and the business has no chance to see or provide feedback on
the application until it is too late. All these challenges are avoided with Pegas DCO.
Business stakeholders can generate documentation for a Pega BPM solution as
needed during the life of the solution. DCO helps avoid requirement gaps introduced
in custom software projects, where business intent is misunderstood, and technical
changes obsolete requirements, long delivery times mean business needs have
changed, and business has no chance to see or provide feedback on the application
until it is delivered. The first step in building an application profile is to use the
Discovery Map a process mapping tool running in the same thin-client environment
as all Pega BPM tools to define the base steps for a process.
Figure 7:
Directly Capture Objectives
For more information, please contact your Pegasystems representative, visit us on the Web at, or email us at Copyright 2011 Pegasystems. All rights reserved.
Application Profiler
The Application Profiler guides the user to capture the
following details:
` Overview (organization, project, application)
` Actors (users, services, and agents initiating and
performing work in the application)
` Work Types (high-level business functions and the use
cases that act against them)
` Interfaces (required connectors and services for external
data integration)
` Reporting (types and contents of reports required against
the work)
` Correspondence (mail and other materials sent to process
` Assumptions and Resources (project requirements for
internal and external resources)
The heart of the Application Profiler is the collection of work
types and associated use cases. These drive the definition of
the application all the way through to testing and deployment,
where use cases guide test scenarios and work types define
what work can be performed by application users.
The participants (either a person or a remote system) who
interact with the SmartBPM

solution are called actors. The

interaction between the SmartBPM

solution and an actor

is called a use case. In SmartBPM

uses cases are atomic:

each use case represents a single interaction between an
actor and the system. The collection of atomic use cases
describes the behavior of a work type.
The Application Profiler links captured requirements to the
elements that implement the requirements, allowing, for
instance, a flow implementing the use case to have a link
directly to the requirements of that use case. This aids the
developer by providing a mechanismto trace directly back
to the use case requirements. This allows the developer to
review requirements and ensure they are fulfilled.
The Application Profiler continues gathering key
requirements of the project, including the requirements
for the SystemInterfaces, Reports, and Correspondence.
The Application Profiler also collects key project planning
parameters, such as the assumptions, roles, responsibilities,
tasks, and resources. This project planning information
is used to manage the project with the optional Project
Management Framework.
Following the completion of the Application Profiler
wizard, a preliminary high-level project scope document is
automatically generated. Now Business and IT can access
the high-level objectives right within the system.
The Application Profiler can be run again as project
requirements are augmented or changed. When any aspect
of the profile is updated, use cases, the proposal document,
and project estimates are immediately updated for all team
members to use.
Application Profiler is part of SmartBPM

version 5.4 or
The Discovery Map lets business teams sketch a base process, and then flesh it out
with activities, sub-processes, and decisions to any level of detail. The process is
always live and can be immediately shown as a Visio-based process flow and test-
run so users and designers can collaboratively work to get it right.
Additional information such as actors and use cases may be attached, and blocks can
be quickly added or rearranged to reflect the best thinking on the process.
Business stakeholders can generate documentation for a Pega BPM solution as
needed during the life of the solution. Because this documentation is generated
directly from the rules at any time, it is always up-to-date and in sync with the
actual implementation. With Pega BPM, all aspects of business requirements are
modeled and executed directly in the shared environment. Pega provides visual
forms and wizards to define use cases, processes, and decisions in business terms.
Pega BPM provides a unified, powerful, and easy-to-use Web-based environment
for business owners, analysts, designers, and developers. Business and IT use
the same platform and nothing is lost in translation. Changes and prior versions
are automatically tracked, and access and change permissions are controlled for
complete application governance.
Figure 8:
Application Profile
Application Profiler
Directly Capture High-Level Objectives
` Guided work-centric process to collect
information at the beginning of a project.
` Handles details of application objectives,
including use cases as core of
requirements definition
` Creates an Application Profile document
that can be reviewed by Project Sponsors
` Information collected provides the basis
for the application built in PRPC
` Works with other Agility Accelerators
to drive requirements throughout
development and deployment
` Easy to use by business users and
analysis initially and for changes
quickly generates consistent, robust
` Provides complete details to ensure
nothing is missed, allowing accurate
and timely estimates, development,
management, and deployment of a
SmartBPM application
` Documentation supports review,
understanding, and justification for
` A complete and consistent set of tools
allows all project participants to work
efficiently, shortening time-to-market
The Application Profiler is a business friendly wizard that allows business
process owners and business analysts to directly capture requirements and
objectives into a SmartBPM

The Application
Profiler uses a guided
approach to build an
application profile,
which is a document
and a collection of
rules in SmartBPM

that capture use cases,
actors, and objectives
for a SmartBPM

The application profile
is used to produce a
proposal document (the
last step of the Application Profiler), supply work types, roles, integration,
etc. to create the application itself (in the Application Accelerator), and to
provide use cases and project estimates for testing and project management
(using the optional Test Management Framework and Project Management
Framework). Together these tools act as agility accelerators for the life cycle
of a SmartBPM

application, reducing development time and effort by 30%or

more, and providing excellent visibility into the development process.

The Application Profiler implements best practice for requirements gathering,
enforcing a consistent approach across an organizations SmartBPM

applications. With the high-level objectives captured through the Application
Profiler, a business/IT implementation teamcollaborates to develop and deploy
an application based on the shared objectives.
Adapt Through Automation and Dynamic Cases
In real-life business applications, what is being executed are actually cases, not
individual or often siloed process flows. Many times, the processing of the actual case
is done manually. With manual case processing, it is usually difficult to extend a case,
run additional process fragments, handle unstructured processes, or visualize the
case hierarchy. BPM addresses this through automation. Traditional BPM approaches
with structured processes tend to be pre-determined and cannot adapt. The swim lane
is perhaps the most ubiquitous representation of traditional production processes,
where each of the lanes indicates a participant or a party; you have tasks, you have
events, and the most important thing is that the sequencing of the tasks is rather rigid
and predetermined. Enter dynamic case management, which can handle structured
processes, of course, but also unstructured processes and ad-hoc changes.
A case is the coordination and collaboration of multiple parties or participants that
process different tasks for a specific business objective. Some of the tasks will
be planned in predetermined process flows. The tasks are most often unplanned.
Cases are therefore dynamic, adding or changing any of their elements. All of these
coordinating tasks in the case are for a concrete business objective or goal. Cases
are dynamic and respond to and generate events. In fact, if we were to look at the
anatomy of a typical case, as illustrated in figure 9, the case will have a hierarchy. It
will have subcases. Various tasks will be executed in the context of the parent case
or one of its subcases. The coordination of the tasks is organized in a case hierarchy
(subcases). Cases will always have a subject. Often, the subject is a human such as
a customer, patient, or recipient of welfare. A case, however, can be almost anything,
such as a claim. The case will also have a business objective pertaining to the case
subject. There will be a lot of collaboration between various case workers to resolve
the case. While processing these tasks, a case will have content, often from multiple
enterprise information or content management repositories. Cases generate and
respond to business events. Sometimes, events need to be correlated and the cases
will have service levels. There will be different types of policies and business rules,
such as decisioning rules, expressions, decision tables, and constraints, which
are associated with the case. Cases also have data properties pertaining to the
parent case or subcases, and multiple process fragments executing in the context
of the case hierarchy. Dynamic cases can adapt when requirements, behaviors,
circumstances, or events change.
Pega is the leading Dynamic Case Management platform At its core, it supports
adaptive automation of work. Pega BPM supports work automation in business
applications. It coordinates activities through routing work to the best skilled or
available resource, and obtaining, when needed, information from external or
internal sources. Pega BPM supports all types of work: clerical workers, knowledge-
assisted workers, and knowledge workers. Leveraging the Situational Layer Cake,
it dynamically tailors each task or interaction of the case. It supports the dynamic
case contents. Furthermore, the business application keeps track of all the business
activities and allows business users to drill down to control the performance of
their solutions. The solution will respond to customers and interested parties with
automated correspondence to minimize effort and ensure consistency. Pega BPM
supports the definition, subscription, and robust handling of business events. The
case work gets resolved by automating where possible and guiding users when user
involvement is needed.
Figure 9:
Case Hierarchies
Case Workers
See for example:
Specifically, Pega Dynamic Case Management supports:
` Design and Build Complete and Holistic Case Management Applications:
Pega provides a robust case type designer. The case types with their subcase
relationships can be defined intuitively through a visual hierarchy. Additional
elements that could be defined include attachment types, service levels, and
starting as well as ad-hoc processes or tasks that could be instantiated in
specific cases.
` Run-Time Case Worker and Case Manager Portal: This provides complete
visibility and control of the cases with fast access to case hierarchy, the case
tasks, the related cases, the history of their own and related cases, and
upcoming goal and deadline events. Users can drill down to the details of
the case and have a 360-degree view of the case and its subjects. The portal
also contains social collaboration constructs, such as a case wall to share
what is going on with the case or its elements. The case portal also provides
complete actionable business activity monitoring of the various cases that are
owned by the manager.
` Enterprise Content. Case workers can include documents and data from
multiple internal and external systems. Pega supports the CMIS industry
standard to include documents from potentially multiple ECM systems in the
case. Pega also supports document attachments with versioning.
` Business Events: Case managers can create events and subscribe to them.
The creation of the event can specify the name, description of the event type
as well as various conditions for the event. The event will happen when the
conditions on the event are satisfied. Events also have an action part for
instance executing an activity. Subscribers to the event can be notified through
a number of channels, including e-mail and text messages.
Figure 10:
Case Management portal
Continuously Learning Through Adaptive Decisioning
Companies that have automated decisions as part of a BPM solution can, in some
circumstances, opt for a system of continuous learning and adaptation. In such a
system the decision strategy (a combination of predictive models and specialized
rules that effectively exploit their predictions) is one that learns from its mistakes
and automatically corrects and improves itself. Popular use, for instance, is where
BPM solutions are used in the CRM or Marketing space where the decision strategy
adapts to changes in customer behavior or market dynamics. Customer behavior
can change because of demographic trends, legislation, interest rate, or a myriad of
other factors. Similarly, competitive offers or pricing can stir up things and impact
how customers behave. Rather than trying to re-calibrate predictive models manually
forever testing when such models get less accurate, then develop updated versions
adaptive systems will update automatically without human intervention.
This capability is available in domains where the link between decisions and the
feedback about the quality of those decisions is unambiguous and the time lag is
relatively short. That is, its possible to give the system a slap on the wrist when it
makes a bad decision (and reward it for a good decision) and the slap follows the
bad decision in quick order. In such domains (and there are many that qualify, also
outside CRM and Marketing) the BPM solution becomes proactive, not retroactive as
is mostly the case. Its one thing to effectively measure that change is needed, and
then being able to make that change in an agile manner; its quite another to fully
automate this process and have the improvements implemented by a self-learning,
adaptive system.
In Walker & Khoshafian, 2011 three stages of predictive guidance of processes
were distinguished. In stage one, process decisions were based on traditional rules,
for instance expressed in a decision table. Such processes can include complex
expressions to govern flow, but those expressions cover explicit, discrete, and
static knowledge, say from a company handbook. If a prediction is used in such an
expression, it is as a static reference, as in if customer.likelihood_to_buy > 0.75 then
sell else continue. Stage one is the realm of traditional BPM.
In stage two, the reference to a prediction is replaced by an actual predictive model.
This changes the dynamics considerably as the prediction is now on demand,
calculated at the time of the decision, as in if likelihood_to_buy(customer) > 0.75 then
sell else continue. The predictive model (or formula) that calculates the likelihood to
buy could perhaps still be expressed in a decision tree but in this case the decision
tree has been discovered, i.e. inferred from historical data, and is not defined in a
handbook. Stage two is called predictive BPM.
In stage three, the predictive models are not just inferred from historical data but
learn continuously from correct and incorrect predictions. The flow decision would
now look something like if likeli-hood_to_buyadaptive(customer) > 0.75 then sell
else continue. In this case, two subsequent invocations of the rule that contains this
decision might result in a different flow even when the data used in the decision is
exactly the same. It is this variant, called adaptive BPM that will be explained in more
detail in this section.
An altogether different approach is using so-called adaptive (or self-learning)
models. Instead of looking at a snapshot of data, they look at a moving window of
data as it enters the adaptive system. Such predictive models are always up to date
and never get tired. If the quality (i.e. predictive power) of adaptive predictive models
versus static predictive models is comparable, it would seem that adaptive models
are the better option. True as that may be in many situations, adaptive techniques
have three characteristics that make them not universally superior.
The Mechanics of Adaptive Modelling
To understand at a basic level how adaptive
techniques work, consider a BPM scenario
that involves three choices in a flow: black,
white and green. Instead of some form of
decision table that governs the selection,
an adaptive model will be used. This (trivial)
model uses only two case attributes:
customer age and customer gender (this
may be some CRM process). It will also be as
assumed that it can be instantly (or at least
quickly) established whether a choice for any
of the three directions was the right one.
The colors are chosen to make what follows generic examples of choices within
process flows. For a retail bank, for instance, the actual choices supported by
adaptive models could be:
` Black: offer a Platinum card;
` White: offer a Gold card;
` Green: offer a Silver card.
Note that choices can also be at a higher level (e.g. whether to best pursue sales,
collections, or retention for this customer), or at a more granular level (e.g. what
further incentive to use while offering the Platinum card).
To start approaching any of the above examples with adaptive techniques something
like figure 12 below is created first. It captures the underlying attributes, age and
gender in this case, and will maintain a count of wrong and right predictions/
decisions for each of the three choices we are interested in. In reality of course, the
number of attributes on which the decision is based will be much larger than two and
the number of possible choices will likely exceed three.

Figure 11:
BPM Scenario
Walker & Khoshafian, Doing the Right Thing: The Use of Predictive Analytics in Business Processes, 2011
But many predictive models would be quite complex and non-linear, and could not (easily) be expressed in
a decision tree (like a very simple parabolic formula could only be approximated in a decision tree or table).
More about that later, but the predictive performance is usually equivalent.
Note how, for the age attribute, the different age segments (<30, 30-40, >40) do not
look arbitrary. They are not and this so-called grouping is dynamically calculated and
adjusted, and part of the adaptive algorithm. The three adaptive models (one for each
of the choices) can use various techniques to calculate the probability from this kind
of table. In this case, where all the counts are equal, the three choices/decisions can
be right or wrong and theres no evidence to favor any of them.
Lets assume a 60 year-old woman is impacted by this process and that a (currently
random) choice is made to go with Green. Perhaps the Green process will wind up
proposing to this customer a session with a wealth advisor. Consider the scenario where
the woman accepts this proposition. This causes the table to be changed accordingly:
Figure 12:
Tallying good and bad
predictions based on Gender
and Age
Bayesian Networks are often used.
Figure 13:
Successful (Green) prediction
for woman over 40
With corresponding changes in the likelihood of going with Green for a woman over 40:
The probability of the Black choice being right remains, without evidence, 50%, and
the same for going with White. But Green is now considered to have a 72% likelihood
of being the right choice. But this is not the only effect! The adaptive system has now
seen (very limited) evidence that women may favor Green and (very limited) evidence
that customers over 40 may favor Green. Therefore, the case of a 50 year-old male
will also show a slightly increased chance of successfully being resolving through the
Green choice (57% per figure 15), but not as high as for a 60 year-old woman (72%
per figure 14).
An enhancement to self-learning is time windowing. It is essentially the size of the
memory of the adaptive models. If its small, the models will be faster to forget older
responses (to their predictions) and therefore follow short term trends very acutely
at the expense of longer term trends. Their predictions will be more opportunistic as
they are more susceptible to spikes in customer behavior (still staying with marketing)
while models with a larger memory will be slower to respond to new behavior and
factor in more of the past. In practice, approaches may be used (e.g. champion/
challenger as described later) that combine both short term and longer term models.
Its then a (real-time) business decision whether, for a particular prediction, the fast
learning (and unlearning) model or the slower one should be used.
Its important to note that all the algorithms referenced here are designed to be
very scalable and support hundreds or thousands of adaptive models and billions of
annual propensity calculations. As learning and predicting are separate processes,
with learning potentially asynchronous, very large decisioning volumes can be
handled with the right architecture.
The previous section described the value proposition of adaptive decisioning. In this
section we delve deeper into Pega BPMs features in supporting adaptive decisioning.
Figure 14:
Likelihood of success for
choices concerning a woman
over 40
Figure 15:
Likelihood of success for
choices concerning a man
over 40
In the example in figure 16, a simple decision
strategy is shown that uses three adaptive models
in the yellow shapes. Each model is trying to
predict the success of the corresponding action (in
the blue shape): Black, White, or Green.
In the top section of figure 17 a few details on one
of the adaptive models are shown. It deals with the
memory span of the models, i.e. after how many
responses should the model start to forget previous
experiences. In this case the model will forget its
first prediction (and the corresponding customer
response) when the 251st response comes in.
The second section in figure 17 configures when
and how the input data to the adaptive model (age
and gender in the example used above) need to be
re-analyzed to potentially adapt and optimize the
grouping (i.e. <30, 30-40, >40 for the age attribute).
The last section configures the so-called
performance memory: to be able to compare
different adaptive models with different size
memories, there has to be agreement on
the number of cases on which the predictive
performance (i.e. accuracy of the predictions)
is calculated.
The green shape in figure 16 is prioritizing the
different actions, in this case, based on the likelihood
of success (.pyPropensity in the screenshot). Its this
last shape in the sequence that effectively deciding
on the best choice reports back to the process on
how to proceed. In figure 18 the metric is defined that
decides on the best choice. In figure 18 its simply the
action with the highest (i.e. top 1) probability that is
chosen, but the field marked Priority can be used to
define a more complex expression as well.
Its this final prioritization that, in the process flow,
implements the decision about which direction to
choose: Black, Green, or White.
Figure 16:
Simple decision strategy
Figure 17:
Adaptive model configuration
Figure 18:
Configuring the priority
This sample process flow in figure 19 runs the decision strategy discussed above and
then, based on the outcome, pursues a Black, Green, or White action, whatever those
may be. When the customer response to the chosen direction is fed back to Pegas
Adaptive Decisioning Manager, the adaptive models (also the two that werent picked
to drive the flow) will learn from their successes and failures to predict the right
course of action.
Figure 19:
Decision strategy in process
Adaptive Through Champion Challengers
The previous section described how adaptive decisioning can continuously learn and
adapt through modifying the propensities of next best actions dynamically. Adaptive
decisioning is a very powerful decisioning technique that learns from the responses
and behaviors of customers to optimize decisioning. Strategy designers often have
a champion strategy that becomes the source of the next best action options
with various probabilities or propensities. The champion is their favorite deployed
strategy. The champion strategy could be based on predictive models, adaptive
models, scores, or other decisioning strategies. This champion is the current
envisioned optimal option based on intuition or experience. In the presence of
multiple decisioning strategy options, it does not necessarily reflect the true optimal
strategy for a particular automated process solution. So there could be challengers
to the champion strategy. For instance, the champion could be a predictive model
and challengers could include an adaptive strategy and a score. It could very well be
the case that one of these challengers is a better decisioning option and perhaps the
true optimal strategy. More importantly, as processes get executed and customers
behaviors change, the champion strategy could become obsolete. It needs to be
replaced by another new champion. These two complimentary objectives drive the
need for adapting to new champions through champion challengers.
The champion challenger approach therefore involves a champion and a number
of challengers. The underlying decision engine selects the champion most of the
time, but also occasionally tries out and selects the challengers. At design time, the
percentages for the various choices can be set by the strategy designer. For instance,
as illustrated in figure 20, the champion will be selected 60% of the time. The other
challengers will be selected 25% and 15% of the time respectively.
Predictive Model
Select Champion:
60% of the time
Challenger 1:
Score Model
Challenger 2:
Adaptive Model
Select Challenger 1:
25% of the time
Select Challenger 2:
15% of the time
and Results
Change the champion
Should the
Champion be
replaced by a
Figure 20:
The responses will be recorded. These responses, for instance customer choices
based on the champion or one of the challengers will be recorded in a database.
As time passes, the strategy designer could analyze and decide that one of the
challengers should become the new champion. The champion challenger strategy
map will then be updated and the adaptive cycle continues.
More than technology, this mechanism for
continuous experimentation is a methodology
for corporate agility, change, and instrumented
second guessing. Especially for strategies that
rely on assumptions, each assumption should
be challenged: size, placement, tone of voice
and other attributes of a web banner; product
pricing and incentives; or, at a higher level, entire
customer strategies. Even if empirical evidence
is used rather than assumptions, for instance a
(non-adaptive) predictive model, the environment
is changing and processes and decision
strategies thus need to be challenged and, where
the challenge is successful, adapted.
In figure 21 a champion/challenger rule selects randomly from, in this case, three
different methods to predict the financial risk associated with a loan application. The
top yellow shape represents a scorecard, which assigns points to customer attributes
to arrive at a score. The middle is a decision table to express the relationship
between customer attributes and risk of default in a different way. Lastly, the bottom
shape indicates a predictive model where no assumptions are made about risk but
where the probability of default is automatically inferred from empirical evidence.
The champion/challenger rule in the red shape makes a random weighted selection
from the three models. As illustrated in figure 22, the weighting is 10%, 30%, and
60% of the cases. Over time, detailed reports will make clear which challenger, if
any, is worthy of becoming the new champion. The choice of three is arbitrary as is
the level at which to challenge; instead of picking from three different types of risk
models, entire strategies can be challenged.
Figure 21:
Figure 22:
Weightings for Champion/
Adaptation Through Simulation and Optimization
Above, various approaches have been discussed that allow an organization to swiftly
adapt processes to changing goals or circumstances. This section investigates how
some of this can be achieved in anticipation of actual changes to processes or even
the need for such changes. Take aviation. A pilot can adapt his or her landing skills
by practicing various approach scenarios in a flight simulator and thus acquire the
best practice. The process is still about landing descending, making the approach,
touch down but the decisions, when and how steep to descend, when and how fast
to turn, etc., can be honed to perfection. Similarly, what-if business scenarios can
be defined and tried out on historic (or manufactured) circumstances so changes to
decision strategies can then be tried out to find scope for improvements. This can be
a very effective way to adapt to changing circumstances; simulate various strategies
on real data and then commit to the strategy that delivers the best outcomes in the
business simulator.
Note that this kind of simulation is not a simulation of the process to judge its
efficiency, but a simulation of the business that runs these processes to judge
effectiveness. This kind of simulation is not designed, therefore, to prove that a
certain process meets a specific Service Level Agreement 95% of the time, but to
investigate, for instance, how many more products would have been sold (and at what
opportunity costs) if certain decisions embedded in the processes are changed.
This approach is only safe and meaningful when 1) the strategies being simulated
are the real strategies (not a spreadsheet approximation), and 2) the data they are
simulated on is the exact same data the actual strategies are (or have been) applied
to. Lets consider a scenario where a bank is communicating with its customers
across multiple channels about a variety of products and services. As earlier
examples in this paper have also suggested, this is an area where adapting to the
ever-changing whims of the customers and market dynamics is a real challenge.
Assume our hypothetical bank is executing processes and decision strategies
and assessing the outcomes. Outcomes, in this context, could include, but are not
restricted to:
1. The volume of Platinum cards successfully offered to some customer
segment in some channel;
2. The agents in the call center that have (not) been successful in converting a
Platinum card offer into a sale;
3. The effect of the Platinum card strategy effect on revenues, risk, customer
satisfaction, etc.
4. The effect of the Platinum card strategy effect on the sales of saving and
loan products.
Resorting to traditional Business Intelligence (BI), many organizations could probably
get answers to 1 and 2, albeit most likely well after the fact. That delay in itself
means its not possible to quickly adapt, should the answers to 1 and 2 not meet
expectations. The answer to 3 may look deceptively simple at first glance but 4
suggests that the answer may not be that straightforward: what if the Platinum card
strategy does indeed add $5 million to the bottom line but at the expense of product
B? What if product B could have generated $7.5 million? This is where the business
flight simulator comes into play. Suppose this bank could simulate what would
happen if product B would have been part of the mix. It would be like a hindsight
champion/challenger. Imagine this works across multiple strategies (for B, C, D,
etc.) and it could also be used in the same situations where a champion/challenger
approach would be advisable: challenging a price, an incentive, a form factor.
These two approaches, champion/challenger and simulation, are actually
intertwined. Using champion/challenger approaches, the bank, in this case, would
automatically create data points for various scenarios: offering B instead of the
Platinum card, offering B with a lower interest rate, etc. Those data points in turn
are useful when business simulations are ran of strategies that could have been in
place but werent. Equally important in this respect is the use of predictive analytics.
A propensity model predicting the likelihood of a customer accepting an offer can
also be used in circumstances where in practice a different offer was made. Changing
the eligibility criterion for a Platinum card from, say, an age of 21 down to 18 could
still be simulated even when no 18 year-old has ever been offered a Platinum card
before. The reason for this is that the propensity model (or credit risk model, for that
matter), looking at many more attributes than age alone, might still be able to make
a reasonable estimate as to the likelihood of an accept (or default). In this example
the bank might be able to approximate the business implications of changing the
minimum age of a Platinum card holder from 21 to 18 years old.
Organizations need to move to a level where their operations are virtualized: captured
in process designs and decision strategies. Only then will it be possible to simulate
change and adapt to circumstances that have not even happened yet. Less perfect, no
doubt, than a flight simulator where aviation physics are supposedly a known quantity,
but a big step up compared to trial and error. After all, hope is not a strategy.
Figure 23:
Processes and Decisions
Only a unified environment can ensure seamless collaboration between processes
and decisions. Both can only be understood, or simulated, in close conjunction.
Take a loan origination process; the process flow is intertwined with, but independent
of, the decision strategy that determines which customers are eligible for a loan
based on their risk profile. The designers of the process flow need not know, are
perhaps not even allowed to know, about the risk models that drive the flow. Certainly
the expertise required to define the flow is very different from the expertise required
to design the risk models. Change cycles are also likely to be different. The process
flow may change whenever front- or back-office systems change, when actors in
the process are added or removed, when different SLAs are put in place, etc. In
contrast, the risk decision strategies will change when the risk appetite of the bank
changes, when the risk profile of customers and prospect change (for instance due
to economic circumstances or the implications of new tax laws), or when the central
bank imposes different exposure requirements.
In Pega BPM this observation is used to support a simulation environment which
keeps the processes static while offering deep simulation of (or variants on) decision
strategies. Consider the cockpit of the bank below:
Figure 24:
Visual Business Director (VBD)
In this particular view, this Pega cockpit allows the bank to see, in real-time, how
each of its products is doing in various customer segments in terms of acceptance
rate. In the actual Pega product, the customer dimension can be changed to channel
or any other system that implements decisions; the proposition dimension can be
changed to processes; and the business metric can be changed from accept rate to
any metric that can be defined in terms of the decisions taken (six of those can be
seen on the back panel).
But what if this was not a cockpit but a flight simulator? Where the banks cards
manager, rather than simply boosting sales for her silo wants to look first at the
consequences of doing so at the corporate level? Or perhaps the overall sales
manager would like to have that view before allowing her to make change. In that
case, instead of deploying the new marketing weight (and any other changes she may
have made), she may want to simulate her changes first.
Figure 25 shows the three steps in the simulation process: simulation, consolidation,
and deployment. First the simulation itself. This involves all the cards managers
changes to the strategies (an increase of a marketing weight parameter in this
case) to be applied to a chosen historic timeframe. The simulation will re-run all
the predictive models, rules, and decisions on the exact same data to which they
have been applied during the selected time window. The results can be presented in
many ways within Pega BPM but one variation is to look at the deltas of the orginal
outcomes and the what-if outcomes as a result of the simulations.
Figure 26 shows, using cones instead of bars to emphasize this delta view, that the
cards manager achieved the effect (in green, positive cones) of boosting credit cards
sales. Quickly zooming in to the particulars reveals that, as expected, the platinum
Figure 25:
Simulation in VBD
Figure 26:
Emphasizing deltas in VBD
card is causing the increase (across both the call center and web channel). Because
we are looking, in this case, at the accept rate and not just volumes, this does actually
indicate that customers appreciate the offer. So whats not to like? The bigger picture
is whats not to like. Within the cards category, the boost of the platinum card shows
no significant effect on the sales of other cards (presumably because the eligibility
criteria makes them mutually exclusive to some extent). But one level higher, shown
above in figure 26, the negative effect on other product sales is huge. This unified
view, very hard to come by using general purpose BI tools, shows how the outcomes
for mortgages, loans, and insurance products will take a big hit if the cards manager
gets her way. Part of this can be opportunity costs; pushing the platinum card during
any possible interaction on the Web and in the call center leaves only suboptimal
channels to push other products. Apparently, in those channels the accept rate is not
nearly as high as in the inbound channels. But this can also be caused by more subtle
dynamics. Perhaps a less expensive credit card leaves customers more spending
room to buy other products. Its only a very granular simulation that can show these
cannibalization effects that will surely prompt a corporate-oriented cards manager
(or her manager) to pull back on the platinum card throttle.
Reality, however, is a bit more complex than the above suggests. The cards manager
may not have been the only one running simulations. Perhaps the mortgage manager
is doing a similar thing. The call center manager may be interested in forecasting
volumes over the coming months (see figure 27). To approximate the combined effect
of all those changes the various simulations need to be consolidated for an overall
picture. To ensure this is reliable (and different simulators dont flex the same levers
at the same time) the simulations are applied after another and only one simulation
can run at any one time.
This process is essentially adapting the virtual bank to historically observed
circumstances. Once the consolidated results usually reflecting a compromise
between the various stakeholders that maximizes globally agreed business objectives
are to everyones liking, the adapted strategy can be deployed into the live system
for instant change across all connected processes. At that moment, the real bank
will adapt to mirror the decision strategies of the virtual bank, i.e. the banks flight
simulator. This approach of planning, monitoring, simulating, consolidating, and
changing the way the organization does business is an example of an adaptive
enterprise making informed course corrections to stay ahead of the competition in a
world of change.
Figure 27:
Forecasting volumes in VBD
Pega is the industrys leading platform that is holistic in its support of adaptive
enterprises. Adaptive enterprises need to support change continuously. The change
requirements emanate from a plethora of sources and/or reasons. Changes are also
of different granules: simple policy changes to complete innovative solutions in target
markets or sectors.
The seven dimensions for adaptive enterprises can be summarized as follows:
` Continuously monitored and optimized measurable business objectives:
Pega supports business activity monitoring, KPIs, and perhaps more
importantly the ability to drill down from measurable results to executing
cases to effect change.
` Continuous innovations through re-use and specialized, contextual and
situational solutions. Pegas unique and patented situational layer cake
allows adaptive enterprises to achieve two key objectives that sometimes
conflict: re-use or sharing of solutions while easily specializing for contexts
involving geographical locations, specific services, or customer types.
` Continuously discovering requirements with iterative enhancements:
Through Pega, organizations can easily and directly capture the business
requirements in one cohesive tool. Pega is a complete platform: business
processes, business rules, case type information models, user interactions
(or UI), strategic decisioning, and integration with custom or legacy solutions
within the enterprise.
` Continuously improving automated work and dynamic case management
solutions: Pega supports the whole spectrum of work and workers. In
addition to structured/predetermined or planned workflows, Pega supports
unplanned, collaborative dynamic cases. This provides visibility to the entire
case, the case subject, the case content, the case tasks, and case objectives.
More importantly it allows case workers including knowledge assisted
workers to dynamically discover process fragments, tasks, or to change
case hierarchy as well as content.
` Continuously gaining insight by learning and automatically adapting
decisions: In its dynamic cases and processes, Pega can embed self-learning
predictive models to drive flow choices or other decisions. Learning from
success and failure to predict the right course of action, decisions that
embed such models are continuously optimizing themselves in response to
change. This built-in calibration objectively course corrects the dynamic case
management solution and in addition, greatly reduces the dependency on
humans for supervision and change.
` Continuous adaptation by challenging champions: Pega methodologically
supports the challenging of decision strategies at any level of granularity by
one or more alternative approaches. This encourages an innovative culture
of continuous experimentation where every approach is challenged and
replaced when the alternative is better. The result is an adaptive system that
can respond quickly to changing circumstances.
` Continuously monitor, simulate and control decision priorities: With a built-
in feedback loop, Pega allows the effectiveness of decisions to be tracked in
real-time and instant tactical changes to be instantaneously implemented
whenever a course correction is required. Ahead of such a correction the
business impact can first be simulated by applying the freshly adapted
strategies to the actual, historic decision input data.
These seven dimensions combined and unified in one robust adaptive platform helps
organizations become adaptive enterprises. With Pega, Fortune 500 companies in
various industries have achieved tremendous business results including generating
increased revenue, optimizing the customer experience, and continuously improving
efficiencies. But more importantly, Pega helps organizations transform themselves
to adaptive enterprises, with continuous iterative improvements, through thinking
big but yet starting small with incremental wins.
About Pegasystems
Pegasystems, the leader in business process management and software for customer centricity,
helps organizations enhance customer loyalty, generate new business, and improve productivity. Our
patented Build for Change

technology speeds the delivery of critical business solutions by directly

capturing business objectives and eliminating manual programming. Pegasystems flexible on-
premise and cloud-based solutions enable clients to quickly adapt to changing business conditions
in order to outperform the competition. For more information, please visit us at
Copyright 2012 Pegasystems Inc. All rights reserved. PegaRULES, Process Commander, Pega BPM

and the Pegasystems logo are trademarks or registered trademarks of Pegasystems Inc. All other product
names, logos and symbols may be registered trademarks of their respective owners.

You might also like