integrating business rules and business processes

51
Integrating Business Processes and Business Rules Michael zur Muehlen, Ph.D. Center of Excellence in Business Process Innovation Howe School of Technology Management Stevens Institute of Technology Hoboken NJ [email protected] 1

Post on 18-Oct-2014

41.907 views

Category:

Business


1 download

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

Page 1: Integrating Business Rules and Business Processes

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

Page 2: Integrating Business Rules and Business Processes

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

Page 3: Integrating Business Rules and Business Processes

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

Page 4: Integrating Business Rules and Business Processes

Rules + Processes =Simpler ProcessesHigher AgilityBetter Risk Management

4

Page 5: Integrating Business Rules and Business Processes

Why don’t Users like Processes?

AbstractRestrictiveIt’s not Excel

5

Page 6: Integrating Business Rules and Business Processes

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

Page 7: Integrating Business Rules and Business Processes

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

Page 8: Integrating Business Rules and Business Processes

8

Example

...

Send questionnaire

Send reminder

Completed questionnaire

...

After 5 days

Page 9: Integrating Business Rules and Business Processes

It’s not Excel

9

Page 10: Integrating Business Rules and Business Processes

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)

Page 11: Integrating Business Rules and Business Processes

Managing Change

Claims processing at major US Insurance company

12 Process Steps

>5,000 Business Rules

What do you think changes faster?

11

Page 12: Integrating Business Rules and Business Processes

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

Page 13: Integrating Business Rules and Business Processes

Integration Points

Control Flow DecisionsAssignment DecisionsMonitoring of Policies and Exceptions

13

Page 14: Integrating Business Rules and Business Processes

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

Page 15: Integrating Business Rules and Business Processes

Manual Decision Making

15

Manual Decision Making

Page 16: Integrating Business Rules and Business Processes

Manual Decision

16

Review Application

Applicationreceived

Process Case Type A

Process Case Type B

Process Case Type C

Page 17: Integrating Business Rules and Business Processes

Multi-Step Decisions

17

Page 18: Integrating Business Rules and Business Processes

18

Control Flow Decisions

Page 19: Integrating Business Rules and Business Processes

Control Flow Decision

19

Check Credit Score

Applicationreceived

Straight-through Process

Manual Review

Reject

>770

680<=770

<680

Page 20: Integrating Business Rules and Business Processes

Simpler Processes

20Loos (2007)

Page 21: Integrating Business Rules and Business Processes

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

Page 22: Integrating Business Rules and Business Processes

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

Page 23: Integrating Business Rules and Business Processes

Assignment Decision

23

Check Credit Score

Applicationreceived

Review by Intern

Review by Manager

Review by CSR

>770

680<=770

<680

Page 24: Integrating Business Rules and Business Processes

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)

Page 25: Integrating Business Rules and Business Processes

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)

Page 26: Integrating Business Rules and Business Processes

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)

Page 27: Integrating Business Rules and Business Processes

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)

Page 28: Integrating Business Rules and Business Processes

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)

Page 29: Integrating Business Rules and Business Processes

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

Page 30: Integrating Business Rules and Business Processes

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)

Page 31: Integrating Business Rules and Business Processes

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)

Page 32: Integrating Business Rules and Business Processes

Managing Risks

32

Page 33: Integrating Business Rules and Business Processes

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

Page 34: Integrating Business Rules and Business 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

Page 35: Integrating Business Rules and Business Processes

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

Page 36: Integrating Business Rules and Business Processes

Standards?

36

Page 37: Integrating Business Rules and Business Processes

BPMN - Modeling Notation

Page 38: Integrating Business Rules and Business Processes

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

Page 39: Integrating Business Rules and Business Processes

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

Page 40: Integrating Business Rules and Business Processes

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

Page 41: Integrating Business Rules and Business Processes

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

Page 42: Integrating Business Rules and Business Processes

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

Page 43: Integrating Business Rules and Business Processes

43

Page 44: Integrating Business Rules and Business Processes

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

Page 45: Integrating Business Rules and Business Processes

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

Page 46: Integrating Business Rules and Business Processes

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

Page 47: Integrating Business Rules and Business Processes

Getting Started

Some practical advice

47

Page 48: Integrating Business Rules and Business Processes

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

Page 49: Integrating Business Rules and Business Processes

49

Identify Business Objectives

Identify Business Activities

Identify Process Objectives

Identify Core Processes

Create Rules Model Processes

Create Detailed Rules Model Detailed Processes

Page 50: Integrating Business Rules and Business 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

Page 51: Integrating Business Rules and Business Processes

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