Business process measurement

(1)

Business process

measurement - data

mining

.

(2)

• Balanced scorecard

(3)

(4)

(5)

 Clear & measurable goals  Effective solutions

 Measurable results

Goal-oriented development of organization’s IS

(6)

ROCE Customer Loyalty On-time Delivery Process Quality Process Cycle Time Employees Financial Customer Business Process Learning and Growth Systems

(7)

Financial perspective : goals and measures

Customer perspective : goals and measures

Process perspective :goals and measures

Learning and growth perspective : goals and measures

Mission and vision of organization

•Strategic goals

•Main tasks

(8)

(9)

(10)

(11)

(12)

Example Balanced Scorecard: Regional Airline

Mission: Dedication to the highest quality of Customer Service delivered with a sense of warmth, friendliness, individual pride, and Company Spirit.

Vision: Continue building on our unique position -- the only short haul, low-fare, high-frequency, point-to-point carrier in America.

(13)

(14)

W

L

Y

A

Chapter 17 Process Mining and Simulation

Moe Wynn Anne Rozinat Wil van der Aalst Arthur ter Hofstede

(15)

Overview

• Introduction • Preliminaries

• Process mining (with ProM)

• Process simulation for operational decision support • Tools: YAWL, ProM & CPN Tools

(16)

Y

YYYY

Introduction

• Correctness, effectiveness and efficiency of business processes are vital to an organization

• Significant gap between what is prescribed and what actually happens

• Process owners have limited info about what is actually happening

• Model-based (static) analysis – Validation

– Verification (correctness of a model)

– Performance analysis

• Process Mining – post-execution analysis • Process Simulation – „what-if‟ analysis

(17)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₁₇

Y

YYYY

(18)

Y

YYYY

Preliminaries: Data Logging

• Keeping track of execution data – Activities that have been carried out

– Timestamps (Start and end times of activities)

– Resources involved – Data • Purposes – Audit trails – Disaster recovery – Monitoring – Data Mining – Process Mining – Process Simulation

(19)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₁₉

Y

YYYY

Preliminaries: Process Mining

• Event logs (recorded actual behaviors) • Covers a wide-range of techniques • Provide insights into

– control flow dependencies

– data usage

– resource involvement

– performance related statistics etc.

• Identify problems that cannot be identified by inspecting a static model alone

(20)

Y

YYYY

Preliminaries: Process Simulation

• Develop a simulation model at design time

• Carry out experiments under different assumptions • Used for process reengineering decisions

• Data input is time-consuming and error-prone • Requires careful interpretation

– Abstraction of the actual behavior

– Different assumptions made

– Inaccurate or Incomplete data input

(21)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₂₁

Y

YYYY

(22)

Y

YYYY

Process Mining

• Process discovery: "What is really happening?"

• Conformance checking: "Do we do what was agreed

upon?"

• Performance analysis:

"Where are the bottlenecks?" • Process prediction: "Will this

case be late?"

• Process improvement: "How to redesign this process?" • Etc.

(23)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₂₃

Y

YYYY

Example: mining student data

• Process discovery: "What is the real curriculum?"

• Conformance checking: "Do students meet the prerequisites?"

• Performance analysis: "Where are the bottlenecks?"

• Process prediction: "Will a student complete his studies (in time)?"

(24)

Y YYYY software system process/ system model event logs models analyzes discovery records events, e.g., messages, transactions, etc. specifies configures implements analyzes supports/ controls conformance “world” people machines organizations components business processes

(25)

Where to start?

process

design

implementation/

configuration

process

enactment

diagnosis

process

control

process mining

(26)

Y

YYYY

(27)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₂₇

Y

YYYY

ProM framework

• One of the leading approaches to Process Mining http://www.processmining.org/

• Covers a wide range of analysis approaches • 250+ plug-ins

– Process Discovery

– Social Network

– Conformance Checking

• Conversion capabilities between different formalisms – Petri nets, EPCs, BPMN, BPEL, YAWL

(28)

Y

YYYY

(29)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₂₉

Y

YYYY

(30)

Y

YYYY

(31)

throughput

time

bottle-necks

flow time

from A to

B

(32)

Y

YYYY

Dotted chart analysis

time

(relative)

case

s

short

cases

long

cases

46138 events

(33)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₃₃

Y

YYYY

ProM and YAWL

• YAWL logs workflow events and data attributes

• An extractor function available as a ProMImport plug-in

• ProM can analyze YAWL logs in MXML format

• Prom can transform YAWL models into Petri nets

