Has the Process Approach Arrived Yet?


Ever since the year 2000, “the process approach” has been fundamental to the ISO9001 family of international quality management standards, but they still fail to offer a coherent explanation of the underlying concepts.

New versions of ISO9000 (Fundamentals and vocabulary) and ISO9001 (System Requirements) are scheduled for publication in September 2015, but the recently released final drafts (FDISs) risk compromising improvements in other areas of the standards because of ill-defined and poorly presented concepts, with last minute changes adding to the confusion.

Although the redefinition of a “process”, one of the key elements on which the standards are predicated, has addressed a long-standing problem, other key concepts have become less clear.

The final update of an FDIS to create a new standard is usually cosmetic – but in this case the “foundation” to be applied needs to change, and some natural “blusher” might also be appropriate.


Every functioning organization has an existing management system, and ISO9000 has (at long last) recognized that a “quality management system: is part of a management system with regard to quality”.

But this is inconsistent with ISO9001 which implies not only that it should be used to “develop” or “establish” a quality management system but also that this “system” is a separate system and not part of a management system.

Reference to “quality management system processes” suggests that these exist outwith existing operations, and the pervasive references to “PDCA” (Plan-Do-Check-Act) imply that the first step towards compliance is to “plan” the system, even though it already exists in some form (unless you are a start-up company).

ISO9000’s definition of a management system is the “set of interrelated or interacting elements of an organization to establish policies and objectives,” and “processes to achieve those objectives”. This implies (i) that the “processes to achieve those objectives” are not (necessarily) “interrelated or interacting” and (ii) that the actions “to establish policies and objectives” are not processes.

A Note tells us that “the management system elements establish the organization’s structure, roles and responsibilities, planning, operation, policies, practices, rules, beliefs, objectives and processes to achieve those objectives”. So not only are these not “elements” themselves, but we are no wiser as to what the elements might be, other than inferring that processes are not included.

ISO9000 states that “a QMS comprises activities by which the organization identifies its objectives and determines the processes and resources required to achieve desired results” (i.e. “a QMS comprises (i) the identification of objectives and ii) the determination of the processes and resources required…”). This implies that i) the “objectives, processes and resources” are not key elements of a QMS and ii) that the QMS is nothing more than a tool to determine them.

But “identifying objectives and determining processes and resources required” is not “the system”, it is merely “recognizing” the system. And are the “activities by which the organization identifies its objectives and determines the processes…” not also processes?

Does this mean that, if an organization’s objectives are to take advantage of its suppliers, to put the competition out of business, or to maximize profit, then it must determine the processes to do this, and that these processes are part of the QMS?

The management system exists, and what you need to do is to identify those elements of that system which relate to the management of quality. Too many people still think that a QMS is something separate from how you manage and improve the quality aspects of your existing management system.

A (Business) Management System (strictly speaking, a Management and Operational System) is “the structure, processes and resources needed to establish the Organization’s policies and objectives and to achieve those objectives”.


The long-established ISO9000 definition of a process has miraculously been transformed at the eleventh hour to:

  • “a set of interrelated or interacting activities that use inputs to deliver an intended result”.

There is, thankfully, no longer any mention of “transforms”. The previous definition required a “transformation of an input”. As well as generating all sorts of contrived interpretations of “transformation” (such as the mere “passage of time”), it also ruled out any activity where a transformation was the outcome you definitely didn’t want (such as “storing goods in a warehouse”, where you want them to be maintained in their original state).

But the new definition raises its own questions…

Does “to deliver an intended result” signify an intention or an actual outcome (is it the objective itself that relates the activities, or the achievement of the objective)? If you read this as “activities that… deliver a result which was intended”, then this means “deliver an actual result”. This leads to the absurd conclusion that the activities do not constitute a process if the intention is not realized.

The new definition now at least implies that a process has an objective (“to deliver an intended result”). But why not use the term in the definition – it is in the definition of a project (“a unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective…”)?

