Operational Decisions Management 101

© 2015 IBM Corporation© 2015 IBM Corporation

Operational Decisions Management 101Alain Neyroud,Program Director, Decision Management IBMPierre Berlandier,STSM, Decision Management IBM

© 2015 IBM Corporation

Decisions 101

• Setting the Stage• Operational Decision Management• Decision Engineering• A few more considerations


Setting the StageOperational Decision Management 101

3


What are we discussing

4

Decision A decision is the selection between possible actions.

Decision Making

Decision making can be regarded as the (cognitive) processes resulting in the selection of a course of action among several alternative scenarios. Every decision making process produces a final choice.

Decision Automation Decision automation is considered most appropriate for well-structured, clearly defined, routine or programmed (cf., Simon, 1960) decision situations.

Decision Management Decision management is a business discipline that enables organizations to automate, optimize, and govern repeatable business decisions


Candidate Decisions

5

Strategic

Tactical

Operational

Frequency of OccurenceLow

Valu

e of

a s

ingl

e de

cisi

on

HighLow

High Candidates for Decision Automation and Management

Operational Decision are repeatable, lower value decisions that typically relate to a single customer or a single transaction. Because of the number of times they must be made, consistency and repeatability are critical.

A repeatable decision is one that is made more than once by an organization following a well-defined, or at least definable, decision-making approach (Taylor, James (2011-10-13)).


Decision Variations and Change Dynamic

Decision Variations drive the complexity of the decision making process Decision Variations implies related change dynamics

– Few variations => few changes

– Many variations => Many changes

Decision Automation must support decision change dynamics– Otherwise the automated decision quickly become obsolete

Change Dynamics

Market Dynamics

Competition

Merger and acquisition

Regulation

…DecisionVariation

s

Jurisdiction

Product

Channel

Market Segment

…


When should you consider Operational Decision Management

• Significant Decision Variations

• Significant Change Dynamics

• Other influencing factors– Visibility– Traceability– Auditability

Change Dynamics

Dec

isio

n Va

riatio

n


Qualifying Changes applied to Operational Decisions

Disruptive

Evolutive

Adaptative

Ex: update existing rate sheet

Ex: provide new typeof vehicle coverage

Ex: enter new LOB(auto vs property)

Impact of change

Freq

uenc

y

Run the business

Change the business

Low HighLow

High


High

9

Anticipating the nature of Decision Changes

Disruptive

Evolutive

Adaptative

Ex: update existing rate sheet

Ex: provide new typeof vehicle coverage

Ex: enter new LOB(auto vs property)

Operation (80%)

Engineering (20%)

Predictability(ability to anticipate the change in advance)

Freq

uenc

y

Low HighLow


Take Away

• Operational Decisions are highly repeatable and therefore are good candidates for decision automation

• Decision variations and related change dynamics define the complexity of the decision making process associated with operational decisions

• The ability to manage decision changes is the most important factor to successful operational decision automation

• The majority of decision changes are adaptive in nature:– They are highly repeatable– Their impact is well understood

10


Operational Decision Management


Why anticipate the changes?

• Software engineering is about creating application capabilities that support defined Business requirements

• It is unlikely that an application will provide capabilities that support Business requirements that were NOT specified initially

• If Change is not a built-in capability of an application, it has to happen at engineering time

• In order for Change to be a built-in capability of an application, change requirements have to be specified initially

12

© 2015 IBM Corporation 13

Classical IT Change Management

13

Manage and Monitor

InitialRequirements

DesignConstruct

Test

Deploy

Software Development Lifecycle

> 1-3 months

Platform upgrade

DesignConstruct

Test

Deploy

Functional Enhancement

Decision Change



Manage and Monitor

InitialRequirements

DesignConstruct

Test

Deploy

Software Development

> 1-3 months

Platform upgrade

DesignConstruct

Test

Deploy

Functional Enhancement

Business Rule Change

AnalyzeAuthor

Validate

Initial Rules

Deploy

AnalyzeAuthor

Validate

Deploy

AnalyzeAuthor

Validate

Deploy


Change Request

AnalyzeAuthor

Validate

Deploy

< 1 week

Change Request

Change Request


Traditional Software LifecycleBusiness IT Dev / QAAnalyst Support

Inception Elaboration Construction Transition Production

I1 E1 E2 T1 C2 C3 C1 Application Maintenance

Build-Time Run-Time


Operational Decision Management Lifecycle


I1 E1 T1 C1 Decision Change Management

Build-Time Change-Time

E1 C1 C1


Decision Change Management

Making the change process Easy, Safe and Predictable

Analyze

Author

Validate

Deploy


The Outcome: Operational change management

• Explicitly support a well defined set of change scenarios (change cases)

• Executing a change cycle is relevant to business engineering,

