What’s the best for ISO: Flowcharts or procedures?
There is a lot of debate about the use of flowcharts and the degree of documentation necessary for an ISO project.
Common misconceptions are that ISO requires only a minimum amount of documentation and thus you should try to have as little documentation as possible, and that flowcharts provide an adequate way of describing a process and thus meet ISO requirements. These myths have been propagated by poor auditors who allow inadequate procedures, however documented, but typically flowcharts. Also there has been an upsurge in Lean and Six Sigma training which frequently tends to denigrate the benefits of ISO (and in some cases is justified but not in principle and not generally) and substantially supports the use of flowcharts to define and describe processes.
Flowcharts have their place. Their goal in Lean and Six Sigma project is to provide enough information to allow an understanding of the process to perhaps look for waste or opportunity. Sometimes these flowcharts have considerable detail including timing information, production rates and other information. These flowcharts are great for that purpose.
ISO requires that processes are defined and that those processes meet certain requirements. A flowchart tends to be general in nature and so to be able to prove that the ISO requirements have been met, additional information has to be added to a general flowchart of the process in question. Sometimes this means adding extra boxes to describe the detail of the requirement. Then all of a sudden, a nice general flowchart with boxes of similar detail, have a couple of boxes that are out of context because they are provide substantial detail. For instance, three boxes might be “plan the activity”, “issue instructions” and “review results”. The ISO box might require “record details and person authorizing the release of the job”.
By the time you have added extra boxes for all of the ISO requirements the flow is broken.
Another approach is to add notes to side of the flow chart and associate them with the box. So now the note about “record details….” would be a note at the side related to the “review” box. This works and the flowchart can remain general or at least consistent in level of detail. Truth is that this is also potentially confusing. The box and notes are not often next to each other and thus referencing and cross referencing makes it different for the understanding to flow with the simplicity of the flowchart. Moreover, if the notes are going to be in sufficient detail to actually describe what the activity is (in order to meet the ISO requirement) then it might as well have been written in full as a procedure anyway.
Flowcharts provide a few key benefits. The provide a simple overview of processes. But they need to be consistent in level of detail, decision boxes cant be contrived (just to make the flowchart worthwhile) and they should ideally fit on one page – or you lose that special benefit of being able to see the whole process.
Obviously all of these issues must be taken with a “pinch of salt” but the bottom line is that if you are trying to create a comprehensive management system, documented procedures are the best way to do it.
Cavendish Scott has been consulting, auditing and training in ISO management system processes and systems since 1985 and has limitless experience of documenting systems, processes and activities. We can also provide training on documenting and implementing ISO management systems.