Owner-Led Business Process Methodology
White paper prepared by Codel
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
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:
not informed that we were to be involved”
the first we heard of this”
not involved in these decisions”
there was some change, but we don’t have time to implement this now”
didn’t realise the scope of this was such”
isn’t anything to do with us”
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.
The stages of the project can fall into the following phases:
the end to end process
detailed process design
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
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
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
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.
© 2002-2007 Codel Services Ltd
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: firstname.lastname@example.org