Re: How do you decide what is a process, procedure or work instruction?
Define yourself a six tier system. Yes, six, not four;
LEVEL ONE: Quality Manual (Top Management's committment to follow ISO)
The commitment you refer to is generally captured in the quality policy; the QM should be more than that.
LEVEL TWO: Administrative Procedures (document your selected processes)
No issues here; this is pretty much standard.
LEVEL THREE: Work Instructions (document sub-processes directly related to your processes, or level twos.
LEVEL FOUR:Job Instructions (A very important level. These belong to your organization. They explain expressly how you set this part up, how you package this one, how to run this piece of equipment and so on. They are site-specific. You need them but lets not mix them up with the system related documents. You should never have to change these simply because the standard gets updated. You will only revise them if your operation changes. These really don't even have to be audited - just their existence.
Why two tiers here? What's the difference between three and four? They don't have to be audited?? How to you do part/process audits if you don't verify that the work instructions are being followed? I'd like to learn more about your rationale for the bifurcation.
LEVEL FIVE: Blank forms and reference documents (Things like any blank forms that will become a record, SPC ConstantS table, rockwell conversion chart, viscosity table, things that you may want to issue from your own machine but things that are full of unchangeable fact.
I understand the need to control forms (usually tier 4 in a 4-tier system), but I don't see a need for controlling "unchangeable fact." If it's immutable, why does it need to be controlled?
LEVEL SIX: Records. (These are simply evidence that somethng has happened.
Again, no issues; pretty much standard.
And yes, the Quality Manual is nearly a re-hash of the standard unless of course you plan on doing something that is not in the standard or you plan on not doing somethIng the standard requires you to do. If you are going to acknowledge the standard and agree with it why not just say so in your top level, committment document. Typically there is very little direction or instruction within the qualty manual anyway; it is usually policy.
Quality manuals that are "nearly a re-hash of the standard" are mostly worthless beyond the requirement to
have a quality manual; why have a potentially significant document that serves no useful purpose? Most quality manuals are useless because they came into being as a result of desire to fulfill what's seen as a bothersome requirement. If the goal is simply compliance with the standard, a rehash QM will certainly fill the bill, but shouldn't we be aiming a little higher than that?
There is no set list of processes. In fact the recommended list varies from registrar to registrar (who incidentally truly have nothing to do with what you call your processes anyway - it really is none of their business how you satisfy the standard as long as you make it work) Just look at what you do and name your prmary processes.
This isn't about giving things names, like newborn children or puppies; the object should be to
identify significant processes, optimize them and document the proven methods. Again, it's about making things work as well as possible, not worrying about what might be audited or what name you give to something.
There are PROCESS recommendations galore but I would highly recommend resisting calling anything having to do with anything not defined within the standards; costing, profit margins, accounting, personnel benefits, market analysis, bench marking, safety, payment and so on, a process. There are no published criteria within ISO9001:2000 for any of these so there is nothing for you to stake a claim on and nothing for your registrar to reference when they decide to write a NC. They will be auditing these or any other activities that are not defined within the standard to their best judgement and desires, not healthy for you and not healthy for any audit program.
What you
call a process doesn't change the fact that it
is a process, and if a process is perceived as being worthy of control and documentation, it should be controlled and documented. If you do it well (and that's the primary objective, I hope) then you don't have to worry about auditors. The primary function of auditors (internal or external) is to confirm the auditee's contention that the system is working as designed,
not to play "gotcha!". If an auditor (internal or external) is clearly on a search-and-destroy mission, then someone needs to step in and take control, and not allow auditors with fanciful imaginations to make stuff up.
As we discussed in another thread, the standard mandates the existence of certain processes and documents, and beyond that whatever is necessary for the functioning of the system. The idea of a tightly-structured hierarchical document system is a bit old hat, and cleaving to the idea that it's necessary has a tendency to stifle creativity. The best quality systems I've seen are the ones where someone has set out to build an efficacious system, one in which the satisfaction of ISO requirements is a secondary consideration. We all know that it's eminently possible to cookie-cutter your way to registration, but if you set out with banality and needless rigor aforethought, you'll wind up with a system that's banal and needlessly rigorous.
