a model for process and transformation_maj 2007

8/2/2019 A Model for Process and Transformation_maj 2007

1/38

1May 22-24, 2007Washington Dulles HiltonThe Business Transformation Conference

Chris Lawrence

Business Architecture Consultant

Old Mutual South Africa

Session Title:

A Model for Process and Transformation

WelcomeWelcometo Transformation and Innovation 2007The Business Transformation Conference


2/38



WfMC BPM and Workflow Handbook 2007

Paper:

Business Process Architecture and the Workflow

Reference Model

Argument: Derive BPM reference model not from workflow

or BPM technology, but from logical analysis of

the business process


3/38



Draft BPM reference model

Logical analysis of the business process

Advantages:

Same model can support:

Technology

Process management

Transformation

Analogy: Relational data model


4/38


WHAT versus HOW

Analogy:

Logical data model v physical data design

Processrules even if

no systemswere used

Process featuresrelating to a

specificimplementation


5/38


Process analysis, process modelling, process

mapping, process design, process improvement...

Receive

switchrequest Medium?

SYSX

Validate request

Paper

or fax

SYSX

Enter request

WF

Route for checking

WF

Check request

WF

Validate scheme

member, populatequeue and move

to MSC

SYSX

Check request

Switch tocash

Web

Operational procedure

design around given

system components

Process = linking components

together (procedurally or

automatically or both)

This is HOW not WHAT


6/38



Objectives:

Understand process as WHAT

To get best available HOW

Initial scope:

Administration: Processing orders & applications, granting approval,

carrying out instructions etc etc

Sales, financial services, central & local government,

education, travel, tourism etc etc etc


7/38


Administration

Service to end-customer

Implicit or explicit request

Rule-governed

Right and wrong ways

Standard v exceptions

Sequence; completeness

Increasingly supported by computer systems

People deal with exceptions and special cases

People make rules rather than follow them


8/38


Administration

Content & rules can be treated abstractly

Essence survives translation into differentformats (brain, paper, digital)

Eg life insurance policy:

legal contract between afinancial organization and

another person or

organization, in relation toone or more human lives

Almost everything about it

and its creation can be

treated abstractly - in a

translatable (eg

digitizable) way

Cannot say the

same about theprocess of making

an armchair


9/38


Administration

Concrete object

Cannot betranslated intoanother form and

stay an armchair

Life

insurance

policy

Abstract entity

Can be translatedinto another form

Only has to exist

as hard copy ifrules say so


10/38


Process

ProcessInput(s)

Input(s)Output(s)

Familiarmodel


11/38


Process

Orderprocess

Input(s)Receivedgoods

Businessprocess

Customerorder


12/38


Process

Additionprocess

2

3

5

Calculationprocess


13/38


Process

PhotosynthesisWater

Carbondioxide

Sunlight

Glucose

Oxygen

Naturalprocess


14/38


Process

ProcessInput(s)

Input(s)Output(s)

This model is generic

Nothing special about business process


15/38


ProcessProcess

1

Input

1

Output

1


16/38


ProcessProcess

1

Input

1

Output

1

Input

2

Process

2

Input

3

Output

2

Output

3

=


17/38


ProcessProcess

1

Input

1

Output

1

Input

2

Process

2

Input

3

Output

2

Output

3

Input

4

Process

3

Output

4

=


18/38


ProcessProcess

1

Input

1

Output

1

Input

2

Process

2

Input

3

Output

2

Output

3

Input

4

Process

3

Output

4


19/38


ProcessInput

1

Input

3

Process 4

(1+2+3)

Output

4

Output

3


20/38


Process

ProcessInput(s)

Input(s)Output(s)

This model is also indefinite

Where does the process start and stop?

For a business process we need something moreprecise


21/38


Business process

Process Output(s)Input(s)

ProcessRequest Outcome

For a business process we need to identify:

A particular kind ofinput A particular kind ofoutput

Request is for the outcomeOutcome = thing requested

Request = entity changing business status through the process

Outcome = last business status change

BPMN symbol for

data object

BPMN symbol forprocess or process

component


22/38


Business process

ProcessRequest Outcome

Unambiguous

start point Unambiguousend point

At individual

instance level

Paradigm case: request

is from a customer(external or internal)

Paradigm case:outcome is forthat customer

Achieving therequested outcome willinvolve following rules

Process is not arbitrary:

starts with the request & =

everything which must be done toachieve the requested outcome


23/38


Business process

ProcessRequest OutcomeProcessRequestRequested

outcome

Alternative

outcome(s)

The business process will involve following rules

Rules may or may not be satisfied

Requested outcome may not be achieved:

Eg ordered goods unavailable; loan application unsuccessful;

But just like the requested outcome,

any alternative outcome will also becorrect in terms of the rules of theprocess


24/38


Business processBusinessprocess

Order

process

Input(s)Received

goods

Customer

orderOrder Order process

+

Despatch

advice


25/38


Subprocess

A business process can normally be broken

down into a finite series ofsubprocesses

Request Process

+

Outcome OutcomeRequestSubprocess