This implies that a repeatable process doesn’t have an objective – is every instance of every process not “unique”?

Now, all that is needed to complete the “transformation” of the definition is to recognize the need for a trigger event so that we can understand why a process would ever start. The event (or an output from it) is probably the only actual “input” to many processes.

If you have an objective and take action to (try to) achieve it, you have executed a process.




The standards are awash with “Notes” of variable value. For example:

“Two or more interrelated and interacting processes in series can also be referred to as a process.” Is that not precisely because they are a process by the definition? Although why they would have to “interrelate and interact” I don’t know, since this is most unlikely for consecutive activities.

Why must activities “use inputs” to constitute a process – even if they do, is this needed in the definition? For example, “preparing a business plan” may be triggered by someone having an idea for a new project, or just planning to run the business for another year or three. The resources needed (information etc) will be gathered by the people preparing the plan. There does not need to be “input” by anyone else.

And why must the activities be “interrelated or interacting”? Since “the activities deliver an intended result”, does that not “relate” them? In essence, a process is just: “a set of actions triggered by an event and intended to achieve an objective”. It uses resources and is subject to factors which can influence its performance.

Best Practice – or Best Practise (Until It All Makes Sense)?

Many organizations are not very efficient, and many managers are “average”. So why say: “Processes in an organization are generally planned and carried out under controlled conditions to add value”? I wish! Or “The organization has processes that…interact to deliver results consistent with the organization’s objectives and cross functional boundaries” – only in a well-run organization, perhaps? Or: “People collaborate within a process to carry out their daily activities” – some people do not even realise that they are working within a process, never mind collaborate with anyone else.

I have the same concern over the definition of a project (“consisting of a set of coordinated and controlled activities…”). Does this mean that, as soon as there is a loss of coordination or control, the project ceases to exist rather than merely over-running?

If this definition were valid, what makes “a set of coordinated and controlled activities…” different from other processes? The definition includes many elements that apply to any process – surely the definition should qualify which processes are projects and which are not? The definition (“unique process…”) specifically excludes treating a single instance of a generic process as a project, which I believe can be a very practical way to manage work.

Is the Association of Project Management (APM)’s definition (“a unique, transient endeavour undertaken to achieve planned objectives”) not a more useful (and credible) definition?

Figure It All Out

There are two “figures”, or diagrams, in ISO9001. Figure 1 is described as a “Schematic representation of the elements of a single process”: these elements of the process include “Sources of Inputs” and “Receivers of Outputs”, which are defined as other processes – which is patently nonsense for the elements of the process in question.

And “Predecessor / Subsequent Processes” implies a linear sequence, which is one of the problems with the “sequence and interaction” diagrams many people still feel obliged to draw. These diagrams would need to be n-dimensional in some cases to show the complete inter-relationship.


The interlinked definitions and Notes of “Output”, “Product”, “Service” and “Customer” are also unsatisfactory and confusing.

Output is now defined as “the result of (any) process”. The Note which tries to explain “Whether an output of the organization is a product or a service…” implies that it must be one or the other, without saying so specifically. But another Note (“whether the ‘intended result’ of a process is called output, product or service depends on the context of the reference”) contradicts this. I thought that all results are now called “outputs”. Can an output be neither a product nor a service?

Given the definition of an “output”, does the phrase “output of an organization” imply that an organization is a process? I hope not – but what does it mean?

“Product” and “service” now seem to be restricted to the (undefined) “output of an organization”. If, on the other hand, the “output from the organization” is the output from any of an organization’s processes, the inference is that the output from a process which does not involve “a transaction with the customer” must be a “product” (see the definition of “Product” below). This means that the result of a process to “prepare a tender”, “implement a policy”, or “recruit a new member of staff”, is a “product”. This does not sit easily with the use of the term throughout the standards (“launching new products”; “conformity of products…”; “relevant product information, such as catalogues or advertising material”).

