This week, the Chartered Quality Institute highlighted the confusion surrounding the ISO:2015 standards management system to be introduced in a few weeks' time. Since this new regime will eventually apply to all ISO standards it has the potential to affect millions of organisations around the globe, yet many are confused about its practical application. Indeed the aerospace industry is debating whether a process approach is really the right way forward and some are suggesting a break-away for its next AS9100 industry-specific alternative to ISO 9001.

We agree with the CQI that a process approach makes sense - not just for standards management but for managing an organisation in general. But we also believe that the International Standards Organisation is falling short in its guidance and really does need to get a grip on this.

So to help ISO, this blog briefly addresses what for us are the main areas of confusion and suggests some practical ways that ISO might provide some clarification.

The primary areas of confusion

  • Process versus procedure. There are two aspects to this: firstly the duality of the two terms and their confused usage; secondly their applicability in managing standards.
    • In the UK a procedure is a written document, often pages long, containing multiple sections which describe every aspect of a particular management topic. In the same country, a process is usually defined as an interactive mechanism for capturing and actively managing sequential information. In the USA this definition is not so clear and the term process and procedure are often used interchangeably to describe what the UK would term a procedure. By and large, the USA does not understand the term "process" outside of its use in systems automation. Thus it rarely adopts a true process approach to standards management.
    • When applied to the management of standards - or indeed the organisation as a whole - the process and procedural approaches are very different. A process facilitates an understanding of cause and effect and thus the active, ongoing improvement of an organisation's operations. A procedure confers no such insight. So, despite the ubiquity of procedures, they hold little operational improvement value unless they can be converted into processes. This would be fine were it not that the demonstration of continual improvement is a vital tenet of the new ISO regime. So to appease those industries that are heavily committed to a procedural approach - despite its faults in this area - ISO appear to have provided a get-out clause to which the CQI allude. The use of procedures appears to be an acceptable means of compliance with ISO:2015 provided that somehow they are linked together in sequence. This is a shoddy compromise which ISO really does need to address.
  • Process versus process. Modern organisations cannot survive without processes: they are the backbone of our IT systems and our production machinery. But the language needed to successfully communicate a process to a machine is very different to that needed to do the same for a person: and the management of standards is all about people. Thus there are fundamentally two different types of process - one for machines and one for people - and they are incompatible. Try and apply one to the other and confusion reigns. We are not suggesting that it is ISO's job to dictate a process language but it would be helpful if they were to communicate this fundamental difference to the buyers of standards management systems and to CIOs.

How the International Standards Organisation might help

To summarise, we believe that the International Standards Organisation needs to provide urgent clarification if its new regime is to avoid failure due to confusion. Our suggestions for this are as follows.

  1. Standardise the term "process" across the globe so that it is clearly distinguished from a procedure.
  2. Drop the linked procedure substitute for process management. It can never facilitate the same level of cause and effect analysis.
  3. Define the required process language for standards management. We have long supported the IDEFO language which was designed for this very purpose. Equally we fail to see how systems languages such as BPMN and BPMN2 can ever be applicable.