A Model For Process and Transformation

Welcome
to Transformation and Innovation 2007

The Business Transformation Conference
Chris Lawrence Business Architecture Consultant Old Mutual South Africa Session Title: A Model for Process and Transformation
May 22-24, 2007 Washington Dulles Hilton
A Model for Process and Transformation

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
A Model for Process and Transformation

Draft BPM reference model Logical analysis of the business process Advantages:
Same model can support:
Technology Process management Transformation
Analogy:
Relational data model
3
WHAT versus HOW

Process rules even if no systems were used Process features relating to a specific implementation
Analogy:
Logical data model v physical data design
Process analysis, process modelling, process mapping, process design, process improvement...
Process = linking components together (procedurally or automatically or both)
Paper or fax SYSX Validate request Receive switch request Medium? SYSX Enter request WF Route for checking WF Check request Switch to cash
Web
Operational procedure design around given system components
WF Validate scheme member, populate queue and move to MSC
SYSX Check request
This is HOW not WHAT

5
Draft BPM reference model

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
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
7
Administration
Content & rules can be treated abstractly Essence survives translation into different formats (brain, paper, digital) Eg life insurance policy:
Almost everything about it and its creation can be treated abstractly - in a translatable (eg digitizable) way
legal contract between a financial organization and another person or organization, in relation to one or more human lives
Cannot say the same about the process of making an armchair
Administration
Life insurance policy
Abstract entity
Can be translated into another form Only has to exist as hard copy if rules say so
Concrete object
Cannot be translated into another form and stay an armchair
Process
Familiar model
Input(s)
Process
Input(s) Output(s)
10
Process
Business process
Customer order
Order process
Received Input(s) goods
11
Process
Calculation process
2
Addition process
12
Process
Natural process
Carbon dioxide Glucose Water Photosynthesis Oxygen Sunlight
13
Process
This model is generic
Nothing special about business process
Input(s)
Process
Input(s) Output(s)
14
Process
Input 1 Process 1 Output 1
15
Process
Input 1 Process 1 Output 1
=Input 2
Input 3
Process 2
Output 2
Output 3
16
Process
Input 1 Process 1 Output 1 Input 2 Input 3
Process 2
Process 3 Output 2 Output 4 Input 4 Output 3
17
Process
Input 1 Process 1 Output 1 Input 2 Input 3
Process 2
Process 3 Output 2 Output 4 Input 4 Output 3
18
Process
Input 1 Input 3
Process 4 (1+2+3)
Output 3 Output 4
19
Process
This model is also indefinite
Where does the process start and stop?
Input(s)
Process
Input(s) Output(s)
For a business process we need something more precise

20
Business process
For a business process we need to identify:
A particular kind of input A particular kind of output
BPMN symbol for process or process component
Request Input(s)
Process
Outcome Output(s)
BPMN symbol for Request is for the outcome data object Outcome = thing requested Request = entity changing business status through the process Outcome = last business status change
21
Business process
Unambiguous start point At individual instance level
Process is not arbitrary: starts with the request & = everything which must be done to achieve the requested outcome
Unambiguous end point
Request
Process
Outcome
Paradigm case: request is from a customer (external or internal)
Achieving the requested outcome will involve following rules
Paradigm case: outcome is for that customer

22
Business process
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;
Request
Process Process
Requested Outcome outcome
But just like the requested outcome, any alternative outcome will also be correct in terms of the rules of the process
Alternative outcome(s)
23
Business process
Business process
Customer Order order
Order Order process process
Received Input(s) Despatch goods
advice
24
Subprocess
A business process can normally be broken down into a finite series of subprocesses
Order process
Start
Request
Request Take Check 1 order order + + +
Match Subprocess Subprocess Check Subprocess Process Outcome Authorise Despatch Outcome Stop credit 2 against 3 order order rating + stock + ++ + + +
25
Subprocess
Boundaries often = handoffs/breakpoints needing internal/external interaction, eg input or authorisation. Boundaries set by business not system constraints.
Subprocess 1, subprocess 2 etc can be described in purely business terms, eg authorise order, match against stock. Subprocesses would need to happen whatever system was used, or whether a system was used at all. Fixed pattern: sequential; parallel
Request
Subprocess 1 +
Subprocess 2 +
Subprocess 3 +
Outcome
Boundaries often correspond to bottlenecks, eg x 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.
26
Subprocess
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
Order process
Start Take order + Check order + Check credit rating + Match against stock + Authorise order + Despatch order + Stop
In this example order process:

Check credit rating = transition from awaiting Check credit rating to awaiting Match against stock
27
Where are we?

So far:
Business process
Request Outcome
Subprocess
Next:
Business rule Task
28
Business rule
Rules about what subprocesses Rules about sequence of subprocesses
Order process
Subprocess Check order: Rules about what happens inside a subprocess All orders must be for a known customer Items must be identifiable as goods the business trades in Quantities must be specified etc.
29
Business rule
NOT:
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
...which takes us to the concept of
task
30
Task
Order process
Subprocess Check order: Rules about what happens inside a subprocess All orders must be for a known customer Items must be identifiable as goods the business trades in Quantities must be specified etc.
31
Task
Check each order against business rules
Take order
Check order
Check credit rating
Match against stock
Authorise order
Despatch order
+
Not OK
+
OK
x
But what about invalid orders?
Valid orders can pass to the next subprocess
32
Task
All the work of the subprocess is contained within the tasks. Subprocess = container for the tasks.
All orders go through the automatic check task, which runs business rules Some orders (perfect ones) only need to go through the automatic task
Check order Take order + Automatic check Manual correct errors

Others (imperfect ones) are routed by the automatic task to the manual task The manual task then routes them back to the automatic task for rechecking
Check credit rating +
Match against stock +
Authorise order +
Despatch order +
Manual task to correct the errors

33
Check credit rating Take order Check order Automatic credit check Match against stock Authorise order Despatch order
Task
+
+
pass 1 or 2 meets criteria of 3, 4 or 5
approved (rule 3)
Manual credit check
Example of a more complex task structure for subprocess: Check credit rating
But the principle is the same: tasks & routing derived from applying rules to possible orders
Automatic follow up
written to customer (rule 4 or 5)
Manual record reply
34
Task
Apply the concept of a
Business rule
to the
Routing
needed to achieve the work of a
Flow at subprocess level: - From logical sequencing of process rules - Ignores variety of individual cases
Subprocess
and you get the concept of a
Task
Flow at task level: - From logic & logistics of applying process rules to variety of individual cases
35
Draft BPM reference model

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

36
Process model
Process 1
Subprocess 1.1 M
Business (area)
Model can also show how processes interact with each other: One may initiate another One may terminate another One may determine outcome of another etc
Process 2
Subprocess 2.1
Process 3
Subprocess 3.1
etc
+
Subprocess 2.2
+
Subprocess 3.2
Subprocess 1.2
+
Subprocess 2.3
+
M
Subprocess 3.3
Subprocess 3.4
+
A Subprocess 1.3
Subprocess 2.4
+
Subprocess 3.5
37
Transformation
AS IS
TO BE
38

A Model For Process and Transformation - Maj 2007

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Model For Process and Transformation - Maj 2007

Hochgeladen von

Copyright:

Verfügbare Formate

Welcome

to Transformation and Innovation 2007

The Business Transformation Conference

May 22-24, 2007 Washington Dulles Hilton

The Business Transformation Conference

May 22-24, 2007 Washington Dulles Hilton