A Model for Process Transformation

Chris Lawrence

Business Architecture Consultant

Old Mutual South Africa

Session Title:

A Model for Process and Transformation

Welcome to Transformation and Innovation 2007 The Business Transformation Conference Welcome

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

Draft BPM reference model

Logical analysis of the business process

Advantages:

Same model can support:

Technology

Process management

Transformation

Analogy:

Relational data model

WHAT versus HOW

Analogy:

Logical data model v physical data design

Process rules even if no systems were used Process features relating to a specific implementation

Process analysis, process modelling, process mapping, process design, process improvement... Operational procedure design around given system components ‘ Process’ = linking components together (procedurally or automatically or both) This is HOW not WHAT

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

Administration

Content & rules can be treated abstractly

Essence survives translation into different formats (brain, paper, digital…)

Eg life insurance policy:

legal contract between a financial organization and another person or organization, in relation to one 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 the process of making an armchair

Administration

Concrete object

Cannot be translated into another form and stay an armchair

Life insurance policy

Abstract entity

Can be translated into another form

Only has to exist as hard copy if rules say so

Process Process Input(s) Input(s) Output(s) Familiar model

Process Order process Input(s) Received goods Business process Customer order

Process Addition process 2 3 5 Calculation process

Process Photosynthesis Water Carbon dioxide Sunlight Glucose Oxygen Natural process

Process

This model is generic

Nothing special about business process

Process Input(s) Input(s) Output(s)

Process Process 1 Input 1 Output 1

Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 =

Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 Input 4 Process 3 Output 4 =

Process Process 1 Input 1 Output 1 Input 2 Process 2 Input 3 Output 2 Output 3 Input 4 Process 3 Output 4

Process Input 1 Input 3 Process 4 (1+2+3) Output 4 Output 3

Process

This model is also indefinite

Where does the process start and stop?

For a business process we need something more precise

Process Input(s) Input(s) Output(s)

Business process

For a business process we need to identify:

A particular kind of input

A particular kind of output

Request is for the outcome Outcome = thing requested Request = entity changing business status through the process Outcome = last business status change BPMN symbol for ‘data object’ BPMN symbol for ‘process’ or ‘process component’

Business process Unambiguous start point Unambiguous end point At individual instance level Paradigm case: request is from a customer (external or internal) Paradigm case: outcome is for that customer Achieving the requested outcome will involve following rules ‘ Process’ is not arbitrary : starts with the request & = everything which must be done to achieve the requested outcome

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; …

But just like the requested outcome, any alternative outcome will also be correct in terms of the rules of the process

Business process Business process Order process Input(s) Received goods Customer order

Subprocess

A business process can normally be broken down into a finite series of subprocesses …

Subprocess 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 happen whatever 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 not system constraints. 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 customer’s credit rating .

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

In this example order process:

‘ Check credit rating’ = transition from ‘awaiting Check credit rating’ to ‘awaiting Match against stock’

Where are we?

So far:

Business process

Request

Outcome

Subprocess

Next:

Business rule

Task

Business rule Rules about what subprocesses Rules about sequence of subprocesses 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.

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

x ...which takes us to the concept of task

Task 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.

Task Check each order against business rules But what about invalid orders?  x OK Not OK Valid orders can pass to the next subprocess

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 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

Task 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

Task

Apply the concept of a

Business rule

to the

Routing

needed to achieve the work of a

Subprocess

and you get the concept of a

Task

Flow at subprocess level:

From logical sequencing of process rules

Ignores variety of individual cases

Flow at task level:

From logic & logistics of applying process rules to variety of individual cases

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

Process model Business (area) Process 1 Process 2 Process 3

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

… etc +

Transformation AS IS TO BE

Transformation

Both are HOW not WHAT :

TO BE AS IS AS IS TO BE At physical level: HOW Current solution, using current systems, people, partners etc At physical level: HOW Proposed solution, using proposed systems, people, partners etc

Transformation

Need a stepping stone :

AS IS TO BE Logical model

Transformation

Logical model

= step between TO BE and AS IS

Implicit or explicit

= AS IS with all contingent constraints removed

(Abstract away everything that could be otherwise)

Logical model can only be realised in physical terms

TO BE :

= best available/achievable implementation of logical model

Logical model BPM reference model = principles for developing a logical process model aligned with the logical data model = Process model + Data model To support: business analysis; system selection & design; transformation; change management; process management; ...etc