1

+

Subprocess

2

+

Subprocess

3

+

Take

order

+

Check

credit

rating+

Match

against

stock+

Authorise

order

+

Despatch

order

+

Check

order

+

Order process

Start Stop


26/38


Subprocess

OutcomeRequestSubprocess

1

+

Subprocess

2

+

Subprocess

3

+

Fixed pattern:

sequential; parallel

Subprocess 1, subprocess 2 etc can be

described in purely business terms, eg

authorise order, match against stock.

Subprocesses would need to happenwhatever system was used, or whether a

system was used at all.Boundaries often = hand-

offs/breakpoints needing

internal/external interaction, eg

input or authorisation.

Boundaries set by business notsystem constraints.

Boundaries often correspond to

bottlenecks, egx cases

awaiting authorisation.

Subprocesses not arbitrary collections

of actions, nor events in terms of a

particular computer system:Eg not Run job C123 but Check

customers credit rating.


27/38


Subprocess

Take

order

+

Check

credit

rating+

Match

against

stock+

Authorise

order

+

Despatch

order

+

Check

order

+

Order process

Start Stop

A subprocess is not:

An arbitrary set of actions

A piece of functionality

A subprocess is:

A transition from one business status to the next

In this example order process:

Check credit rating = transition from awaiting Check credit rating

to awaiting Match against stock


28/38


Where are we?

So far:

Business process Request

Outcome

Subprocess

Next:

Business rule Task


29/38


Business rule

Take

order+

Check

credit

rating+

Match

against

stock+

Authorise

order+

Despatch

order+

Check

order+

Order process

Start Stop

Rules about what

subprocesses

Rules about

sequence of

subprocesses

Rules about whathappens inside a

subprocess

Subprocess Check order:

All orders must be for a known customer

Items must be identifiable as goods the

business trades in

Quantities must be specified

etc.


30/38


Business ruleNOT:

Process and subprocesses come first Then decide what the rules are

BUT:

Rules come first Definition of process = rule

Where process starts and stops

Analysis into subprocesses = rules

Some rules fit inside other rules, eg Rule that you have to achieve something

Rules about what to do to achieve it

x

...which takes us

to the concept of

task


31/38


Task

Take

order

+

Check

credit

rating+

Match

against

stock+

Authorise

order

+

Despatch

order

+

Check

order

+

Order process

Start Stop

Rules about what

happens inside a

subprocess

Subprocess Check order:

All orders must be for a known customer

Items must be identifiable as goods the

business trades in

Quantities must be specified

etc.


32/38


Task

Take order

+

Check credit

rating

+

Match against

stock

+

Authorise

order

+

Despatch

order

+

Check order

+

x

OKNot OK

Check each order

against business

rules

Valid orders can

pass to the nextsubprocess

But what about

invalid orders?


33/38


TaskAll the work of the subprocessis contained within the tasks.

Subprocess = container for

the tasks.

Check

credit

rating

+

Match

against

stock+

Authorise

order

+

Despatch

order

+

Check order

Automatic

check

Manual

correct

errors

Take

order

+

All orders go

through the

automatic check

task, which runsbusiness rules

Some orders (perfect ones)

only need to go through

the automatic task

Others (imperfect ones) are

routed by the automatic task

to the manual task

Manual task to

correct the errors

The manual task then routes

them back to the automatic

task for rechecking

Ch k dit ti


34/38


Match against

stock

+

Authorise

order

+

Despatch

order

+

Check credit rating

Automatic

credit check

Manual credit

check

Automatic

follow upManual

record reply

meets criteriaof 3, 4 or 5approved

(rule 3)

pass

1 or 2

written to customer(rule 4 or 5)

Check

order

+

Take order

+

Task

Example of a more

complex task structurefor subprocess: Check

credit rating

But the principle is the

same: tasks & routing

derived from applying

rules to possible orders


35/38


TaskApply the concept of a

Business ruleto the

Routing

needed to achieve the work of a

Subprocess

and you get the concept of a

Task

Flow at subprocess level:

- From logical sequencingof process rules

- Ignores variety ofindividual cases

Flow at task level:

- From logic & logistics of applying processrules to variety of individual cases


36/38



Process architecture approach:

Three levels A business consists of a finite set of processes

A process consists of a finite set of subprocesses

A subprocess consists of a finite set of tasks

Result = process model

Derived from

Business rules

applied to Business data entities


37/38


Process modelBusiness

(area)

Subprocess

1.2A

M

M

Subprocess

1.1

Subprocess 1.3

A

Subprocess

2.1+

Subprocess

2.2

+

Subprocess

2.3+

Subprocess2.4+

Subprocess

3.1

+

Subprocess

3.2

+

Subprocess

3.3

+

Subprocess

3.5

+

Subprocess

3.4

+

Process 1Process 2

Process 3etc

+

Model can also show how processes

interact with each other:

One may initiate another

One may terminate anotherOne may determine outcome of another

etc


38/38


Transformation

AS IS TO BE

a model for process and transformation_maj 2007

Documents