Customer: is defined as “person or organization that could or does receive a product or a service that is intended for or required by this person or organization”. There was a time not so long ago when these standards used a simple “supplier – organization – customer” connection. This was (and still is) a clear representation of normal business relationships. But we now have the meaning of “Customer” extended to include Prospects and indeed any possible user of the goods or services offered by the organization, whether or not a relationship exists.

The (self-inflicted) confusion arises from the fact that the recent editions of the documents define a “customer” in relation to “the output from a process” rather than someone who is offered something for sale. If you want to be really confused, try: “in this International Standard, the terms ‘product’ or ‘service’ only apply to products and services intended for, or required by, a customer”,

viz “the terms… only apply to products and services intended for, or required by a person or organization that could or does receive a product or a service that is intended for or required by this person or organization”). All clear now?

Instead of simplifying these terms, we are faced with various attempted explanations of what these outputs (products and services) might be. For example:

Product is the “output of an organization that can be produced without any transaction taking place between the organization and the customer”. If a customer is a “person or organization that receives a product or service from an organization”, surely the relationship involves a legal or monetary transaction (and is often contractual)?

Or is this trying to cover the situation where an organization makes items for stock rather than to order? If there is no transaction, is there no customer? Are a new brand or image, a revised policy, a new member of staff, or damage to the environment, all to be called “products”?

How would you describe goods offered for sale by an organization like Argos, which neither owns nor delivers the goods? The goods are not “produced” by the organization at all – they are made available for purchase.

I have never understood the Notes which attempt to explain possible types of “product” (or “service”). For example, what are “processed materials” if not “materials that have been processed”, ie they have either been input into a process or come out of a process? Or is this referring to a totally different type of process? And a driver’s licence is “software” – surely not!

How does a purchase order to a supplier, or an Invitation to Tender, fit with the definition of a “product”? Each document is intended for the recipient, it is an “output of the organization” and it is “produced without any transaction taking place between the organization and the customer”. This makes a PO a “product”. So every supplier and sub-contractor is a “customer” – surely not!

Service is the “output of an organization with at least one activity necessarily performed between the organization and the customer”. So what is the “activity between” the two organizations when, for example, a bus company provides transport to take rail passengers around a blocked line on behalf of a train company? If it is no more than the agreement to provide the service, then the same logic applies to products, in which case the terms are not differentiated.

Internal Confusion

One of the long-established and deep-seated flaws of the documents is that they talk of “internal customers” and of “receivers of product or service from an internal process”, yet the term “customer” appears to be used throughout ISO9001 to mean “external customers” only – although nowhere is that stated.

So each of the eighty-nine references to “customer” in ISO9001 has to be considered as potentially meaning “internal customer”. Why is “internal customer” even mentioned? Although a key element of good process management is to consider others who are affected by a process, it makes no sense to extend use of the term outwith the context of quality management (“providing confidence to an organization’s customers”). The definition of “risk” has been similarly compromised.

One wonders if the standards are intended as a text book of modern management theory, a compendium of random common or good practice advice, or a concise set of clear requirements for meeting customer requirements.

There is an implication that there are only i) “internal processes” and ii) processes which produce the “output from the organization” – although neither category is defined. What is “an internal process”? Could it be a process where the starting activity and ending activity takes place purely within the organization? I don’t think so – for example, a Sales process might start with a salesman identifying potential targets from a database, and end with him updating the internal CRM system and passing a sales order to Production. Or is it one where there is no communication with a customer (even if there should be)?

I suspect that the concept of an “internal process” has arisen from (the confusion caused by) the concept of “internal customer”, and the idea that an output from one process is input into “the next” process.

The intuitive “supplier – organization – customer” linear relationship has been transmogrified into a Mobius strip of circularity and confusion. But at least there is an obvious name for it – the PDCA Loop (Poorly Defined Customer Attributes loop).

In, Out, Shake It All About

