IDEF0: How to do it
The Quality Toolbook >
IDEF0 > How to do it
When to use it | How to understand it |
Example | How to do it | Practical
<-- Previous |
How to do it
- Identify the system or process to be described. Use a name
that clearly indicates what it is, possibly adding further description of what
is and what is not included.
- Identify the purpose or objectives of describing the
process. This will help to determine whether IDEF0 is an appropriate tool, and
will also help when making other decisions, for example whether to decompose the
system further at lower levels.
- Decide on the viewpoint from which the process is to be
described. For example, a sales manager might have a broader view of a sales
process than a sales person, as the sales manager includes the clerical
activities in the sales office as well as the customer-salesperson process.
The objectives from step 2 will help with this decision. For
example, if the objective is to improve the amount of direct sales, then the
viewpoint of the salesperson may be most appropriate.
- Identify the decomposition strategy to be used. This is
the set of rules to use when deciding how to break down activities into
sub-activities, and may depend on the type of system being described and the
objectives from step 2. Possible strategies include:
- Functional decomposition
breaks down activities according to what is done, rather than how
it is done, and is probably the most common strategy.
- Role decomposition
breaks down things according to who does what. It can be an easy and
useful starting point, but is likely to constrain improvements if it is
- Subsystems decomposition
divides systems first by major subsystem. This is useful when these subsystems
are largely independent of one another.
- Lifecycle decomposition
breaks down a system first by the phases of activity. Again, this is most
useful when these phases are clearly defined and relatively independent.
Before starting to draw diagrams, gather information about
the system. This may start with reading of existing documents or observing the
process in action, but the most useful activity is likely to be formal
interviews with selected people. This not only is the best source of
information, but it will also help to gain involvement and acceptance in any
later improvements. Use the following process for interviews:
- In the initial interview, aim
first to agree the purpose and viewpoint, then find sufficient details to be
able to draw the first two levels only (A-0 and A0).
- Before each interview, review
existing information and identify the scope of what is to be identified.
- In interviews, work to
acquire the most useful information, asking open questions, probing in key
areas and checking the validity of assumptions.
- First, find out what is
produced by and used within the process, including inputs, controls, outputs
and mechanisms. This can be helped by asking questions of the process,
starting with outputs (What is produced?) and work backwards (What is needed
to produce this?). This will result in a list of items (often called the data
list) that will form the arrows in the diagram.
- Next, use the data list to
identify the list of activities within the process, asking how items
are used or produced.
- Then explore how activities and data items relate to one another and how
they group together. This will result in a list something like Fig. 1.
Fig. 1. Sketch of data, activities and ICOM
- From the information gained in step 5, draw a set of
diagrams. Draw the A0 diagram first, as illustrated, then summarize this in the A-0
diagram, as illustrated.
When drawing a diagram, use the following sequence of
- Use the decomposition
strategy from step 4 to identify between three and six activities that will be
shown on the diagram (around four is often best). It can be useful to try
several different decompositions before settling on one.
- Sort these activities into
the order of dominance. The more dominant of a pair of activities is one which
has the greatest influence over the other. For example 'produce plan' has
higher dominance than 'build product'.
- Place the activity boxes on
the diagram, using the general layout strategy of putting most dominant
activity in the top left, with subsequent activities along the diagonal, such
that the least dominant activity ends up in the bottom right corner. When
positioning the activities, try to think ahead to where arrows will go. Put
the name of each activity in its box.
- Draw the arrows for each data
item, starting with inputs and outputs, then adding controls then mechanisms.
Combine and split lines to help simplify the diagram. When the lines are
drawn, write in the labels for each line, being careful that the label cannot
mistakenly be confused with another item. If a label is not clearly associated
with a single line, draw a short line between it and the line, as illustrated.
- Add parentheses ('tunnel'
marks) to the end of any line which will not be shown in its parent or child
diagram, as illustrated. Tunnel items that will not add useful information
elsewhere. It is common to tunnel mechanisms at higher levels, so they do not
appear on lower level diagrams.
- Identify the diagram with a
node name, title and C-number, as illustrated. It may also be useful to add other
data, such as the date and the status of the diagram (e.g. initial, draft,
final). Use a log, as illustrated, to ensure that all C-numbers are unique.
- Review the completed diagram
for correctness, consistency, completeness and clarity. Check it against the
purpose (step 2), viewpoint (step 3), decomposition strategy (step 4) and
available information (step 5). Revise and repeat the above steps as
- For each diagram, it is useful to write a Glossary page, as Fig. 2,
that further describes each data item, as illustrated. This can contain any text
that will help the understanding of individual items or the overall system,
although it should be kept brief, to avoid an 'information overload'.
Fig. 2. Glossary page
Identify each page of the glossary with a title the same as
its diagram, but with 'Gn' added to the node name, where 'n' is
the page number in the glossary, and '(Glossary)' appended to the title. Use a
unique C-number, adding each page to the C-number log.
Note that ICOM items from the parent diagram are not included
in the glossary, as this would result in duplicate glossary entries and
consequent synchronization problems.
- Decide whether to review the pages produced so far. It is
useful to review early, when the A-0 and A0 diagrams (and possibly the level
below) are completed, and subsequently when significant changes have been made.
If you do hold a review until all pages are completed, then this can result in
significant extra effort being spent in rework.
When holding a review, first create a kit, consisting
of all pages requiring review, together with a cover page, and send it to
appropriate contributing experts for review. The cover page details the reviewer
list, the contents of the kit and what is expected of the reviewers, including
when to return it and any other special instructions.
The reviewers read the pages in the kit and write
corrections, in red directly on the pages of the kit, before returning it to the
author. Specific items to review include:
- The detail of each diagram,
including the title and node name, all activities and arrows, additional
glossaries and other material.
- The overall system, and how
the diagrams fit together, including use of the stated breakdown strategy.
- How well the stated viewpoint
The author then examines the reviewer's corrections and
writes comments in blue ink (thus differentiating from the reviewer's
corrections). Agreement with reviewer corrections are shown with ticks and other
comments are written alongside.
The author and each reviewer then meet and discuss the
comments and corrections. They agree to actual changes which the author then
implements. Make sure that when an item is changed, all other diagrams affected
by the change are also updated.
For each box which has not yet been decomposed, decide
whether it is worth taking this step, or whether sufficient detail exists at
this point. Considerations of whether to stop decomposition include:
- The final set of diagrams (or
'model') should contain sufficient detail to satisfy the stated purpose from
- A good point to stop is when
boxes start saying 'how' instead of 'what', or where the viewpoint changes.
- Boxes should describe
activities that are solid and unique functions, not trivial items nor
duplicates of other boxes.
For boxes that are to be decomposed further, the above
process of interview, create and review is repeated as required. Generally, the
process experts should be fully involved, but they should not be worn down with
too many interviews and reviews, as this is likely to cause them to become
annoyed and disinterested, with consequent damage to the model and its use.
The final set of diagrams is then used for the purpose as
described in step 2.
<-- Previous |