How to understand Flowchart

In order to improve a process, it is first necessary to understand its operation in detail. Describing this in text lacks the clarity of a pictorial diagram, where individual steps are more easily seen.

The Flowchart is a simple mapping tool that shows the sequence of actions within a process, in a form that is easy to read and communicate.

The basic element of a process is a simple action, which can be anything from striking an anvil to making a cash payment, and is represented as a box containing a description of the action. The mapping of 'what follows what' is shown with arrows between sequential action boxes, as in the illustration. This also shows the boxes for process start and end points of which there are normally one each.

Fig. 1. Basic Flowchart elements

Processes become more complex when decisions must be made on which, out of an alternative set of actions, must be taken. The decision is shown in a Flowchart as a diamond-shaped box containing a simple question to which the answer is 'yes' or 'no' as in Fig. 2. More complex decisions are made up of combinations of simple decision boxes.

Fig. 2. Decisions in Flowcharts

Processes often go wrong around decisions, as either the wrong question is being asked or the wrong answer is being given.

Where boxes cannot be directly connected with lines, the separated lines are coordinated with connector boxes containing matching names. This typically occurs where lines cross onto another page, as in the illustration.

Fig. 3. Continuing Flowcharts across pages

By using multiple connector boxes, it is very easy for Flowcharts to become very large, although this is usually self-defeating, as the Flowchart then becomes difficult to understand. The ideal size for a Flowchart is one page, as this gives a single visual 'chunk' that is reasonably easy to understand as a single item.

Large processes can be broken down into a hierarchical set of smaller Flowcharts by representing a lower level process as a single sub-process box. This behaves like a normal action box at the higher level, but can be 'zoomed into' to expose another Flowchart, as in Fig. 4.

Fig. 4. Sub processes

An additional 'action' box that can be useful when analyzing processes is the wait box, which highlights a delay (i.e. no action), as in the illustration. This is a typical point where the overall cost of a process may be improved by acting, possibly on other processes, to reduce the delay.

Fig. 5. Delay symbol

When to use Flowchart

• Use it when analyzing or defining a process, to detail the actions and decisions within it.
• Use it when looking for potential problem points in a process flowchart.
• Use it when investigating the performance of a process, to help identify where and how it is best measured.
• Use it as a communication or training aid, to explain or agree the detail of the process.

How to Create Flowchart

Are you confused on how to create a flow chart? Most of us don¡¯t know how to deal with flow charts when we are novice users but with the passage of time and experience we gain expertise. A good flow chart helps to understand the systematic flow of information in the system. If a flow chart is not created properly then it may mislead the designer of the system or may result in fatigue consequences. Therefore, it is very important that you create flow chart with caution and expertise. I would always suggest you to use flow chart to ease the process of understanding the system and its flow.

1. Identify the process which is to be mapped. There are several ways this may be discovered:
   • It has an identifiable purpose. A good test of this is to find a realistic name for the process.
   • It has an overall owner, often the lowest level person who has responsibility for the complete process. For cross-functional processes, this is likely to be a senior manager.
   • It has identifiable customers and suppliers (these may be people or just other processes).

2. Gather the team who are to work on describing the process. These should include people who are intimately involved in all parts of the process, to ensure that it gets described as it actually happens, rather than an idealized view.
    
3. Agree on a standard symbol set to use, for example as in Table @@. Alternatively, a company standard may be available. It is important to agree a standard as there are several conflicting common uses (for example, a circle can be a delay, an operation, assistance, an on-page connector or a terminator).

4. Draw a 'start' terminator box at the top of the work area.
5. Add the first box below the start box, identifying the first action simply by asking, 'What happens first?'. Add an appropriate box around it.
   Add subsequent boxes below the previous box, identifying each action by asking, 'What happens next?'. Draw an arrow from the previous box to this one.

    Points to note when building the Flowchart include:

   • Keep the descriptions short and simple. Use a brief phrase rather than a complete sentence. A verb-noun phrase is often useful, saying what is being done to what. For example, 'Check customer satisfaction,' rather than, 'Investigate the level of customer satisfaction using the F3 survey system'.
   • Maintain a consistent level of detail. For example, do not go from, 'Fix television' to 'Replace line output transformer' in the same Flowchart.
   • Aim to keep the Flowchart within one page. This can be useful in helping to restrain the level of detail. Typically this will result in around three to twelve boxes.
   • Identify and include the key decisions in the process.
   • Try to use consistent directions out of decision boxes for the 'yes' and 'no' lines. This can help prevent misinterpretation by people reading the Flowchart later.
   • Aim to make the main flow of the diagram flow from top to bottom, with digressions going off to the right. Branch left only for loops back up and when the right is already occupied. Generally aim for a clockwise flow, but not at the cost of clarity.
   • Have only one 'end' box.
     

6. If the final diagram is to be used as a part of a formal system, make sure that it is uniquely identified. This may include:
   • The name of this process, plus any other unique identification, such as a number from a hierarchical numbering system.
   • An identification of the parent process (if it exists), for example by name or number.
   • The name of the person or group who drew the chart.
   • The owner of chart plus their job title.
   • The version number of the chart.
   • The date the chart was last changed.
     

7. Use the consequent diagram as planned. This might be one or more of:
   • Identification of measurement points. Typically this will be around critical actions such as input/output or expensive actions.
   • Identification of potential problems. Common places for these to occur are around decisions or any form of communication between people.
   • Looking for actions that are missing, wrong or unnecessary.
   • Inclusion in a quality management system as a formal description of the process.

More Flowchart Resource

Use flowcharts to clarify and communicate

A special note on team flowcharting

How to draw flow chart

Flowchart symbols