• Executing a change cycle is NOT relevant to software engineering

• Change cycle shall be executed without interrupting system operation (no delivery of software)

• Change cycle shall preferably be executed by operation personnel (as opposed to engineering personnel) 18

Analyze

Author

Validate

Deploy

Collaboration

Gov

erna

nce

EasySafe

Reliable


The Outcome: Operational change management• Explicitly support a well defined set of

change scenarios (change cases)• Executing a change cycle is relevant to

business engineering, • Executing a change cycle is NOT

relevant to software engineering• Change cycle shall be executed

without interrupting system operation (no delivery of software)

• Change cycle shall preferably be executed by operation personnel (as opposed to engineering personnel)

19

Analyze

Author

Validate

Deploy

Collaboration

Gov

erna

nce

EasySafe

Predictable


Take away

• Adaptive changes occur frequently, it is desirable, if not mandatory, for these changes to be supported at operation time

• Adaptive changes and their related impact can be anticipated and it is possible for these changes to be supported at operation time

• Disruptive changes and their associated impact cannot usually be anticipated, it is only possible to support these changes at engineering time

• Operational Change Management provide the framework to manage decision changes at the operation level through a simple, safe and reliable process


Decision Engineering


Decision Engineering

• Each engineering cycle goal is to support one or more change case• Every aspects of the change case must be addressed in the cycle (e.g.

analysis, authoring, V&V, deployment, governance)

ProductionInception Elaboration/Construction

Characterize Decision

Evaluate Decision

Variability

DesignRule Model

Define the Verification & Validation

Process

Define the Governance

Process

Define Change Cases

Analyze

Author

Validate

Deploy

Collaboration

Gov

erna

nce

EasySafe

Reliable

Decision CenterBWL Rule Designer


Decision Discovery: The classic approach

• Find the Business Knowledge• Structure the Knowledge into English Language• Apply analysis to the knowledge to form it into rules• Document the rules, the rule sources, and the vocabulary used for the

rules.

23


Business Rules – a Mean to an End• “Business rules are an expression of business policy in a form that is

understandable to business users and that can be executed by a rule engine. From a business perspective, a business rule is a precise statement that describes, constrains, or controls some aspect of your business. From the IT perspective, business rules are a package of executable business policy statements that can be called from an application.”

03/05/2023 © ILOG, All rights reserved 24

IF the event type equals ‘payment transaction’ and the customer type is ‘corporate’ and the channel used is ‘the web’THEN apply a 30% discount to the standard fee


Decision Discovery: You don’t need all the rules

• Many decision discovery and analysis methods focus only on the formalization of decisions and rules and promote and exhaustive approach

• However, Decision changes over time so, by the time all rules are discovered, it is likely that a good proportion of them are already outdated

• Moreover, no effort is made to anticipate what type of change will occur in the future

• As a consequence, the resulting application may contain outdated rules and will not likely to be easier to change than any other system


Change Management Approach to Decision Discovery

One need to discover just enough rules to:• Characterize the decision model functionally

– Ex: what step are used to establish product eligibility

• Determine the variations on this decision model– Ex: product eligibility varies by product, by geography and by channel

• Establish the associated change dynamic– Ex: What trigger change in eligibility along those various dimensions

• Document the anticipated change case– Ex: Add a product, Add a state, update a product, update a state, etc.

• Specify how a change case shall be validated– Ex: establish how a new eligibility guideline should be verified

• Specify how a change case shall be governed– Ex: establish who is participating in a specific change case


Decision Engineering: The full picture

3 Major phases:• Formalize the decision model and the associated change cases• Design and implement an associated change management framework• Capture and validate the rules in the context of this framework


I1 E1 T1 C1 Policy Change Management

Build-Time Change-Time

E1 C1 C1

Implement Decision Framework

Decision Capture and ImplementationFormalize Decision Model and Change Cases


BRM: Who Can/Shall Participate

Business

IT

Analyze

Author

Validate

Deploy

Analyze

Author

Validate

Deploy

Analyze

Author

Validate

Deploy

Time

Mat

urity


How do we handle unanticipated change

29

QualificationUnanticipatedChangeRequest

Engineering supervised/executed Adhoc Change

Engineering of new Change Case

Will Repeat

One shot

If it is anticipated that this change will re-occur in the future then a decision engineering cycle should be executed to implement the new change case. Once the change case is implemented, change can occur at decision management time.

If it cannot be anticipated that this change will re-occur in the future then the change shall be implemented within an engineering cycle


Take away

• Executing a Decision Engineering project is not (just) about discovering and implementing all the rules at engineering time

• Executing a Decision Engineering project is about building a Decision Framework that will enable subject matter expert to discover, capture and change their decisions with minimum support from IT

Operational Decisions Management 101

Software

Transcript of Operational Decisions Management 101