Transition Support

A flexible approach to business improvement

Home Publications Articles FAQs About Contact

© Transition Support  Last Edit 12/12/2022 16:38:07 

The diagrams above show how a procedure differs from a process. In simple terms a process produces an output when activated and a procedure is a way in which one works to produce an output. An output will only be produced if a procedure is placed in the hands of people having the competence, authority and resources to use it. A process includes everything that produces and influences the output which will include the people, the tools, the environment, the procedures and and other resources needed for people to execute the activities required to produce the required process outputs.

The language used in ISO 9000 series significantly moved away from procedure to process in the 2000 version but retained requirements for documented procedures. However in the 2015 version all reference to procedures has been removed. So is this change any more than simple semantics or is there something fundamental going on?

Identifying and managing critical business processes is a vital factor in the effective management of successful organizations. This appears to be a fairly obvious statement. At the heart of the business excellence model there is a strong beat generated by the emphasis on process management. Within the context of quality management standards, and more specifically IS0 9000, 'procedure' is a key word which has acquired a particular meaning over the years.

The term process on the other hand might appear to be new in ISO 9001:2000 but the concept of an organization being a network of processes was addressed in ISO 9000:1994 so it is not new. What is new is the concept that the results an organization achieves are the product of the interaction between its processes and not its procedures.

The following table illustrates the difference between procedures and processes.

  • Procedures are driven by completion of the task
  • Processes are driven by achievement of a desired outcome
  • Procedures are implemented
  • Processes are operated
  • Procedures steps are completed by different people in different departments with different objectives
  • Process stages are completed by different people with the same objectives; departments do not matter
  • Procedures are discontinuous
  • Processes flow to conclusion
  • Procedures focus on satisfying the rules
  • Processes focus on satisfying the customer
  • Procedures define the sequence of steps to execute a task
  • Processes generate results through use of resources
  • Procedures are used by people to carry out a task
  • People work through a process to achieve an objective
  • Procedures are static until changed
  • Processes are dynamic they cause change
  • Procedures only cause people to take actions and decisions
  • Processes make things happen, regardless of people following procedures
  • Procedures prescribe actions to be taken
  • Processes function through the actions and decisions that are taken
  • Procedures identify the tasks to be carried out
  • People select the appropriate procedures to be followed at each stage of a process


In its simplest form a procedure is a way in which one works to accomplish a task. It can therefore be a sequence of steps that include preparation, conduct and completion of a task. Each step can be a sequence of activities and each activity a sequence of actions. The sequence of steps is critical to whether a statement or document is a procedure or something else. Specifications, contracts and records are not procedures as they do not tell us how to do anything. These describe the outputs resulting from carrying out procedures or tasks, leaving us to decide any further actions necessary to use these outputs. The output will more than likely be used as inputs to other procedures.

We need procedures when the task we have to perform is complex or when the task is routine and we want it to be performed consistently Hence procedures are intended to make something happen in a certain way. If we are not concerned about how something is done and are interested only in the result we do not produce procedures but issue instructions such as 'post the letter', 'repair the spin drier' or 'recruit another person'. These are work instructions as they intend us to do 'quantitative' work without telling how to do it or the 'qualitative' standard to which the work should be carried out. Instructions are not procedures unless they follow in a sequence and enable us to perform a task.

A set of self-assembly instructions is a procedure as it tells how to proceed to assemble the product. But the wording on the label telling us not to put hot objects on the surface is an instruction or a warning (a special type of instruction). As procedures are normally used by people they are designed with a user in mind. The user is normally an individual or a group of individuals, although procedures can cover a sequence of steps each of which is performed by different individuals or groups. However, perceptions of procedures vary considerably depending on the context in which they are created and used. Any sequence of steps, no matter how simple or complex, can be expressed as a procedure that is intended to cause someone to act in a certain way to accomplish a task. The key is that the steps follow a sequence. A random collection of statements is not a procedure unless we rearrange these in a sequence that enables someone to proceed.

Is it a procedure or a misnomer?

Within the context of QMSs (and more specifically, ISO 9000) the procedure has, for many, taken on particular and sometimes peculiar characteristics. Such (documented) procedures may be written, not as a sequence of activities or steps but as a series of requirements or a series of responsibilities. Neither of these can be procedures as they do not tell us how to proceed, what steps to take or how to measure the result.

Such procedures often follow a uniform format with a purpose statement, applicability statement, responsibilities and then procedure statements. Often there is no connection between the purpose statement and the procedure. Purpose statements often address the purpose of a document not the purpose of the task which the sequence of tasks is intended to deliver. Again, if such procedures (and rarely they do) contain measures of success, these are probably quantitative measures related to the task itself and not to why the procedure is carried out. The most common perception of such procedures is that they are simply associated with paperwork and filling in forms.

