Discussing the dynamic of change of operational decisions and its impact on decision automation and management

1. © 2015 IBM Corporation© 2015 IBM Corporation
Operational Decisions Management 101
Alain Neyroud,
Program Director, Decision Management IBM
Pierre Berlandier,
STSM, Decision Management IBM

2. © 2015 IBM Corporation
Decisions 101
• Setting the Stage
• Operational Decision Management
• Decision Engineering
• A few more considerations

3. © 2015 IBM Corporation
Setting the Stage
Operational Decision Management 101
2

4. © 2015 IBM Corporation
What are we discussing
3
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

5. © 2015 IBM Corporation
Candidate Decisions
4
Strategic
Tactical
Operational
Frequency of OccurenceLow
Valueofasingle
decision
High
Low
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)).

6. © 2015 IBM Corporation
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
…
Decision
Variation
s
Jurisdiction
Product
Channel
Market
Segment
…

7. © 2015 IBM Corporation
When should you consider Operational Decision
Management
• Significant Decision
Variations
• Significant Change
Dynamics
• Other influencing factors
– Visibility
– Traceability
– Auditability
Change Dynamics
DecisionVariation

8. © 2015 IBM Corporation
Qualifying Changes applied to Operational Decisions
Disruptive
Evolutive
Adaptative
Ex: update existing rate sheet
Ex: provide new type
of vehicle coverage
Ex: enter new LOB
(auto vs property)
Impact of change
Frequency
Run the business
Change the business
Low High
Low
High

9. © 2015 IBM Corporation
High
8
Anticipating the nature of Decision Changes
Disruptive
Evolutive
Adaptative
Ex: update existing rate sheet
Ex: provide new type
of vehicle coverage
Ex: enter new LOB
(auto vs property)
Operation (80%)
Engineering (20%)
Predictability
(ability to anticipate the change in advance)
Frequency
Low High
Low

10. © 2015 IBM Corporation
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
9

11. © 2015 IBM Corporation
Operational Decision Management

12. © 2015 IBM Corporation
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
11

13. © 2015 IBM Corporation 12
Classical IT Change Management
12
Manage and Monitor
Initial
Requirements
Design
Construct
Test
Deploy
Software Development Lifecycle
> 1-3 months
Platform upgrade
Design
Construct
Test
Deploy
Functional Enhancement
Decision Change

14. © 2015 IBM Corporation 13
Operational Decision Management
Manage and Monitor
Initial
Requirements
Design
Construct
Test
Deploy
Software Development
> 1-3 months
Platform upgrade
Design
Construct
Test
Deploy
Functional Enhancement
Business Rule Change
Analyze
Author
Validate
Initial Rules
Deploy
Analyze
Author
Validate
Deploy
Analyze
Author
Validate
Deploy
Operational Decision Management
Change
Request
Analyze
Author
Validate
Deploy
< 1 week
Change
Request
Change
Request

15. © 2015 IBM Corporation
Traditional Software Lifecycle
Business IT Dev / QAAnalyst Support
Inception Elaboration Construction Transition Production
I1 E1 E2 T1C2 C3C1 Application Maintenance
Build-Time Run-Time

16. © 2015 IBM Corporation
Operational Decision Management Lifecycle
Inception Elaboration Construction Transition Production
I1 E1 T1C1 Decision Change Management
Build-Time Change-Time
E1 C1 C1

17. © 2015 IBM Corporation 16
Decision Change Management
Making the change process Easy, Safe and Predictable
Analyze
Author
Validate
Deploy

18. © 2015 IBM Corporation
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) 17
Analyze
Author
Validate
Deploy
Collaboration
Governance
Easy
Safe
Reliable

19. © 2015 IBM Corporation
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
Governance
Easy
Safe
Predictable

20. © 2015 IBM Corporation
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

21. © 2015 IBM Corporation
Decision Engineering

22. © 2015 IBM Corporation
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
Design
Rule Model
Define the
Verification
& Validation
Process
Define the
Governance
Process
Define
Change
Cases
Analyze
Author
Validate
Deploy
Collaboration
Governance
Easy
Safe
Reliable
Decision CenterBWL Rule Designer

23. © 2015 IBM Corporation
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.
22

24. © 2015 IBM Corporation 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.”
22/06/2016 © ILOG, All rights reserved 23
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

25. © 2015 IBM Corporation
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

26. © 2015 IBM Corporation
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

27. © 2015 IBM Corporation
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
Inception Elaboration Construction Transition Production
I1 E1 T1C1 Policy Change Management
Build-Time Change-Time
E1 C1 C1
Implement Decision Framework
Decision Capture and Implementation
Formalize Decision Model and Change
Cases

28. © 2015 IBM Corporation
BRM: Who Can/Shall Participate
Business
IT
Analyze
Author
Validate
Deploy
Analyze
Author
Validate
Deploy
Analyze
Author
Validate
Deploy
Time
Maturity

29. © 2015 IBM Corporation
How do we handle unanticipated change
28
Qualification
Unanticipated
Change
Request
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

30. © 2015 IBM Corporation
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