Eternal procedure vs process doubts.


Involved In Discussions
Reading some articles about the differences between Procedures and Processes, I usually find that Processes are "what" and procedures are "how" things are done.

This White Paper gives this description of each

are a high level view of the organization’s activities. The key tasks within the overall process are identified. Process descriptions usually refer to several individuals or teams as processes tend to flow across the organization. ISO defines a process as a set of interrelated or interacting activities which transforms inputs into outputs. So every process will have a clearly identified input and output, and depending on whether these are internal or external, there will also be a customer or set of customers.
Procedures are the detailed steps that describe how a process step will be performed.

This is a bit odd to me, and I guess that it may be so only for QMS, but for BPM for example, you would only have different levels of processes. Macro processes, processes and subprocesses. And processes being made up of tasks.

And tasks sometimes having descriptions if they are more complex. However, I feel a task description would usually be compared to a Work Instruction.

The paper also tells that a Process can have 1 or several procedures. Which is also a little odd to me. For if I think of a standard ISO required procedure, DOCUMENT CONTROL, it's almost the inverse. It's a procedure and it can have several processes associated, like "Document Approval Process", "Document Creation Process", etc.

So, a process having several procedures only makes sense if we are talking about macro-processes... Macro Process Document Control corresponding exactly to Procedure Document Control, which has several smaller processes. Or do procedures (Document Control) have sub-procedures?

But let's follow with this description of Process and Procedure.

Then we have, in the Quality Manual, a list of processes, how they correlate and their sequence. Fine.

But everytime I hear about ISO documentation, people talk about Manual > Procedures > Work Instructions

So, how do they correlate the processes described in the Manual to the written Procedures? Documented Processes are not or hardly ever mentioned as separate entities outside the manual. Should the process just be refered to in the code for the Procedure Document?

Example: Risk Management Process in the manual. Then I would have procedures Prd.RiskMan-001-2.2 Analyzing Risks, Prd.RiskMan-002-1.5 Treating Risks

It somehow makes more sense to me, instead of saying that a Process is a more "macro" thing made up of several procedures, just to think that a Procedure is a more textual description of a Process.

In that line of reasoning, I would have macro processes in the Manual, how they relate and in each order.

Each macro process corresponds to several one or more written procedures, that may include a flowchart of the process.

Written procedures have topics/sections, which correspond to sub processes.

Example: Risk Management Process in the manual. Then I would have a single procedure, like Prd.QMS-004-2.2 Risk Management.

Inside the procedure document, I would have a workflow of the process. And I would have a written description of the Risk Management, with sub-topics, each subtopic refering to a subprocess (with or without flow diagram) like Risk Discovery, Risk Analyzis, Risk Treatment...


Involved In Discussions
Another reason it seems to be odd that ONE process has multiple procedures... our Internal Audit Procedure, for example...

It has several definitions about Auditors Requisites, about timing of Audits, how Auditors should behave, etc.

And it inside has several Auditing related processes: Audit Planning, Audit Execution, etc.


Involved In Discussions
well, that depends on how monolythic and centrist the planning, execution, etc, is, I guess.

Audit planning may involve activities like decide auditors based on scores, checking auditors availability, decide areas to be audited, assign available auditors to areas without conflict of interests, print and distribute to auditors the audit checklists...

Audit Process | Office of Internal Audits | The University of Texas at Austin

imho, in the left, clearly processes, while the list on the right shows activities


Involved In Discussions
Of course, if you are a competent auditor, this isn't even necessary...
well, the internal audits are performed by a multi-disciplinary team from several departments. And they were not hired based on their audit capabilities, even if they train for audits. So, they are the best auditors we can have from inside the company. Are they as competent as external auditors, and as knowledgeable about ISO and all related standards? Nope.

So yes, that is necessary for our internal audits. If the University of Texas which probably has over a thousand employees, most of them with PHDs, need such, we do need too.

But anyway, we are digressing by entering in an argument about the specifics of the auditing process, subprocesses, etc.


A problem shared...
Staff member
Super Moderator
The white paper seems to be at odds with history. A procedure hasn't been (traditionally) used for "activities" - that was work instructions (going back as far as ISO 9001/2/3 1987.).

Processes haven't been a "high level" description of "activities" either. I believe an ISO 9000 definition describes a procedure as a way to implement a process.

The issue is that you need to have control over processes. That can be accomplished in many (documented). A well designed form can accomplish this and become a record. Too much time is spent debating what pigeon hole to put a document in - often because of some arbitrary document numbering scheme which isn't even needed - rather than understanding the need for process controls and for a good reason to write stuff down. No wonder (senior) management treat ISO compliance like a dead skunk!

BTW - a small business I'm familiar with wrote their one end-to-end process on the wall of their conference room, along with inputs/deliverables and responsibilities. All 6 people contributed to defining those processes. The owner agreed and said "That's what we do. Did that meet ISO requirements in your mind?

John Broomfield

Fully retired...
Process is work. Usually the work of interacting people, machines and/or animals. Work applies resources and controls (from the system) to change inputs into outputs.

A procedure describes the execution and control of the work. The procedure is documented to the extent necessary. The procedure may be well enough understood by the people doing or controlling the work to make the document unnecessary. A procedure may refer to an instruction for a specific task within the process. A procedure may refer to a form to collect the required data. A machine may be programmed with detailed documented instructions to complete a task within a process.

Work is fundamental to our livelihoods and this is why I clearly differentiate between procedure and process.

Peter Fraser

Trusted Information Resource
<ISO defines a process as a set of interrelated or interacting activities which transforms inputs into outputs.>
Not any more it doesn't. But they still seem to have a major problem understanding what a process actually is...