We seem to think that we have created a procedure by classifying a document as a procedure. These documents are often thought of as high-level procedures. Procedures do not have to be documented to be procedures and do not have to be only high level. We often hear of procedures addressing the 20 elements of IS0 9000 and work instructions being used at departmental level to guide activities. These characteristics of procedures only serve to constrain our thoughts and our intent.


Processes produce results by converting. transforming or simply using inputs to create outputs. An input could be material, information, people or a set of conditions and these are passed through a sequence of stages during which they are either used, transformed or their status changed to emerge as an output with different characteristics. Hence processes act upon inputs and are dormant until the input is received. At each stage the transformation tasks may be procedural, but may also be mechanical, chemical etc. Inherently processes do not normally recognize departmental or functional boundaries (but are often hindered by them) nor the boundaries between customers and suppliers. Each process has an objective with both quantitative and qualitative measures of its outputs directly related to its objectives. The transformation or process stages are designed to ensure the combination of resources achieves the objectives - the desired outputs. Of course this means that the process has to receive the right inputs to deliver the desired outputs and that the correct resources are applied at the right stages, in the correct quantities and in the right manner It is true that a process can be illustrated as a sequence of steps just as a procedure is illustrated, but the similarity ends there.

It's the way we use them

The way we use the words procedure and process tells us something about how they differ. We tend to start and stop processes. We implement procedures and commence and complete them. We process information. We do not procedure information but we may employ a procedure to process information. We have plating processes and there may be plating procedures. In this context, the plating process comprises the resources, people, plant and machinery, and the plating procedure contains the instructions on how to plate material.

We have process interrupt but not procedure interrupt, because processes are perceived as continuous and run until physical intervention. In our bodies we have processes, not procedures. The reproductive process, the digestive process, the respiratory process, these processes are certainly continuous and stop only when an intervention takes place. They may require human intervention in which a surgeon may employ procedures to effect a repair. Procedures on the other hand are perceived as being discontinuous, having steps which can be paused with activities or actions picked up or put down at will.

Procedures usually relate to groups of activities with a given output where that output may not be complete until acted upon by someone else at a later stage in the process. Therefore, procedures are the actions taken by individuals in a process that may span across several functions and use multiple resources to deliver a predetermined output at a given rate at a given location on a given date.

All change

Whether any change is necessary depends upon perception and attitude. If documented procedures merely respond to requirements in a standard they are not likely to demonstrate a clear line of sight to the real purpose of why the procedure is necessary. This is very often the root cause of why the people involved do not see the value in carrying out the actions. It is very likely that many organizations will have to undergo a fairly radical rethink of the way they regard their management system. In order to satisfy the requirements, needs and expectations of the interested parties (customers, shareholders, employees, suppliers and community) organizations have to identify the critical processes that deliver satisfaction. It is also clear that the effective management of those processes depends upon common understanding and monitoring of how success is measured. Perhaps the most crucial and radical factor is the constant focus and alignment of the key stages on achieving the end results.

 The implication here is that in many cases the organization and the activities must have a greater alignment. The previous notion of a 'functional' organization (for example, where different departments have created their own internal agendas and cultures with no clear linkage to defined organizational objectives) has to be seriously questioned. It is all too tempting for organizations to address this issue by simply adopting a 'cross-functional' approach which in reality means that they gather together representatives from different functional bunkers and let them fight it out. In general, cross-functional teams are not a substitute for process management. Simplistically, functions tend to be vertical in nature, processes are horizontal, with stakeholder interest at both ends.

 To make a transition away from managing procedures towards process management, an organization must answer whether it has:

The underlying principles of the business excellence model and the latest versions of  ISO 9000, ISO 9001 and ISO 9004 should leave people in no doubt that the change in language from procedure to process is not about perception or semantics. There is a very real change of focus required by many organizations if they are to remain competitive, and with this change comes the significant opportunity to ensure that their processes are designed to consistently add value.

Now look at our FAQs on processes for more information

What is the process approach?

What are the advantages of a process based system?

How do we show the sequence of processes?

Do all processes transform inputs into outputs?

Is a flow chart not adequate enough as a process description?

What do I need to include in a good process description?

How many levels of processes do I need?

How do we identify the sub-processes?

How do we identify the Business Processes?

Why can't we simply add a flow chart as rename my procedures as processes?

How do I convert my procedures into processes?

What’s the difference between a process and a procedure?