Home | Book Store | Toolstore | Consulting Room | Contact | FAQs & Search | About

Drop Down Menu

Process Management
Business process management
Process Approach
Process based systems
Process Mapping
Process vs Procedure
Risk Assessment techniques
Process Auditing
Documenting processes
Process improvement

Related Books
The right place to start
Process management guide
Integrated management
Work Packages

Process versus procedures

The language of the 20000 revision to the ISO 9000 series significantly moves away from procedure to process 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 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 difference 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 transform inputs into outputs through use of resources
  • Procedures are driven by humans
  • Processes are driven by physical forces some of which may be activated by humans
  • Procedures may be used to process information
  • Information is processed by use of a procedure
  • Procedures exist they are static
  • Processes behave they are dynamic
  • Procedures cause people to take actions and decisions
  • Processes cause things to happen


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:

  • clearly defined what its objectives are and how it will measure and review the success of achieving those objectives

  • evaluated the impact of those objectives on the interested parties, the stakeholders

  • designed the critical, end-to-end processes necessary to deliver the objectives

  • assessed and provided the resources, skills and competence to make the processes work

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


Active scripting needs to be enabled in IE to use the pull down menus
Last amended 24/08/2013
Home | Book store | Tool Store | Consulting Room | FAQs and Search | Contact

Transition Support 2013