The Psychology of Quality and More

A Toolbook for Quality Improvement and Problem Solving (contents)

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 variations

<-- Previous | Next -->

How to do it

1. 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.
    
2. 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.
    
3. 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.

4. 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 maintained.
   • 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.
      
5. 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

6. 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 actions:

   1. 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.
   2. 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'.
   3. 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.
   4. 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.
   5. 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.
   6. 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.
   7. 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 necessary.
       
7. 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.

 




 

8. 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 is represented.

 

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.
 

9. 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 step 2.
• 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.
 

10. The final set of diagrams is then used for the purpose as described in step 2.

 

 

<-- Previous | Next -->