Flow Charts

Flow Charts and Process Maps are often seen as interchangeable but it’s worth being aware of a distinction, even if it doesn’t change the way we work.  Process Maps focus on the relationships between the various steps (or actions, stages, etc.) is a process (a process being the means to achieve an output); Flow Charts focus more on the sequence of steps and, in some cases, addressing the flow of information is more important than the underlying actions.

I want to introduce the three chart formats I’ve found most useful.  The first is what many see as the fundamental type:

This is a simple sequence of actions to make a slice of toast and illustrates three of the most common shapes that can be used: the terminator (to start and end a sequence), the action (where something is done) and decision (where the flow can be diverted to alternative routes – or, in some cases, a delay introduced).  There are international standards covering other symbols; flowcharting software usually includes sets to choose from, the choice depending on the application.  When developing a Flow Chart, be concsious of the level of detail needed – describe enough but don’t try to cover every detail if it isn’t necessary.  The above chart could have included instructions on how to operate the toaster, where the bread is stored (it could even, as one cookery book does, start with sifting the flour to make the bread).  My chart tries to emphasise the need to keep an eye on progress and not rely on the smoke alarm to say when toasting is complete!

The second type I want to show is the deployment chart (also called a swim lane or cross-functional chart).  The emphasis here is to show the step sequence with a focus on who is responsible for each step:

Again, a simple case to illustrate the format.  This one is formatted horizontally (to better fit this page) but often works better with vertical lanes.  A useful variation of this is to implement the RACI scheme for each function.

The final format is the IDEF0 style; introduced earlier when describing processes, a bit more here.  There is a whole family of Flow Chart styles within the IDEF (Integrated DEFinition) family, IDEF0 is used for what is termed “function modelling”.  What follows is grossly over-simplified from the “official” method; rather it uses some of the basic ideas.  In this, we used an ICOM definition for a process step:

Inputs are what goes in to make the Outputs, Controls regulate it and Machinery is what we need to do it.

In generating our IDEF0 chart we start with the top level and define the output needed.  We also need a purpose for producing the chart as it will involve a lot of effort.  Once the top level is outlined, we go down one level and define the key process steps needed; we then deconstruct each of those with a further diagram where necessary, and so on until we get to the level of detail needed.

There are a few basic rules, the key ones being:

  • All process steps need at least one Output; no output, no point in doing anything.
  • All process steps need at least one Control; no control and anything could happen.  Note: whilst most process steps will require an Input, there are some where this is not the case – although it’s easy to confuse an Input with a Control at times.
  • No more than four steps to a diagram.
  • Other than on the top level diagram, all Inputs need to come from somewhere and Outputs need to go somewhere (i.e. they should be on higher or lower level diagrams).

When complete, we should have a very detailed process description.  It’s not possible to include a full set of diagrams in such a brief introduction but a simple diagram might start to look something like this:

I find this type of chart particularly useful for detail process analysis, especially for identifying waste.  For example, it’s not uncommon to uncover process steps that don’t produce an output used anywhere else.

These are just simple examples to show there’s more than one type.  Knowing that helps pick something that might actually be useful…