Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Simple ISO 9001 Compliant Document Control

#22
[Andy N] "Mirror" was my choice of language, not his. And his arguments were sufficiently logical that I agreed to address the issues.
"Arguments" are NOT the basis of non-conformity. Objectivity is. Where, objectively speaking, does it say your document control procedure has to state what the standard states? Where is there evidence that your document control procedure isn't requiring something and then this leads to implementation ineffectiveness?

ONLY when an auditor has framed these two issues in their report, do you have enough to work on a corrective action. Being a good auditor isn't "selling" an argument of another way to do things!
 

insect warfare

QA=Question Authority
Trusted
#23
If I may chime in for a bit....

I've read several posts in this thread which seem to advocate the abandonment of a number classification (or codification) system altogether. I do hope that everyone here continues to be aware that there are almost always exceptions to a rule, and as such, this particular one should not be thought of in absolute terms - because every organization is still unique.

Take my situation for example. I do not number my documents to any clause structure (thankfully), but I still "codify" them nonetheless because of one very specific reason - our document titles alone just don't make our documents unique enough.

As we are a smartphone refurbishment company which manages multiple accounts, on the surface the requirements of a particular account may look identical to our other accounts (with common processes such as re-flash, RF/LTE testing, factory reset, etc.), but the testing requirements of these similarly-titled processes can vary greatly, depending on the objectives, resource availability and other various capabilities associated with each account. Without a solid numbering system for us to codify and separate these work instructions/procedures, there would be much internal confusion as to what belongs to who.

Naturally, I had to take all of this into consideration when setting up the original system to keep up with all the curve-balls I knew I would be thrown as a process owner, after all our resources were just as limited as the next organization (currently we are sporting 9K, 14K, 18K and R2 certifications, so we must have been doing something right up until then).

While our document codifying system works well for us, I can also appreciate the merits of not employing such a system - only to the extent that it does not negatively impact the effectiveness of the business management system itself.

My thoughts....

Brian :rolleyes:
 

Pancho

wikineer
Super Moderator
#24
...
As we are a smartphone refurbishment company which manages multiple accounts, on the surface the requirements of a particular account may look identical to our other accounts (with common processes such as re-flash, RF/LTE testing, factory reset, etc.), but the testing requirements of these similarly-titled processes can vary greatly, depending on the objectives, resource availability and other various capabilities associated with each account. Without a solid numbering system for us to codify and separate these work instructions/procedures, there would be much internal confusion as to what belongs to who.
...
Interesting point, Brian. When you get a new account, do you set up new testing procedures specific for that account? Do you also have a "generic" version of the procedures with a different number?

Being project-driven, we have a similar problem. Each project has a unique contract, with specific requirements for that project. Upon logging a new job, it gets a project-number and its own workspace to contain documents specific to that project. Then, within each project, we use a document numbering system. In our system, project numbers and project-document numbers have three reasons to exist: (1) they keep the various "Design Reports" or "Installation Manuals" for different projects distinguishable, (2) they provide a convenient sort method for often-used tables of documents within a project, or tables of projects, and (3) clients seem to like them.

But we call all project documents "records", since they have a limited life, and, ultimately, their purpose is to evidence of our compliance with the contract. For example, installation manuals for a project are copied initially from a generic template in our QMS into a project's workspace. Then the specific project variations are composed there, separate from the main QMS, as a project record.

Conversely, new work methods, initially needed for a particular project, usually get their own document in our main QMS workspace (without project-doc numbers, save for their url) so that they are available as generic methods when the next project comes along that needs something similar.
 

insect warfare

QA=Question Authority
Trusted
#25
Interesting point, Brian. When you get a new account, do you set up new testing procedures specific for that account? Do you also have a "generic" version of the procedures with a different number?
Every new account comes with its own unique surprises and twists. Sometimes, the account manager may have unorthodox requirements handed down from their client for which we are totally caught off-guard and have to improvise an equally unorthodox solution (maybe a new test method is developed or migrated), other times it turns out to be the typical cookie-cutter issue-and-release. After all, the smartphone industry is inherently an impulsive one - everyone wants what they want, and they want it yesterday.

Being project-driven, we have a similar problem. Each project has a unique contract, with specific requirements for that project. Upon logging a new job, it gets a project-number and its own workspace to contain documents specific to that project. Then, within each project, we use a document numbering system. In our system, project numbers and project-document numbers have three reasons to exist: (1) they keep the various "Design Reports" or "Installation Manuals" for different projects distinguishable, (2) they provide a convenient sort method for often-used tables of documents within a project, or tables of projects, and (3) clients seem to like them.

But we call all project documents "records", since they have a limited life, and, ultimately, their purpose is to evidence of our compliance with the contract. For example, installation manuals for a project are copied initially from a generic template in our QMS into a project's workspace. Then the specific project variations are composed there, separate from the main QMS, as a project record.

Conversely, new work methods, initially needed for a particular project, usually get their own document in our main QMS workspace (without project-doc numbers, save for their url) so that they are available as generic methods when the next project comes along that needs something similar.
That's pretty much how we approach things, for the same 3 reasons you mentioned, and in some cases we have activities that are given a separate doc. classification because they apply to all accounts and the testing requirements are identical - this is just one of the many things we get to evaluate in the planning stage. For our engineering teams, using generic templates or other existing documents significantly cuts down on their preparation time (no need to re-invent the wheel every time) and everything is pretty much archived electronically after an account is closed, or if something is no longer applicable.

I have always stood for alpha-numeric classifications when the need calls for it. This just happens to be true in our case, as I'm sure it is in yours. Thanks for sharing your situation and putting some further perspective on this.

Brian :rolleyes:
 
Top Bottom