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.
So to explain it, I’m gonna talk about sex. If not just to increase the clicks on this article, then to explain it in a language most everyone can understand.
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.