Business Process Redesign using

planning

Abstract Business process redesign is being increasingly

considered as difficult. Because modification of model not only involves in fixing bugs or satisfying requirements, but also needs to consider costs, impact to the existing model and minimum changes. Furthermore, changes often cause other bugs which significantly increase spending. The purpose of this research is to offer a framework to design the better and optimized models based on the exist model or modify the original model which is not compliant to be compliant by considering business processes described in the industry standard BPMN notation.

Abstract

Purpose: Given a BPMN model, redesign it to provide better models or

modify non-compliant models to be compliant.Steps: 1. Exact the effects in BPMN model and translate it to

planning operators. Take and transform the goal in BPMN model as planning goal.

2. Let planners design models based on planning language.3. Transform plans generated by planners to BPMN models.4. Check proximity between BPMN models and the original

model. Find which model is closest to the original model.

Do Planning

Automated CompositionB

PM

N

Mod

el

Pla

nnin

g R

epos

itory

Pla

nner

Pla

n

BP

MN

M

odel

Che

ck

Pro

xim

ity

Business Process Modeling Notation

Business Process Modeling Notation (BPMN)BPMN provides businesses with the capability of defining and understanding their internal and external business procedures through a Business Process Diagram, which will give organizations the ability to communicate these procedures in a standard manner.

BPMN with effects

Effects

Receive Order: (have order) Fill order: (knows order accepted)

Send invoice: (invoice sent) Make payment: (make payment)

Effects in BPMN model can be used in planning to generate plans.

Planning

In recent years research in the planning community has moved increasingly towards application of planners to realistic problems involving both time and many types of resources.

Planning involves the representation of actions and world models, reasoning about the effects of actions, and techniques for efficiently searching the space of possible plans. 

Example -- Farmer's Dilemma Problem

The point is to get the farmer, the fox the cabbage and the goat across a stream. But the boat only holds 2 items. If left alone with the goat, the fox will eat it. If left alone with the cabbage, the goat will eat it.

A classic AI problem

What can I do?

Planning Solution

Solution 1: tFarmer moves with goat to shore-2. tFarmer moves alone to shore-1. tFarmer moves with fox to shore-2. tFarmer moves with goat to shore-1. tFarmer moves with cabbage to shor

e-2. tFarmer moves alone to shore-1. tFarmer moves with goat to shore-2.

Solution 2: tFarmer moves with goat to shore-2. tFarmer moves alone to shore-1. tFarmer moves with cabbage to shor

e-2. tFarmer moves with goat to shore-1. tFarmer moves with fox to shore-2. tFarmer moves alone to shore-1. tFarmer moves with goat to shore-2.

Transform domain knowledge to planning language and set up necessary rules. Then planner can help to do the rest of things!

The effects in BPMN model can be transformed into planning language and set up necessary business rules. Planners can help us to design business solutions according to business rules.

PDDL2.1

