Use of models
Given that a process design document is written for
each key stage of a process (usually at a sub-process level), which are
themselves fine grained deliverables, it is important to give the reviewer
an appreciation of where the document fits into the big-picture.
Models are an effective tool for setting this context
in different ways. The Unified Modelling Language (UML) is an
industry standard modelling language. To enhance the understanding and
re-use of such models, this technique will be used where possible in the
following three areas.
Organisation view: Highlights the roles that
will be interfacing (or impacted by) this sub-process. Responsibility
will be further detailed in the document.
Dynamic view: Shows where the sub-process
fits in, what led up to it, and what follows on from it.
Static view: Summarises the key concepts that
are material to the sub-process, such as information, documents and
reports; and how they relate to one another
For all the above models it is important that they
are present only to enhance the user understanding of the sub-process and
to give assurance that the sub-process is complete and accurate. They are
not for system design purposes, so the level of detail must be kept
at appropriate levels. The temptation to spend large amounts of time
over-engineering the models must be similarly resisted.
The following three sections describe models to
support the above three views.
Use case model
The UML Use Case model is an effective way of
describing the context of the sub-process to the roles within the
A use case states different ways (or cases) in which
the systems within the sub-process are to be used by those outside it (the
This differentiation of what is in scope and what is
out of scope, and to whom our dependencies are with is a key benefit of
using use cases.
The components of the use case are shown below:
Characterising the use case
This is not a functional breakdown: only key areas
that result in some perceived goal by the actors need be considered. Since
this is a similar concept to the scenarios described earlier, the
scenarios can be used as a starting point, however it is permissible to
combine any of these for clarity.
Note also, that as the process design document is not
an architectural document do not model different component systems within
the framework. Instead treat the system as one entity.
The use case model is primarily sourced (and should
not contradict) the goals section of the process and owner document.
Actors vs. process participants
It is important to distinguish the difference between
actors (as shown as the stick men above) and participants of a business
Actors: these are any party (system or human)
external to the (sub)process being described by the process design
document. The sub-process has therefore a dependency to and from these
parties. External agencies are a good example of such an occurrence:
whilst they interface with the sub-process they are not directly
involved in the actual execution, and contractually we cannot tell them
how to produce the things we need
Participants: these, on the other hand are
“part-and-parcel” of how the sub-process is executed. We can (and must)
define how they should perform their actions. In the above model
business users such as finance are not shown as they are included
“inside” the sub-process so are not considered an actor!
Note that both types will require definition in
the responsibility summary section.
Will all process and owner documents require a process design
Process owner documents are concerned with the what,
and in particular, agreeing ownership of any dependencies. So it is
entirely proper to get actors (remember these are parties external to the
sub-process) to sign-off on what we expect them to do.
However it is not appropriate to tell such external
parties how to they fulfil their deliverables (i.e. our process’s
dependencies). The external parties process can be as efficient of
inefficient as they desire – as long as they meet their agreed SLA’s that
is our only concern. Thus, it is only the participants that we have the
authority to say how things will be done, will be subject to process
Another area where there may not be a prcess design
document is concerning technical automation. Since some sub-processes are
fully automated you may find there are cases where a process owner
document does not require a process design document.
The UML activity model with swimlanes is an effective
way of describing handovers, interaction and the relationships of the
current sub-process to other sub-processes.
Depending on the relevance of SOX to you process,
guidelines suggest a 2x2 swimlanes approach, with one direction describing
the roles supporting the activity, the other handovers (input and output)
together with a number of relevant “significant areas” it belongs to.
These significant areas are useful from an audit perspective and include:
Note that only the relevant significant areas need be
shown. E.g. If there is no authorisation taking place in this sub-process,
then no authorisation column is needed.
The activity model is primarily sourced (and should
not contradict) the inputs/outputs section of the process and owner
document, as well as summarising the detail from the scenario steps
An example of this approach is shown below:
Do not try and model all
the intricacies of the sub-process, such as conditionality and branching –
as this may only confuse, and are an unnecessary detail for this
deliverable. Just describe the key activity steps (at a suitable high
level) and a basic indication as to their sequence.
Business Domain model
The purpose of this model is to give the reviewer a
static “snapshot” of what is relevant to the sub-process. Whilst the UML
class model is the basis of this model it is not being used for detailed
modelling or design.
Its purpose is not to model all tables and attributes
as in an Entity Relationship Model (ERM) rather just to highlight the
business significant “artefacts”, such as:
Business Information (only describe data in tables
at a conceptual level)
These models are very useful for highlighting any
re-engineered aspects to a business process. For example, if a new element
of a business process would be to formalise rules in which to apply
tolerances to exceptions (as opposed to purely a judgement call), this
could be emphasised by showing it as a new concept as shown in the example
The domain model is primarily sourced (and should not
contradict) from the scenario steps themselves. It can be considered a
“visual glossary” of all the things the users will encounter in completing
© 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: email@example.com