- Whistleblower Hotline
- Request Quote
Welcome to The O-Forum! Read this first! Then, feel free to introduce yourself here! If you need immediate, real-time support for the Oxebridge ISO 9001 or AS9100 Template Kits, click here to join our Slack chat channel.
Many folks are still conflating “process” and “procedure” and it hinders the development of a process-based QMS as a result. The two words mean different things in the ISO 9001 context, and it’s important to get them right.
Sex is an activity. You do it (or not, I’m not judging). It is a thing that happens and then a baby shows up or something (I’m still not clear on that part.)
Most people don’t need to read a book on how to have sex (although they probably should.) But if they do, that’s fine (again, no judging.)
In this scenario, sex is the PROCESS and the book is the PROCEDURE. The process is going to exist whether you write or read the book.
Under the process approach, the “process” is the activity, and it occurs whether you write instructions or not. A “procedure” is the documented instructions. So when someone says, “can you hand me that process?” it’s clear they (a) probably mean a document and (b) don’t understand the process approach.
You get to decide when to document a process, and if so, to what degree. Some processes may have 100 procedures supporting them; other processes may literally have none. The level of documentation is based on the complexity of the process and the learning abilities of your workforce. But remember: regardless of whether you document the activities with “procedures” that “process” is still going to happen.
It’s What You Do With It
Now let’s talk KPIs. You sex partner probably has an idea about how good or bad you are at sex. I hate to tell you, but your performance is being judged, by them at least.
That judgment is the KPI: it measures the process (sex); it doesn’t measure the procedure (the book you read). Yes, your partner could judge the book, but that’s not a process measurement, it’s a book review. A bad advice book may lead to bad sex, but that doesn’t make the process bad, it makes the book bad. In fact, you’re sort of jumping to the root cause without consideration (“honey, the problem isn’t me, it’s that damn book!”)
So you apply the KPI to the activity and forget about the procedures entirely. When your process fails, it will show up as poor KPI numbers, which will prompt you to do root cause analysis. Maybe the procedures are bad, but it could be a million other things first.
To recap: identify your processes FIRST, then the KPIs, and then decide if you need to write procedures or not. The procedures may help your process achieve its KPIs, but they won’t have KPIs themselves, because they’re just pieces of paper.
Now don’t get me started on “on-time delivery.” No one wants to go there.
haha, love it.
Re: Now don’t get me started on “on-time delivery.” No one wants to go there.
Every time we get a different auditor, this delivery thing comes up and I say we don’t track it. It’s like the deer in the headlights effect with the auditor. They just don’t get it that not everyone does this.
Unfortunately we are mixing some points. “Process” and “Procedure” are definitely different, but “Documented description of the process” and documented procedure are very often the same.
The user may easy apply process apprach using “procedures” i f these procedures are addressing the requirements of Clause 4.2 of ISO9001:2015.