You are on page 1of 3

In this process map template, headings that should be retained are not surrounded by < ..

>, not in italic text and


are not contained in a comment box(such as this box).
Elements that are within <…> should be replaced by user defined or developed text
Elements in italic and marked, coloured comment boxes are for guidance and should be removed from the final
version.
Delete this box from the final version.

Process Map

Name <replace with name of process map without pm_ prefix>

Identifier <give the process map a unique identifier>

Change Log
<yyyy-mm-dd> <action> <author email address>

Exchange <include name of exchange requirement shown in this process map>


Requirements <all exchange requirements should be identified>
<…>
<…>

Overview
Provide a textual overview of the process map under the headings Scope and Description. This should be non
technical, written at a ‘business’ level and targeted to the ‘executive user’
Scope
<Define the scope of the process map>
Set down the scope of the process map. This will include answers to the following questions:
‘what’ subject if the process concerned with
‘when’ is it relevant in terms of the overall stages of the building
‘who is concerned with the process map.

General Description
<Provide a more detailed narrative >
This should give a broad, executive level overview of the purpose of the process map and provide any relevant
guidance that may help to explain the terms used.
Note that the overview may contain diagrams that help to explain particular points that are contained within the
process.
Specification of Processes
A process map may comprise several process maps. These could be a high level map followed by progressive
breakdown of the map into smaller units.
Each process map should be defined progressively

Process Map : <Name>


Each process map will have a name. If the map is a breakdown of a process at a higher level, the name of the
process map will be the same as the name of the higher level process.

<Insert the process map illustration >


A process map will also have a graphical version in the selected notation (typically expected to be the BPMN
notation). This should be inserted before the pool and lane descriptions

POOL : <Name>
Processes within a process map are organised into pools. The definition of the processes should be undertaken by
the various pools included.
LANE : <Name>
Processes within a pool are organised into lanes. Within the pool specification, the processes should be defined
according to the lane in which they are located.

<Process Name> [ID:<xx>]


Each process in a lane is named according to IDM naming conventions. If the software used supports specific
identification numbering for processes, this should be included following the name.

Type <type>
Indicate type of process (task type,
procedure type etc.)
Name <process name>
Repeat of the process name above
Documentation <insert description of the process>
Text narrative describing the process. May include diagrams.
<Coordination Point Gateway Name>
A coordination point gateway is the point at which information can be brought together for comparison and
decisions made regarding actions to be taken. Each coordination point gateway should be named according to its
function within the process map (there are no specific naming conventions applied for this purpose)

Type Gateway
Name < coordination point gateway name >
Repeat of the coordination point gateway name above
Documentation <insert description of the coordination point gateway>
Text narrative describing the gateway.

<Event Name>
An event is a notable occurrence that takes place at a point in time within the process. Each event should be named
according to its function within the process map (there are no specific naming conventions applied for this purpose)

Type Event
Name < event name >
Repeat of the event name above
Documentation <insert description of the event>
Text narrative describing the event.

<Reiteration Name>
A reiteration is a feedback process described within the process map. Generally shown as a sequence flow, it
implies a process within the feedback loop . Each reiteration should be named as a process

Type Reiteration
Name < reiteration name >
Repeat of the event name above
Documentation <insert description of the reiteration>
Text narrative describing the reiteration.

Specification of Data Objects


Data objects are considered to be either library objects providing information to the business process or exchange
requirements that transfer data between processes. Such objects are usually associated with message flows between
objects rather than being directly in a swim lane.

Library Data Objects


<Data Object Name>
Each data object is named according to IDM naming conventions.

Type Data Object


Name <data object name>
Repeat of the data object name above
Documentation <insert description of the data object>
Text narrative describing the data object. Should include a preliminary
specification of the data contained.

Exchange Requirement Data Objects


<Exchange Requirement Name>
Each exchange requirement data object is named according to IDM naming conventions and uses the prefix er_.

Type Data Object


Name <exchange requirement name>
Repeat of the exchange requirement name above
Documentation <insert description of the exchange requirement>
Text narrative describing the exchange requirement. Should include a preliminary
specification of the data contained.
The documentation of an exchange requirement within a process map can be
developed to a sufficient degree of detail that the narrative can be take directly into
the exchange requirement documentation

You might also like