Format for a systems map
A systems map is essentially a snapshot. It shows components
of the system and environment at a point in time. Unless some components are
grouped into sub-systems and/or there are significant overlaps, a map conveys
no more information than a list of components. But it carries much more impact,
and is easier to grasp.
The main uses of systems maps are to help you to decide how
you are going to structure a situation and to communicate to others just what
system you have chosen to study. In particular, systems maps are used to:
- clarify thoughts at an early stage of analysis;
- decide upon structural elements for a more detailed
- experiment with trial boundaries;
- decide upon the level of your system of interest
- communicate to others the basic structure of the
system you are describing.
- blobs of varying sizes;
linking lines, arrows etc. are not permitted elements.)
blob lines in the figure above represent boundaries of system components.
(e.g. aaa, bbb, ccc, ddd, etc.) are used to name each system or component.
(5 and 6) outside the main system boundary (1) represent components of the
(2, 3 and 4) inside the system boundary represent components of the system.
Components (e.g. 3) can be shown as grouped into sub-systems (2).
Undifferentiated components may themselves be sub-systems.
may overlap only if some components (which need not be depicted) are
seen as common to both in the early stages of identifying a system of interest.
title defining the system of interest is essential.
should be clear which is ‘the’ system boundary. The system boundary can be
emphasized by colour, or by a thicker line. A dashed line can be used to
emphasize that the boundary is subjective and tentative.
blobs are normally preferable to regular boxes. Boxes imply that (sub-)systems
are clearly defined, which is seldom the case, and have the practical disadvantage
that the eye finds it hard to distinguish between a series of parallel lines.
overlaps sparingly. They reduce the impact and clarity of the map when trying
to establish a system of interest. Overlap only when the sharing of components
is important from your particular viewpoint or when you are still uncertain as
to where a component should lie. This applies equally to components within and
spanning the boundary. Multiple overlaps should be avoided at all costs as this
goes against the aim of clearly identifying a system of interest.
for consistency between components. For example, avoid representing system
properties as elements.
the size of blob used is not determined by size, importance, or other
characteristics of the component that it represents, it makes sense to show
important sub-systems at a reasonable size and less important ones somewhat
smaller, as this is the way relative size is likely to be interpreted by a
although there are no firm rules on positioning of components (other than
nesting and overlapping) it makes sense to put important components in a fairly
central position and to place related components close together. This will
facilitate subsequent additions of sub-system boundaries.
- It is
a good idea to leave some space within your map. Not only does this allow
components to stand out clearly, but it leaves room for any components you may
wish to add later.
within a blob (6) is to be avoided unless fff and ggg contain all possible
members of hhh and this fact is important. Normally blobs within blobs are
preferable to partitions.