Parts of template
This section gives an overview to the parts of the
deliverable, and gives guidance as to how to complete it. It is important
that each part of the process design complements and references each of
the others.
The template that drives this deliverable is
essentially broken into three sections:
 |
Context: Gives background to what and who
plays a role in the stage of the process being considered. Includes a
range of models to help define this scope. |
|
Scenarios: The main part of the document –
gives the impacted participants instruction as to the best (and most
controlled) way to fulfil their responsibilities. |
|
Supplementary specification: Descriptions of
all terms (such as reports) referenced by the above scenarios |
Describing the Context
As well as establishing the goals and purposes of the
(sub)process in more detail, this section summarises the:
|
key ways things are performed in the (sub)process,
|
|
different ways in which they are performed, and |
|
range of roles required to both perform and support
them, and |
|
responsibilities to service them. |
It is important that the summary section is described
in a manner that allows a third party to read and understand them (at
least to the degree of assessing the relevance of the sub-process to
them).
What are the goals?
There should be a brief (entirely work based)
description of the process. The focus on this section are its main outputs
are and why.
What are scenarios?
The
main aim of (sub)process design is to describe in detail, how to produce a
set of deliverables in the most effective manner.
There is typically not one “correct” path in which to
produce these deliverables, as there could be differences in the steps to
cover situation where exceptions occur and differences in how to react to
information from different source systems.
Trying to embed this complexity into a single
“script” would result in something that looks like a computer program –
clearly something that would fail the requirements to be clear and
concise!
Instead of doing this in one hit, a number of
scenarios are defined for each sub-process, each describing a specific and
stated case.
How many scenarios do you need to describe?
Each sub-process will have a number of business
scenarios to describe it. At minimum there will always be two, but
typically there will be more:
| One for each output where the steps to produce the output are
different (if several outputs are produced by the same set of steps then
it is fine to have just one scenario). |
| One for each divergence as to how the outputs are produced depending
on the input, pre-conditions or some other external factor. |
| One for each exception where the steps to produce the exception is
different. If no exceptions are possible, still have scenario, but put
N/A or something like that. |
Remember, this is process design so it is fine to
have pedantic detail. If the steps are only slightly different (perhaps on
different data, or the same processing but with a different responsible
user role) then this still warrants more than one scenario.
Why, if there is significant divergence between the
steps, keep them in the same (sub)process document? Consider that if these
scenarios share the same goals, have the same (or similar) intermediary
and end-deliverables, same (or similar) control points then keeping them
in one document keeps repetition to a minimum, and promotes process
conformity.
Summarising scenarios
Given that there will be a number of scenarios, it is
important to give the reader a summary explanation of what these different
scenarios do, so as to help him/her navigate through the document.
This summary should cover for each scenario in the
sub-process:
|
The goals of each scenario |
|
Key differences between them (such as different
steps, deliverables or actors) |
|
Key similarities/commonalities and how they relate
to one another. |
Responsibility summary
If the scenario summary is seen as giving an overview
of what is done, responsibility addresses the question of by whom.
Whilst the different areas of responsibility can be
inferred from the scenarios themselves, it is useful to summarise all the
different areas of responsibilities in one place. Whilst this does mean
that this same information is described twice in the document, there is a
different emphasis: the scenario’s purpose is to describe things in a
dynamic manner (it is after all a process description) whereas this
responsibility summary can be considered a “static snapshot” of all the
things the users will be expected to do broken down by user role.
Parties reviewing the document for business impact or
to asses audit issues can thus see this information in one place, without
having to search through the scenarios.
Thus, what the template covers is:
|
User
role |
|
Relevance to Process: This can be either external
or participant. See following section on description of
actors and participants in use cases as to what this means. |
|
Designated contact |
|
Summary of each responsibility, broken down by
source system differences (if applicable) |
|
Core deliverables |
Document dependency
Given that process design involves re-engineering,
business and architectural change, then it is important to describe any
dependency on which any new part of the process is based on. In addition,
if there are assumptions based on future changes in underlying technology
(e.g. decommissioning of a specific system), these must also be
considered.
For both such cases acceptance of the document is
wholly dependent on the dependency being accepted by the process owner.
Therefore these document dependencies must be described in the process
design document, and should cover:
|
New area in question |
|
Dependent on what |
|
Area of document impacted |
For example: If a new report is introduced as part of
the process design documents, it may be dependent on its acceptance by the
business or delivery by third-party.
By emphasising such assertions, the document can be
easily modified should they change over time, or the document’s signoff
can be made conditional upon them.
© 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: info@codel-services.com
