Owner-Led Business Process Methodology

White paper prepared by Codel Services Ltd ©

Introduction

Objectives

This paper gives an overview of an ownership-led approach to business modelling, and explains when it should be used, how it contrasts and complements other methodologies.

It also briefly covers how to approach some of the key deliverables of the methodology.

Detailed descriptions of how to produce key deliverables, as well as templates that can be used can be supplied on request.

What does owner-led mean?

A key pitfall in business process reengineering (BPR) or in business change is that parties, on whom the BPR exercise impacts, do not act on its recommendations.

Common reasons for this are:

	“We were not informed that we were to be involved”
	“This is the first we heard of this”
	“We were not involved in these decisions”
	“We knew there was some change, but we don’t have time to implement this now”
	“We didn’t realise the scope of this was such”
	“This isn’t anything to do with us”
	“The impact of this is tool large, we couldn’t possibly implement this”

Common to all of these is a lack of understanding of what the process means to senior stakeholders in the areas affected. It is thus vital that ownership is accepted at an appropriate detail at the earliest stages of a BPR project. This is the objective of an owner-led project.

Process Overview

The stages of the project can fall into the following phases:

	Define the end to end process
	Agree process owners
	Perform detailed process design
	Deliver user manuals and procedures

The purpose of this paper is not to impose a bureaucratic process onto an organisation. Most organisations have some project lifecycle standards, and it is assumed that the owner-led process can work along-side that.

For example, the Rational Unified Process (“RUP”) is a common methodology for managing iterative projects. The above activity and deliverables can easily form part of the RUP project stages as shown in the following figure.

Figure 1: end-to-end process using RUP

Relationship to IT

BPR can be a standalone “pure business” reengineering exercise, but usually it forms part of a wider programme of change – including IT. In such case it should combined with, and complementing any programme of system or architecture change/rationalisation.

To ensure this cross-compatibility the business stream should go side by side (and feed into) architecture stream. As per RUP guidelines it should go slightly before, as business change has a longer lead time and can be in itself the major source of system requirements.

However the business stream cannot be completed until architecture is defined and agreed, so initially it should be treated solution neutral (unless the solution forms an inseparable part of the business expectations).

Once the architecture is agreed, the business stream must be re-evaluated, and any prior assumptions reviewed to see if need change is required. Certainly by the time the BPR stream gets to user manuals or procedure delivery there needs to be a stable view of technology.

Figure 2: Business vs. IT Streams

Of course this dialogue must continue throughout lifecycle as cost of change (both to business and IT) increases into the later stages.

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com