The term “Input” is sometimes used to include “that which is taken in”. But the distinction is key to understanding processes and their management. If you “put something in”, then you (and the action) are outwith the process. If you “take something in” then you, and that action, are part of the process. The documents do not recognize that the distinction matters.

“Output v Outcome” is another key issue which is not properly addressed. An “Output” is put out and an “Outcome” comes out. This is a key element of risk based thinking (“what might come out of the process (now or later) as a result of how we design the process, or how we act, or what might happen outwith our control?”) And “unintended results” are not mentioned at all. “Risks” (and how you manage them) are not new – they are a basic element in planning and process management.

Another problem with the “input – process – output” mindset is the implication that inputs (in ISO terminology) go in at the start and outputs come out at the end, when in fact either may happen at any stage in a process.

Since “PDCA” is not required for compliance with ISO9001, why does ISO9001 (“Representation of the structure of this International Standard in the PDCA cycle”) mention it at all? PDCA is only one of many “tools” which may be useful. Not only is it listed as one possible option to supplement “the process approach”, but it reinforces the implication that an organization has to start by planning a system. And even that approach is flawed since the first step is often (or should be) to Assess the current situation before Planning is started.

Why is PDCA so pervasive in the standard? If ISO were to use its own revision activity as an example, it would realize that it is repeating a process rather than following a cycle. It is (or should be) “assessing” the current situation, “planning” the revision and “doing” (implementing) what is needed to produce the revised version. In due course it will follow that process again.

Moreover, a (new) requirement in ISO9001 is that the organization understands itself and its context (“the organization shall determine external and internal issues that are relevant to its purpose and its strategic direction and that affect its ability to achieve the intended result(s) of its quality management system”. This actually imposes “Assess” rather than “Plan” as the first step to be taken by any organization which seeks to comply.

It is perverse that the standards promote a “process approach” yet imply that a “cycle approach” is a fundamental requirement.

We are told that: “This International Standard employs the process approach, which incorporates the Plan-Do-Check-Act (PDCA) cycle and risk-based thinking.” How does “the process approach incorporate the Plan-Do-Check-Act (PDCA) cycle”? PDCA is not defined as an element of the process approach, and in fact any mention of PDCA merely says that it can be used (and ISO9000 even lists it as additional to “the process approach”).


– but has it arrived?

A business objective can be achieved more effectively and efficiently if the work to achieve it is organized and managed as a set of related activities.

Way To Go!

Indeed there is… before these two standards are clear, concise and consistent, and the “process approach” can truly be said to have arrived in ISO-land.

Peter Fraser

Peter Fraser

Peter Fraser is Managing Director of Mandos Software and of Process Principles. After a career in software systems development, he spent six years as a Managing Consultant with KPMG before founding his own company. He has wide experience in public and private sector organizations in a range of industry sectors in the UK and overseas. He designed and delivered Quality Management modules for an MSc in Project Management and is a published author on business process management and management systems design. He was a leading contributor to the Chartered Quality Institute’s latest revision to its Body of Quality Knowledge. He was a member of the CQI’s Standard Development Group (SDG) and a leading member of the team which produced the CQI’s paper on the future of ISO9000 (later the UK position paper to ISO). Contact Peter at pkfraser@mandossoftware.com / pkf@deethebusiness.co.uk.
Peter Fraser

Latest posts by Peter Fraser (see all)



  1. Claude Patou says

    Great confusion for 9001 users but necessy step to goal this norm toward BSC Management approach.
    Since V2000, target is to build company process from customer interest to customer interest and sustainable company.
    BSC strategic management and deployment in maps and processes in each company BSC part is the implementation elements.
    9001 wants to do the same thing wihout clearly say it : that’s dilem.
    The figure.1 shows very well BSC manager questionning.
    9001 is the reduced method instead had wanted to use directly BSC.
    Since 15 years, 9001 debats and turns around BSC like maelström targetup.

Speak Your Mind