There is too much bad advice circulating on-line at the moment when it comes to management systems audits, some of it from people who should know better, some of it from those who just think they do. An audit is NOT the management equivalent of a Swiss Army knife. It is not a multi-functional tool that can be used to achieve virtually anything. An audit has quite a narrow function and application, but it is nonetheless extremely useful IF APPLIED CORRECTLY. So, first let’s start with a fundamental question …
What is an audit?
People audit for lots of different reasons, so there are lots of different types of audit. They vary in size (sometimes the audit takes in virtually all the company’s activities, sometimes just a single procedure); they vary in complexity (sometimes there are lots of standards, specifications, customer requirements and legislation to check on, sometimes not so many); and they vary in focus (why we want to do the audit in the first place).
Each of these parameters has its own audit terminology. In plain English, the main parameters are:
*What the audit will look at (the “SCOPE”)
* What the audit will check against (the “CRITERIA”)
* Why we do the audit (our audit “OBJECTIVES”)
It is critical that the auditor never loses sight of these parameters, and also that the parameters are clearly understood by the auditee (more about communication requirements later). If nothing else, an audit is a process designed to promote clarity and transparency. If it is shrouded in secrecy and delivered as something of a black art, the auditor is doing the reverse. The auditor’s role is actually quite narrow and limited. The auditor compares the evidence against the audit criteria, and then the auditor records the result. The result is then passed to the audit client (the party requesting the audit) and the client will do with that report whatever they choose.
Things the auditor shouldn’t do? Well, lecture, advise, diagnose, dictate, solve – that’s not auditing. Now I’m not saying there isn’t a time and a place for all those things – just not during an audit. They belong somewhere else.
Process audits versus procedural audits
The amount of TOTAL RUBBISH I’ve seen written on this subject makes me weep. The most common statement that gets my goat suggests that procedural audits are outdated and a thing of the past, and PROCESS AUDITS are the way to go (Daddy-O). Take it from me, if you hear ANYONE saying words to that effect, that person does not know what they are talking about. Take no notice of them.
That said, procedural audits and process audits are different. They are used to generate different kinds of information, but the information generated by a procedural audit can still be valuable. So it’s important that we don’t dismiss procedural audits – we just need to understand their limits, because they do have limits.
When you audit a procedure you are looking at a single task or activity in isolation. Generally the scope of a procedural audit is small, limited to a single task and often to the work of one person. We audit a procedure to establish whether the procedure is being followed. Now, while it is certainly true to say it does not look at the bigger picture (and we’ll get to the big picture later) sometimes YOU NEED TO KNOW if people are following a procedure, especially if that procedure is critical, and/or you need to have a high level of confidence that the procedure is being followed – it could be a regulatory requirement, for example, or safety/mission critical. Therefore when we audit a PROCEDURE we generate CONFORMANCE information limited to the scope of that procedure. The limitation, of course, is that it does not look at the bigger picture, so information on overall system EFFECTIVENESS and EFFICIENCY won’t be determined by a procedural audit – but let’s not dismiss information that tells us that our procedures are being followed as irrelevant or outdated. Procedural audits are usually easier to prepare for and require a lower level of auditor skill and competence – this is simply because a well written procedure is easy to audit and the audit is usually completed by gathering a load of sequential yes/no answers, with not a lot of thinking needed.
A process audit generally involves drawing evidence from a broader range of sources and people and requires more forethought and planning. A well written procedure more or less tells the auditor what sort of questions should be asked during the audit step by step, however when an auditor considers a process audit, there may be no single document that leads the auditor through the process in that step-by-step way. That means the auditor must establish the methodology through effective planning. Despite being generally a “bigger job”, more complex and time consuming, process audits generate information on the general EFFICIENCY AND EFFECTIVENESS of working methods. They can identify duplication, bottle-necks, delays, weaknesses in communication and confusion that procedural audits cannot pick up, FLOW in other words. A useful approach in auditing a process is to adopt the “grave to cradle” approach. That means to start the audit by looking at the results, then to use the findings from that stage to focus the audit trails for other parts of the process, tracking back to process inputs. Looking at results first (say, the last 3 or 4 weeks worth) will help us prioritise our time and target areas of weakness.
In other words, an effective audit system will use a combination of detailed procedural audits to monitor more critical procedures, and process audits to monitor the overall effectiveness and efficiency of the end to end flow. You’ll normally need both, the trick is knowing how to use them and taking no notice of idiots who tell you it’s an either/or choice – it isn’t.