<Process id="Payment_subprocess.ywl"> <ProcessInstance id="3f9dfc70-5420-40e7-b9f7-329b5c6f0ded"> <AuditTrailEntry> <WorkflowModelElement>Check_PrePaid_Shipments_10</WorkflowModelElement> <EventType>start</EventType> <Timestamp>2008-07-08T10:11:18.104+01:00</Timestamp> <Originator>JohnsI</Originator> </AuditTrailEntry> <AuditTrailEntry> <Data><Attribute name="PrePaidShipment">true</Attribute></Data> <WorkflowModelElement>Check_PrePaid_Shipments_10</WorkflowModelElement> <EventType>complete</EventType> <Timestamp>2008-07-08T10:11:28.167+01:00</Timestamp> <Originator>JohnsI</Originator> </AuditTrailEntry> </ProcessInstance> </Process>

(34)

Y

YYYY

Starting point: event logs

YAWL logs or other event logs, audit trails, databases, message logs, etc.

unified event log (MXML)

(35)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₃₅

Y

YYYY

(36)

Y

YYYY

(37)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₃₇

Y

YYYY

Linking process mining to simulation

• Gather process statistics using process mining techniques

• Calibrate simulation experiments with this data

• Analyze simulation logs in the same way as execution logs

(38)

Y

YYYY

Data sources for process characteristics

• Design (Workflow and Organizational Models) – Control and data flow

– Organizational model

– Initial data values

– Role assignments

• Historical (Event logs)

– Data value range distributions

– Execution time distributions

– Case arrival rate

– Resource availability patterns

• State (Workflow system) – Progress state

– Data values for running cases

(39)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₃₉

Y

YYYY

(40)

Y

YYYY

Architecture II

• YAWL

– Create and execute process models

– Maintain organizational models

– Extractor functionalities for event logs, organizational models and current state of the workflow system

• ProM

– Translate and integrate all the components into a Petri nets model

– Analyze event logs and simulation logs

• CPN Tools

– Run simulation experiments

– Incorporate current state of workflows

(41)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₄₁

Y

YYYY

(42)

Y

(43)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₄₃

Y

YYYY

Tool: Architecture

•

Use existing models

(44)

Y

YYYY

Tool: Architecture II

•

Use existing models

•

Derive parameters

•

Use existing models

(45)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₄₅

Y

YYYY

Tool: Architecture III

•

Use existing models

•

Derive parameters

•

Consider current state

•

Use existing models

•

Derive parameters

(46)

Y

YYYY

Tool: Architecture IV

•

Use existing models

•

Derive parameters

•

Simulation logs in MXML

•

Use existing models

•

Derive parameters

•

(47)

Simulation: Example

Payment [Invoice required] [else] [pre-paid shipments]

payment for the shipment

c: Finance Officer

o: Account Manager

customer makes the payment

c: Senior Finance Officer

Start Issue Shipment

Invoice s: Supply Admin Officer Check Pre-paid shipments Issue Shipment Remittance Advice Issue Shipment Payment Order Approve Shipment Payment Order Update Shipment Payment Order Issue Credit Adjustment issue Debit Adjustment Finalise Produce Freight Invoice Check Invoice Requirement End Process Shipment Payment Complete Invoice Requirement

[payment incorrect due to overcharge]

[payment correct] [payment incorrect due to

underpayment]

account settled

payment for the freight

o: Account Manager o: Account Manager

c: Finance Officer

s: Supply Admin Officer

customer notified of the payment, customer makes the payment [s. order approved]

[s. order not approved]

Process Freight Payment

s: Supply Admin Officer o: Account Manager

(48)

Y

YYYY

Simulation: Example

• 13 staff members

– 5 `supply admin officers„

– 3 `finance officers'

– 2 `senior finance officers'

– 3 `account managers„

• Case arrival rate: 50 payments per week

• Throughput time: 5 working days on average

• 30% of shipments are pre-paid

• 50% of orders are approved first-time

• 20% of payments are underpaid

• 10% of payments are overpaid

• 70% of payments are correct

• 80% of orders require invoices

• 20% of orders do not require invoices

(49)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₄₉

Y

YYYY

Simulation: Scenario

• 4 weeks till the end of financial year

• A backlog of 30 payments (some for more than a week) • Goal: All payments to be processed in 4 weeks time

• Run simulation experiments to

– see if the backlog can be cleared using current resources

– evaluate the effect of avoiding underpayments

(50)

Y

YYYY

(51)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₅₁

Y

YYYY

(52)

Y

YYYY

Four Scenarios

1. An empty initial state ( „empty‟)

2. After loading the current state file with the 30 applications currently in the system („as is‟)

3. After loading the current state file but adding 13 extra resources („to be A‟)