Domain Definition (define (domain A1-dom) (:requirements :conditional-effects :sensing) (:types object) (:constants letter address email start ready success - object) (:predicates (have ?o - object) (be ?o - object) (know ?o - object) (at ?o - object) (execute ?o - object) (send ?o - object))

PDDL is the standard language for the encoding of the planning domains.

Operator Definition

(:action go-to-western-at-A :parameters () :precondition (at start) :effect (and (on western) (on belmont) (not (at start)))) (:action check-traffic-on-western :precondition () :effect (observes (and (on western) (traffic-bad)))) (:action drive-truck :parameters (?truck - truck ?loc-from ?loc-to - location ?city - city) :precondition (and (at ?truck ?loc-from) (loc-at ?loc-from ?city) :effect (and (forall (?x - obj) (when (and (in ?x ?truck)) (and (not (at ?x ?loc-from)) (at ?x ?loc-to))))))

Goal Definition (define (problem A1-prob) (:domain A1-dom) (:init (at start) (not (on western)) (not (on belmont)) (not (on ashland)) (not (at evanston)) (uncertain (traffic-bad)) (not (error))) (:goal (and (at destination) (not (error)))))

(define (problem A2-prob) (:domain A2-dom) (:objects pkg1 pkg2) (:init (at pkg1 rug) (at pkg2 rug) (oneof (contains-bomb pkg1) (contains-bomb pkg2)) (not (bomb-disarmed)) (not (error))) (:goal (and (bomb-disarmed) (not (error)))))

Planner A computer software to help do the planning and design based on planning

algorithm and planning languages. Sensing action (:action check-traffic-on-western :precondition () :effect (observes (and (on western) (traffic-bad)))) Conditional Plan

Is Conditional Plan like a BPMN model?

Planners Help for Reasoning

Support extended goals: Do Reach p (“strong goal”): (af p) Try Reach p (“weak goal”): (ef p) Do Maintain p: (ag p) Try Maintain p: (eg p)

Planners support planning with uncertainty. (define (problem p) (:init (and (P1) (oneof (and (P3)) (P4)) (unknown (P5)))) )  (:action dunk :parameters (?pkg ?toilet) :precondition (toilet ?toilet) (:effect (and (P1) (oneof (and (P2) (P3)) (P4)) (unknown

(P5))))    ....)

Planners Help for Reasoning

Do Planning

Recall - Automated CompositionB

PM

N

Mod

el

Pla

nnin

g R

epos

itory

Pla

nner

Pla

n

BP

MN

M

odel

Che

ck

Pro

xim

ity

Transformation Transformation

Transformation between Planning Language and BPMN Model

Transform BPMN Task, Start Event and End Event to Planning Operator

An operator in planning is an expression of the form (Name Parameters(−!v ) Precondition Effect) where

Name = Name_Type. Type=(Task, Start Event or End Event) Parameters: Variables needed for effects of Task, Start Event or End E

vent Effect: Intermediate Effect of Task, Start Event or End Event.

Transform BPMN Intermediate Event to a WHEN clause and an operator which can be triggered by the WHEN clause.

An example: Operators have conditional effects.

Exception

(:action disarmBomb :parameters (?pkg ?bomb) :precondition (and (bomb ?bomb) (object ?pkg)) :effect (and (disarm bomb)

(when (have exception) (and (stop process) (trigger CompensationA))))

(:action CompensationA_triggerByEventXXX precondition (trigger CompensationA) effect (and (prepare support ) (offer help) )

Transform BPMN exclusive gateway to a sensing action.

Sensing action generates conditional plan A staff wants to inform students either by email or by lett

er. We assume he has either students’ email address or accommodation address, but not both.

MBP sensing action (:observation contactemail - boolean (imply (= contactemail 0) (not (have email))) (imply (= contactemail 1) (have email))) (:observation contactaddress - boolean (imply (= contactaddress 0) (not (have address))) (imply (= contactaddress 1) (have address))) Initial State (:init (at start) (oneof (have address) (have email) ) )

A example Domain Definition (define (domain notification) (:types object) (:constants letter address email start ready successful error - object) (:predicates (have ?o - object) (be ?o - object) (at ?o - object) (send ?o - object) (execute ?o - object) (inform ?o - object))

(:action receivenotification :precondition (at start) :effect (and (be ready) (not (at start))))

(:action sendletter :precondition (and (be ready) (have address)) :effect (and (when (and (be ready) (have address)) (and (send letter) )) (when (or (not (have address) ) (send letter)) (execute error)))) (:action sendemail :precondition (and (be ready) (have email) ) :effect (and (when (and (be ready) (have email) ) (and (send email) )) (when (or (not (have email)) (send email) ) (execute error)))) (:action informok :precondition (or (send letter) (send email) ) :effect (and (when (or (send letter) (send email) ) (inform successful))))

(:observation contactemail - boolean (imply (= contactemail 0) (not (have email))) (imply (= contactemail 1) (have email))) (:observation contactaddress - boolean (imply (= contactaddress 0) (not (have address))) (imply (= contactaddress 1) (have address))) )

Goal Definition

(define (problem notification_problem) (:domain notification) (:init (at start) (oneof (have address) (have email) ) ) (:postronggoal (and (inform successful) (not (execute erro

r)) ) ))

(define (plan ___undefined___) (:problem notification_problem) (:domain notification) (:body (sequence (action (receivenotification)) (switch (case (contactdetail ) (sequence (action (sendletter)) (action (informok)) (done) ) ) (case (not (contactdetail)) (sequence (action (sendemail)) (action (informok)) (done) )))))

Plan

Transform inclusive gateway to a sensing action and also assign all the combination of conditions of inclusive gate way in the initial state.

(define (problem notification_problem) (:domain notification) (:init (at start) (oneof (and (have address) (have email)) (and (have address) (not (have email)))

(and (have email) (not (have address))) )) (:postronggoal (and (execute success) (not (execute error)) ) )) Sensing Action - MBP (:observation contactemail - boolean (imply (= contactemail 0) (not (have email))) (imply (= contactemail 1) (have email)))

(:observation contactaddress - boolean (imply (= contactaddress 0) (not (have address))) (imply (= contactaddress 1) (have address)))

Use previous example

The only difference is that we can have email address or accommodation address or both of them.

We can use the previous domain and problem definition, but assign three probabilities in the initial state.

(define (problem notification_problem) (:domain notification) (:init (at start) (oneof (and (have address) (have email)) (and (have address) (not (have email))) (and (have email) (not (have address))) ) ) (:postronggoal (and (execute success) (not (execute error)) ) ))

(define (plan ___undefined___) (:problem notification_problem) (:domain notification) (:body (sequence (action (receivenotification)) (switch (case (contactaddress) (sequence (action (sendletter)) (switch (case (contactemail) (sequence (action (sendemail)) (action (informok)) (done) ) ) (case (not (contactemail)) (sequence (action (informok)) (done) ) ) ) ) ) (case (not (contactaddress)) (sequence (action (sendemail)) (action (informok)) (done) ) ) ) )))

Transform Parallel (AND) gateway Some planners can generate partial-ordered plans which

can be modeled as Parallel (AND) gateway.

An example( (((DOMAINS::RECEIVENOTIFICATION))) (((DOMAINS::SENDEMAIL)) ((DOMAINS::SENDLETTER))) (((DOMAINS::INFORMOK))))

Transform Activity Looping to an operator including a forall clause or many forall clauses.

An operator can include many forall clauses and forall causes can be nested in forall clauses.

(:action open_device :parameters (?d - engine_no, ?d - engine_power) :precondition (closed ?d) (forall (?e1 - engine_no) (forall (?e2 - engine_no) (ag (not (> (engine_power ?e1) (+ (engine_

power ?e2) 1))))))))) (forall (?door - Door) (open door))

Check Proximity To reduce costs and save time, we should make sure th

at a process model is being minimally modified to keep it as closer as possible to this original one. The more we change, the more errors models have and the more we invest.

Check proximity between variants and the original model. Select the one which is closest to the original one.

I build a tool based on the following paper to check proximity.

Auditing Business Process Compliance(Aditya Ghose and George Koliadis)

Check Proximity

An Example - Check Proximity

An Example - Check Proximity Edge Distance:6 Reject Order-->Merge (SequenceEdge) Ship Order-->Merge (SequenceEdge) Merge-->Close Order (SequenceEdge) Accepted or Rejected-->Reject Order (SequenceEdge) Accepted or Rejected-->Inform Customer Order Rejected (SequenceEdge) Ship Order-->Close Order (SequenceEdge)

Node Distance:3 Reject Order (Task) Merge (GatewayParallel) Inform Customer Order Rejected (EventEndMessage)

Effect Distance:1 Inform Customer Order Rejected (EventEndMessage)

Metric Distance:1.9