integrating business rules and business processes
Post on 18-Oct-2014
41.907 views
DESCRIPTION
Presentation given at the IIR Business Process Management Conference, San Diego, CA, November 13th, 2007. It focuses on the difference between rules and processes, the integration points of BPMS and BRMS, and ways to get started.TRANSCRIPT
Integrating Business Processes and Business RulesMichael zur Muehlen, Ph.D.Center of Excellence in Business Process InnovationHowe School of Technology ManagementStevens Institute of TechnologyHoboken [email protected]
1
2
Private university, founded 1870‣ 1800 undergraduate, 2600 graduate students‣ Located in Hoboken, NJ (across the Hudson from Manhattan)
Four Schools‣ Technology Management‣ Engineering‣ Systems and Enterprises‣ Arts & Sciences
Rankings:‣ Top 5 technology management program, on par with Stanford,
MIT, CMU, Babson (Optimize Magazine)‣ #1 for best distance learning program (Princeton Review)‣ Top 25 for most connected Campus (Sloan Foundation)
http://www.stevens.edu
3
Offers MBA in Technology Management, Master of Science (IS, Telecom Mgmt, Mgmt, EMTM), Bachelor’s Degree (Business & Technology)Programs taught on campus and off-site in corporate locationsClients: ADP, Avaya, BASF, Bristol-Myers Squibb, Chubb, Citigroup, Deutsche Bank, J&J, Lockheed, Merrill Lynch, PaineWebber, Pearson, Prudential, PSE&G, UBS, UPS, Verizon and othersResearch centers with focus on‣ Process Management
‣ Project Management
‣ Product Innovation
http://howe.stevens.edu
Rules + Processes =Simpler ProcessesHigher AgilityBetter Risk Management
4
Why don’t Users like Processes?
AbstractRestrictiveIt’s not Excel
5
Too Abstract
Process thinking requires a lateral view of the organization
Process thinking requires to generalize from the day-to-day business
Process thinking is expressed in (semi-) formal notation
6
http://farm1.static.flickr.com/177/429319452_08923116cd_b.jpg
Too Restrictive
Try modeling the following:Manufacturing can start anytime after the payment from the customer has been received
An inventory check, a credit check, and a regulatory check have to be performed - in any order
After quotes from 3/4 of the eligible suppliers have been received, or after three days (whichever is earlier) a selection is made
Users tend to think in “If-Then” scenarios
7
8
Example
...
Send questionnaire
Send reminder
Completed questionnaire
...
After 5 days
It’s not Excel
9
BPM: The Promise of Agility
We deployed BPM to achieve three things:
Shorten Processing Times
Increase Revenue
Enable Business Users to Change their Processes
We have achieved the first two, but failed on the third.
10
“Royce (2007)
Managing Change
Claims processing at major US Insurance company
12 Process Steps
>5,000 Business Rules
What do you think changes faster?
11
How many rules exactly?>90 product types and their associated product rules
>700 data edit rules
>70 claim pending rules
>200 types of correspondence letters
>250 claim processing and payment approval authority rules
>70 claim quality review sampling rules
>1,000 special client claim handling rules
>2,000 federal/state regulatory rules
>850 accounting rules
>600 published claim processing guidelines
12
Integration Points
Control Flow DecisionsAssignment DecisionsMonitoring of Policies and Exceptions
13
Control Flow DecisionsUsing Business Rules Engine to make data-based decisions about the sequence of processing steps
From Workflow: Workflow-relevant data
From BRMS: Branching decision
Useful if multi-criteria decisions are needed
14
Manual Decision Making
15
Manual Decision Making
Manual Decision
16
Review Application
Applicationreceived
Process Case Type A
Process Case Type B
Process Case Type C
Multi-Step Decisions
17
18
Control Flow Decisions
Control Flow Decision
19
Check Credit Score
Applicationreceived
Straight-through Process
Manual Review
Reject
>770
680<=770
<680
Simpler Processes
20Loos (2007)
Decision RulesSample Applications
Customer Contact Scripts
Validation of data before processing
Complex decision scenarios
Mining of rule criteria from runtime data
Model process with high fidelity
Run process and record audit trail
Apply statistical analysis techniques to uncover correlation between process data and process path
21
Assignment Decisions
Use BRMS to route work to the most qualified performer
From Workflow: Assignment-relevant Data
From BRMS: Identifier of qualified resource(s)
Useful if assignment decisions are made based on data of the workflow object
22
Assignment Decision
23
Check Credit Score
Applicationreceived
Review by Intern
Review by Manager
Review by CSR
>770
680<=770
<680
24
Sample RuleIf channel equals agency,
and plan equals mortgage term or whole life, and region equals Midwest, and age is greater than 18 and less than or equal to 65,and face amount is more than $250,000 and less than $1,000,000,and policy is a conversion from existing policy
Then assign to Midwest Level 1 Underwriter Group.
No Channel Region Age Face Amount Conversion? Assignment
1 Agency Midwest 18<=65250,000
<=1,000,000 noMidwest Level 1 Underwriter Group
2 Brokerage East 18<=65 >=1,000,000 yesEast Level 2 Underwriter Group
3 Agency South 18<=65 <250,000 no Underwriter Assistant Group
Source: Royce (2007)
25
Original System
Network
FileNetImage System
Workflow
1. Application is scanned into
FileNet.
2. Data is enteredInto Admin Systems.
3. Application is assignedto Underwriter during
indexing process.
4. Underwriting Begins
AdministrativeSystems
5. Workflow and associated route work through the business process based on the kind of policy.
Source: Royce (2007)
26
Rule Engine Driven Assignment
Network
FileNetImage System
AdministrativeSystems
Workflow,Rule Engine and Robot
1. Application is scanned into
FileNet.
2. Data is entered into Admin Systems and used by Rule Engine.
3. Applications are distributed based on availability and skill level
and Admin Systems Are Updated.
4. Underwriting Begins
Assignment Engine
Source: Royce (2007)
27
Practical Experience
“Right before going into production the underwriting department re-organized requiring the change of almost 100 assignment rules. These were all done by the business analyst who continues to make changes today.”
“The rule engine was also used to “auto-issue” some of the highest volume insurance products. Currently over 20% of the most popular products are issued without a review by an underwriter.”
“
Source: Royce (2007)
28
Imaging System24/7 Issue System
Workflow and Rule Engine
App is Scanned and OCR’ed
Data EntryAnd Validation
Admin System
Rule Engine validatesApplication information
and Issues some policies
Underwriter reviews APS’s and some complex cases
Producer receives policy
for delivery.
Moving to Exception Based Underwriting
Expanded Rules with Automatic Interface functionality may include:Straight-through processingIntelligent requirement processingAutomated issueMinimized admin system entryWorkload Balancing
Source: Royce (2007)
Cross-Process PoliciesUse BRMS to coordinate across process instances
Example: During labor action, hold all non-critical orders
Requires API for process control at the BPMS level
29
ERP BPM ECM
Legacy
EAI
Custom
Business Operations Control
Event Detection & Correlation
Predictive
SimulationHistorical
Analytics
Real Time
Dashboards
Alerts & Actions
Data Mining
Optimization
Event Bus
30Shapiro (2007)
Actions & Alerts
ProcessMetrics
GoalsThresholds
Risk Mitigation
KPI Evaluation
Action Schedule
Web Service Callor
Execute Script
Actions
Rules Engine
Email and Cellphone notification
Process Event
Triggers
31
Real Time
Dashboards
Alerts & Actions
Shapiro (2007)
Managing Risks
32
33
ComplianceCompliance means adherence to rules and regulations
Process models provide execution rules
Control flow: What happens when?
Task allocation: Who is involved?
Role models: Who may do what?
But what about context?
Business object dependencies: Value/Customer Type
Environmental dependecies: Season/Off-season processing
Regulatory compliance: Documentation/Audit
Correlation of multiple processes
34
Managing Risk with BPMSUse formal Process Models to ensure process compliance
Process Models can be scripts or mapsIf Scripts: Use BPMS to automate control flow, task allocation, application/service invocationIf Maps: Use collaborative tools to allow execution flexibility
BPMS provide risk management servicesAuthorizations / Access ControlEnforcement of routings, reviewsAudit capability to document compliance
Managing Risk with BRMSUse Business Rules to ensure contextual compliance
Document process objectives to prevent business rules from turning into process rulesPerformance Objectives combine BAM with BRMSDecision rules allow context-dependent enforcement of oversight
Use Business Rules Management System to enforce complianceDocument rules limit the state changes on documentsExample: Can’t go from draft to approved without reviewCustomer rules configure case handling
35
Standards?
36
BPMN - Modeling Notation
BPMN 1.1
38
Mainly cosmetic changes
New symbol for Multiple Event and Gateway (used to be star)
New Signal Event
Separation of “catching” and “throwing” events
0
30
60
90
120
Nor
mal
Flo
wTa
skE
nd E
vent
Sta
rt E
vent
/ E
vent
Poo
lD
ata-
Bas
ed X
OR
Sta
rt M
essa
geM
essa
ge F
low
Text
Ann
otat
ion
Par
alle
l For
k/Jo
inG
atew
ayLa
nes
Sub
-Pro
cess
(Col
laps
ed)
Ass
ocia
tion
Dat
a O
bjec
tIn
term
edia
te T
imer
End
Ter
min
ate
Inte
rmed
iate
Mes
sage
Sub
-Pro
cess
(Exp
ande
d)E
nd L
ink
Def
ault
Flow
Incl
usiv
e D
ecis
ion/
Mer
geA
ctiv
ity L
oopi
ng'e
xcep
tion'
task
End
Mes
sage
Sta
rt L
ink
End
Exc
eptio
nC
ompl
ex D
ecis
ion/
Mer
geE
vent
-Bas
ed X
OR
Gro
upM
ultip
le In
stan
ceIn
term
edia
te E
vent
Tran
sact
ion
Com
pens
atio
nC
ondi
tiona
l Flo
wE
nd C
ance
lE
xcep
tion
Flow
Inte
rmed
iate
Com
pens
atio
nIn
term
edia
te L
ink
Sta
rt T
imer
End
Com
pens
atio
nIn
term
edia
te M
ultip
leIn
term
edia
te R
ule
Off-
page
con
nect
orS
tart
Rul
eC
ompe
nsat
ion
Ass
ocia
tion
End
Mul
tiple
Inte
rmed
iate
Can
cel
Inte
rmed
iate
Exc
eptio
nS
tart
Mul
tiple
Practical Use of BPMN Symbols
39
Source: Sample of 120 BPMN models
BMM - Means and Ends
40
BMM Adopted Specification 13
Note: Categories of desired result include: goal, objective
desired result is supported by course of action
Synonymous Form: course of action channels efforts towards desired result
goal is quantified by objective
Synonymous Form: objective quantifies goal
Figure 8.3: - Desired Results — Goals and Objectives
A Desired Result is an End that is a state or target that the enterprise intends to maintain or sustain. A Desired Result is
supported by Courses of Action.
Compared to an Objective, a Goal tends to be longer term, qualitative (rather than quantitative), general (rather than
specific), and ongoing. Compared to a Goal, an Objective tends to be short term, quantitative (rather than qualitative),
specific (rather than general), and not continuing beyond its timeframe (which may be cyclical).
Objectives differ from Goals in that Objectives should always be time-targeted and measurable. Goals, in contrast, are
not specific in these ways.
Desired Results are supported by Courses of Action, which can be either Strategies or Tactics. Generally, Goals are
supported by Strategies, and Objectives are achieved by Tactics1.
In many enterprises there is a continuum from major Strategies that impact the whole of the business to minor Tactics
with limited, local effects. The dividing line between 'minor Strategy' and 'major Tactic' is blurred. Also, over time,
some Courses of Action may evolve from Tactic to Strategy, and some Strategies may devolve into Tactics. Some
enterprises do make a hard distinction between Strategies and Tactics; these enterprises may choose to pair Strategies only
with Goals, and Tactics only with Objectives.
1. An enterprise that prefers to strictly maintain this pairing can do so by specifying an appropriate constraint. It may also want to
specialize the Model for its own use by replacing the fact type desired result is supported by course of action with two more
specific fact types: goal is supported by strategy; objective is achieved by tactic
end
visiondesired result
goal objective
course of action
strategy tactic
supported by
channels efforts towards
quantified by
quantifies
24 BMM Adopted Specification
Synonymous Form: desired result has achievement supported by directive
directive is motivated by assessment
Synonymous Form: assessment provides impetus for directive
directive is motivated by potential impact
Synonymous Form: potential impact provides the impetus for directive
Figure 8.8: - Interrelating Directives with Courses of Action and Ends
As the name suggests, Directives indicate how the Courses of Action should, or should not, be carried out — in other
words, they govern Courses of Action. Specifically, a Directive defines or constrains or liberates some aspect of an
enterprise. It is intended to assert business structure or to control or influence the behavior of the business, and is stated
in declarative form.
Directives govern Courses of Action. For example, the Business Rule "Pizzas may not be delivered beyond a radius of
30 miles" governs the Strategy "Deliver pizzas to the location of the customer's choice." This governance applies to
Tactics as well. For example, the Tactic "Encourage rental extensions" is governed by the Business Policy "Allow
extension of rentals by phone."
It is expected that all Courses of Action should be governed by some Directive, especially as the business plans evolve
and become more coherent and complete. Any Course of Action not governed by a Directive should be examined
carefully to discover potential omissions.
On the other hand, having too many Directives may become unduly constraining. The correct balance in this regard can
only be identified by having in-depth knowledge of the context and intent of the business people participating in the
planning.
In striking this balance it should be remembered that, unless a Directive is made explicit, it is assumed that no constraint
on other elements of the business plans will be exercised. 'Unstated' Directives simply cannot be addressed in the Model
– quite literally, they can be recognized only by stating them2. To be taken into account within the Model, every
Directive must be explicit and recorded in an official manner3.
means
course of action
strategy tactic
directive
business policy business rule
desired result
supports
achievement of
has achievement
supported by
governed by
governs
formulated based on
source of
BMM - Means and Ends
41
SBVRSemantics of Business, Vocabulary and Rules
Formally defined taxonomy to describe elementary business operations and rules
Meta model expressed in UML
Business-level specification aims at enterprises to formally express their operations
42
43
Production Rule RepresentationExchange format for Business Rules (Production Rules)
Defined by Fair Isaac & Co and ILOG
Current revision submitted 09/03/2007
PRR Core defines basic meta model
PRR OCL defines conditions and actions
44
PRR Focus
Submission to Production Rule Representation
3. Production Rule Representation
3.1 Introduction to PRR-Core and PRR-OCL
The following MOF2 compliant metamodel defines the PRR. It features:
!" A definition of production rules for forward chaining inference and procedural processing.
!" A non-normative definition for an interchangeable expression language (PRR OCL) for rule condition and action expressions, so they can be replaced by alternative representations for vendor-specific usage or in other standards.
!" A definition of rulesets as collections of rules with a particular mode of execution (sequential or inferencing).
The metamodel is composed of:
!" a core structure referred to as PRR Core
!" an non-normative abstract OCL-based syntax for PRR expressions, defined as an extended PRR Core metamodel referred to as PRR OCL.
Future extensions of PRR may address:
!" rule metamodels for other classes of rules, such as Event-Condition-Action (ECA), backward chaining, and constraints
!" rule representations that are specific to graphical notations, such as decision tables and decision trees
!" representations of sequences of rulesets within larger decisions
!" transformations between PRR and other MDA models such as SBVR.
Other concrete syntaxes may be applied to PRR Core in future. To this end, the PRR is designed to be extensible.
Production Rules fit into the following rule classification scheme (supplied by the RuleML Initiative), although they are a subclass of Computer Executable Rule rather than Rule to avoid confusion with other uses of “Rule” as a metamodel class.
DerivationRule ReactionRuleIntegrityRule
SQL:1999
Assertion
ProductionRule
ECARule
SQL:1999 Trigger
SQL:1999 View
OCL 2.0 Invariant
XSB 2.6 Prolog
Rule Jess 3.4 Rule
ECAPRule
TransformationRule
XSL 1.0 Rule
MS Outlook 6 RuleOracle 10g
SQL View
ILOG JRule BlazeAdvisorRule
Rule
InferenceRule ProdeduralRule
{OR}
Rule classification
per Gerd Wagner, RuleML
17 PRR Taxonomy
45
SWRL and RIFSemantic Web Rules Language - Proposal submitted to W3C
Rules Interchange Format - Initiative within W3C
SWRL combines OWL and RuleML, some use in practice
RIF is in very early stages, but keep an eye on it
46
Getting Started
Some practical advice
47
48
Business Rules Business Processes
Business Objectives Business Activities
Process Objectives
Business Rules Business Processes
Operational Rules Work Processes
govern & prioritize
govern
govern
use
use
govern
Core Processes
49
Identify Business Objectives
Identify Business Activities
Identify Process Objectives
Identify Core Processes
Create Rules Model Processes
Create Detailed Rules Model Detailed Processes
Classifying Change
50
Frequency
Scope
Responsibility
Trigger
Predictability
Persistency
Hourly Daily Monthly
Company-wide Multi-Process Process Activity
Infrequent
LOB Biz Analyst System Analyst Programmer
External Biz Partner Internal
Low Medium High
Instance Days Months Permanent
51
Thank You – Questions?
Michael zur Muehlen, Ph.D.Center of Excellence in Business Process InnovationHowe School of Technology ManagementStevens Institute of TechnologyCastle Point on the HudsonHoboken, NJ 07030Phone: +1 (201) 216-8293Fax: +1 (201) 216-5385E-mail: [email protected]: http://www.cebpi.org