4. After loading the current state file but changing the model so that underpayments are no longer possible („to be B')

(53)

a university for the real _world R _Y_Y_Y _A_A _W_W _L_L_L ₅₃

Y

YYYY

(54)

Y

YYYY

Simulation for operational decision support

• Combine the real process execution log (`up to now') and the simulation log (which simulates the future `from now on')

• Look at the process execution in a unified manner • Track both the history and the future of current cases

(55)

Alpha algorithm

(56)

Process log

• Minimal information

in log: case id‟s and

task id‟s.

• Additional

information: event

type, time,

resources, and

data.

• In this log there are

three possible

sequences:

case 1 : task A case 2 : task A case 3 : task A case 3 : task B case 1 : task B case 1 : task C case 2 : task C case 4 : task A case 2 : task B case 2 : task D case 5 : task E case 4 : task C case 1 : task D case 3 : task C case 3 : task D case 4 : task B case 5 : task F case 4 : task D

(57)

>,



,||,# relations

• Direct succession

:

x>y iff for some

case x is directly

followed by y.

• Causality

: x



y iff

x>y and not y>x.

• Parallel

: x||y iff x>y

and y>x

• Choice

: x#y iff not

x>y and not y>x.

case 1 : task A case 2 : task A case 3 : task A case 3 : task B case 1 : task B case 1 : task C case 2 : task C case 4 : task A case 2 : task B case 2 : task D case 5 : task E case 4 : task C case 1 : task D case 3 : task C case 3 : task D case 4 : task B case 5 : task F case 4 : task D A>B A>C B>C B>D C>B C> D E>F AB AC BD CD EF B||C C||B

(58)

Basic idea (1)

x

y

(59)

Basic idea (2)

x



y, x



z, and y||z

x

z

y

(60)

Basic idea (3)

x



y, x



z, and y#z

x

z

y

(61)

Basic idea (4)

x



z, y



z, and x||y

x

y

(62)

Basic idea (5)

x



z, y



z, and x#y

x

y

(63)

It is not that simple: Basic

alpha algorithm

Let W be a workflow log over T. a(W) is defined as follows. 1. T_W = { t  T | $_{s } _W t  s}, 2. T_I = { t  T | $_{s } _W t = first(s) }, 3. T_O = { t  T | $_{s } _W t = last(s) }, 4. X_W = { (A,B) | A  T_W  B  T_W  "_a__A"_b_ _B a _W b  "_a1,a2__A a₁#_W a₂  "_b1,b2_ _B b₁#_W b₂ }, 5. Y_W = { (A,B)  X | "_(A__,B_₎_ _XA  A B  B (A,B) = (A,B) }, 6. P_W = { p_(A,B) | (A,B)  Y_W } {i_W,o_W},

7. F_W = { (a,p_(A,B)) | (A,B)  Y_W  a  A }  { (p_(A,B),b) | (A,B)  Y_W  b

 B } { (i_W,t) | t  T_I} { (t,o_W) | t  T_O}, and

8. a(W) = (P_W,T_W,F_W).

(64)

Example

case 1 : task A case 2 : task A case 3 : task A case 3 : task B case 1 : task B case 1 : task C case 2 : task C case 4 : task A case 2 : task B case 2 : task D case 5 : task E case 4 : task C case 1 : task D case 3 : task C case 3 : task D case 4 : task B A B C D E F a(W) W

(65)

DEMO

Alpha algorithm

A E G invite reviewers D get review 2 time-out 2 collect reviews H decide I accept J reject invite additional reviewer K M L get review X time-out X C B get review 1 time-out 1 G F get review 3 time-out 3 48 cases 16 performers

(66)

Logging system

• Nlog

• NLog can process diagnostic messages

emitted from any .NET language (such as

C# or Visual Basic), augment them with

contextual information

(such as date/time,

severity, thread, process, environment

enviroment), format them according to

your preference and send them to one or

(67)

Supported targets

• Files - single file or multiple, with automatic file naming and archival

• Event Log - local or remote

• Database - store your logs in databases supported by .NET

• Network - using TCP, UDP, SOAP, MSMQ protocols • Command-line console - including color coding of

messages

• E-mail - you can receive emails whenever application errors occur

• ASP.NET trace

(68)

Y

YYYY

Conclusions

• Introduction

– Concise assessment of reality needed for processes

• Preliminaries

– Data logging, Process Mining, Process Simulation

• Process mining with ProM

– Understanding process characteristics

• Process simulation

– Operational decision support

– Utilizing log info for simulation experiments

• Tools: YAWL, ProM & CPN Tools – Payment example