During our last audit it our auditor suggested/requested that we write more Procedures. Our procedures as of now are for the most part department only. My company does contract manufacturing in mostly PC Boards. He suggested we write procedures on things such as out SMT (surface mount) line. I recently wrote a Procedure on shipping.

To my question: Where do you say 'thats enough Procedures'? Should a company have a procedure for everything that has a start and end? I realize we don't need procedures for restroom visits. I think you will get my point so I'll stop there. Thanks all!

Our auditor told us that if it's important enough to write down, then it's important enough to put into an actual procedure. He was specifically commenting on guidance documents that we have.
Another point is that if it's for something that needs to be replicated the same way every time, then documenting it is a best practice

During our last audit it our auditor suggested/requested that we write more Procedures. Our procedures as of now are for the most part department only. My company does contract manufacturing in mostly PC Boards. He suggested we write procedures on things such as out SMT(surface mount) line. I recently wrote a Procedure on shipping.
To my question: Where do you say 'thats enough Procedures'? Should a company have a procedure for everything that has a start and end? I realize we don't need procedures for restroom visits. I think you will get my point so I'll stop there. Thanks all!

Other than the mandatory "big six" documented procedures, you should have as many as you feel you need, and no more than that. Remember that one of the prime purposes of process documentation is establishment of standard methods. In such cases your people may never have a need to read the documents--assuming they've been adequately trained--but when processes are designed, the design and methods should be documented, which obviates relying on tribal knowledge in the future.

During our last audit it our auditor suggested/requested that we write more Procedures. Our procedures as of now are for the most part department only. My company does contract manufacturing in mostly PC Boards. He suggested we write procedures on things such as out SMT(surface mount) line. I recently wrote a Procedure on shipping.
To my question: Where do you say 'thats enough Procedures'? Should a company have a procedure for everything that has a start and end? I realize we don't need procedures for restroom visits. I think you will get my point so I'll stop there. Thanks all!

Can you give us any more information as to why the auditor was making such a suggestion?

Did they see, for example, a lack of process control or poor product/process performance which might be improved by writing a procedure? Did the auditor detect a lack of consistency in the description (by management and responsible personnel) of the process and its controls, which might also indicate a procedure would be helpful?

If none of these, then your auditor is waaaaaay off in making such comments. Their comfort around more procedures is counter to the revised ISO 9001 requirements (circa 2000) which reduced the reliance on mandatory documented procedures. The auditor has one foot in the past.

I'd suggest that you respectfully ask your CB for an alternate who is a little more 21st century in their understanding of contemporary quality systems and requirements (possibly auditing techniques too):notme:

Andy,

The auditor may not be in the past. It could simply be that it is a process that the company should have documented is not (i.e. is critical, lack of one has resulted in some near-miss customer issues, etc.).

By all means, I preach the "only document what is necessary to document". I also try to create "multi-purpose" forms as much as possible (thereby less forms, less document control, easier for people to complete).

Just an alternate look at the issue.

Another rule I have recently added - If you are going to write a procedure, make sure that tells someone how to do something! Don't just write a procedure for the sake of having words on a page!!:mad:

This is where 4.2.1 d) comes into play. A procedure is the specified way to carry out a process. My take is that if the absence of a procedure would lead to a deviation, then you need a procedure. If the process is so complex (or the competence of personel is marginal), that the steps used to enact the process needs to be formalized, then formalize them. If folks can follow the process without something in writing, and there is no consequence for deviation, then avoid a documented procedure.

Hello! Didn't I say that?

Did they see, for example, a lack of process control or poor product/process performance which might be improved by writing a procedure? Did the auditor detect a lack of consistency in the description (by management and responsible personnel) of the process and its controls, which might also indicate a procedure would be helpful?

I thought that encompassed the examples you've given, folks.......

Mea Culpa....was "keyword" reading.:o:agree:

Can you give us any more information as to why the auditor was making such a suggestion?

Did they see, for example, a lack of process control or poor product/process performance which might be improved by writing a procedure? Did the auditor detect a lack of consistency in the description (by management and responsible personnel) of the process and its controls, which might also indicate a procedure would be helpful?

Really good questions Andy - and more info is definitely needed here, in order to respond to this question helpfully. Otherwise I'd simply be guessing.

Originally Posted by unitedc

During our last audit it our auditor suggested/requested that we write more Procedures. Our procedures as of now are for the most part department only. My company does contract manufacturing in mostly PC Boards. He suggested we write procedures on things such as out SMT(surface mount) line. I recently wrote a Procedure on shipping.
To my question: Where do you say 'thats enough Procedures'? Should a company have a procedure for everything that has a start and end? I realize we don't need procedures for restroom visits. I think you will get my point so I'll stop there. Thanks all!

Writing procedures for a quality management system can be a tedious task, especially the ones apart from the six mandatory documented procedures.

Sometimes, just because the quality engineer/manager within the company has a crush on making new documents or usage of language, he would insist on a document being cooked up, to his liking and to the ire of the process-owner. It can be that outrageous!

A vice-chairman of one of my past clients, was so very involved in his company's QMS documentation, that he insisted on making excruciatingly detailed micro-procedures and forms that not only found frustation and anger amongst the users, but also gave the VC a vampiric status! I don't know if anyone has come across this, but their core procedure (planning for product realization) was a whopping 46 pages (font: tahoma, size: 10, full A4 size)! And no matter how much I tried in vain to convince him otherwise, the more his stubborness towards his micro objectives!

Anyway, the point of all this is - documentation is pointless, if not by the process-owners, for the process-owners. Further, devising non-value adding procedures will ensure that they are happily yellowed down the years of its stagnant and worthless life!

I may be slightly :topic:, but just wanted to make a point about documentation.

Ciao.
SAM:cool:

To my question: Where do you say 'thats enough Procedures'? When you have what you need to effectively do the work necessary.

Should a company have a procedure for everything that has a start and end? Absolutely impossible to do..you'd wind up meeting yourself.

I realize we don't need procedures for restroom visits. Wanna bet? I have one if you need it. Ever been to the head on a submarine, or off-shore oil facility?


You need what you need and only you can come up with the correct answer here.

while, we might agree that assessing the need for a documented procedure/WI for any given process must be evaluated[rationalised!]; consider the following thoughts!

1. what will be the basis/rationale for deciding whether documented-procedure/WI is required or not?
2. how do you justify:confused: your judgement for not having any defined-procedure?
3. how do you justify your 'policy' which says that the "procedures will be documented as the need arises [ok, based on continuous evaluation of need for defining a procedure!]"! [ i guess 'need' is identified/realised through the problems arising out/due of the process]?
4. even if the above approach may well be received for engineering/automotive industry standards where you can retrospectively justify for not having an defined procedures for any process. HOW do you justify the same from the approach where, the need is to define the procedure for 'assuring the product/process quality'. Some times the procedures are equally important as 'production-controls' ?

i might be putting forth these thoughts from point of view of regulated environments[viz., pharma/medical devices scenario]...

thanks in advance for the clarifications
valiveti.

Another way to look at the question of how many procedures to write is what a true quality minimalist would do:

Write no procedures, run the business totally on 'urban legend' and whim of the day management.

Whenever a situation that more scrap was made than was the cost of the overhead to write and maintain the procedure (cost justification), and the root cause was someone claiming they did not know what they were supposed to do, write a procedure.

Whenever a situation that only one person knows how to do a process, and there is a risk that they may leave the company, retire or die, and the cost of the overhead to write and maintain the procedure (cost justification) is less than reinventing the wheel to determine what the process was, write a procedure.

Not very pro-active, but it is what a true quality minimalist following the concepts of quality level TCE would do.

Disclaimer: I am not a proponent of quality minimalism. I just know there is a grass roots struggle to keep its concepts alive. The movement's motto: Keep it simple - darn simple! Bask in the luxury of being simple minded!

Where do you say 'thats enough Procedures'? Should a company have a procedure for everything that has a start and end?

Here’s a slightly different take on this issue: documentation is required for continual improvement.

The documentation of your system, and any QMS, is, of course, used for training and quality assurance. While it may be alright to avoid writing a procedure when it isn’t necessary to produce quality, often this truism is used as an excuse for not writing a procedure that is really needed (or a work instruction, or any other QMS document).

Remember that another use for your documentation that is at least as important as the others is Continual Improvement. Jim above mentioned that a process is documented when designed. Yet most processes evolve after their initial design and implementation. If a process or task is not documented, then how can it be improved?

I believe the reason why documentation as a tool for Continual Improvement is often forgotten is not because it does not exist, but because there are (or, rather, were) several practical obstacles to using it in such way, such as accessibility of documentation, writing skill and the need for control.

Accessibility and writing skill make improving a document difficult even when a potential improvement is spotted. And control of printed documents, and many types of electronic ones, is difficult enough when they change only occasionally. When changes multiply, often control is often lost and documents can end up with erroneous information.

But we are going through a revolution at this very moment. And it will change our perception of what should be documented. The revolution comes in the form of collaborative software called a wiki (and complementary bug-tracking software). With a wiki, you can capture the unique expertise of every person that has any stake in the procedure: the person that designed the process or task, the person actually following the procedure to do her job, and trainees and trainers reading the procedure. They can all improve it. My company used a wiki to implement its QMS (http://www.geometrica.com/7/64). We now have much more useful documentation than I could have ever predicted that we would need, and our processes are much improved as a result.

To summarize, if in doubt write a document. Make these documents accessible and open to all with a wiki, and your processes will improve.

Good luck!
Pancho

Here’s a slightly different take on this issue: documentation is required for continual improvement.

Really? If you are saying one 'must document in order to do any kind of continual improvement', I disagree.

To summarize, if in doubt write a document.

Yikes! No! I'd disagree with that one too!! I'd never give this advice. My advice is always to write a document only when you are clear that

the need really is there - eg, there are some signs/data/evidence to show that not having this documented is causing problems
you're clear about the purpose and the main audience


The last thing we need to be doing in the world of quality is adding to the mountains of useless (and unused) documents.

That said, I do agree that a wiki can be a useful tool, and I can quite understand that if you came from a position of having no (or almost no) doco, or having obtuse, hard to read and hard to find doco to having a wiki with clear & available info available at the click of a mouse, then that would be an improvement and that it could definitely assist with process improvements. But please, doco isn't the answer to all things, nor the best thing since sliced bread either.

My advice is always to write a document only when you are clear that

the need really is there - eg, there are some signs/data/evidence to show that not having this documented is causing problems
you're clear about the purpose and the main audience


The last thing we need to be doing in the world of quality is adding to the mountains of useless (and unused) documents.


See? Now that is quality minimalist approach! Write documents as corrective actions, not as a preventive approach.

I just love the notion of "mountains of useless (and unused) documents." Sure, it is great if the personnel that have been trained on what would be a documented process do not leave the company until if finally closes the doors, so you never need to train anyone ever again, or they never forget their training. And, sure, they may not be read every day - but that does not mean that having paid the insurance against not having a consistent process by having the process documented is not going have a benefit one day in the future. And, if they were never used, it just shows your training process is sloppy, and based in urban legend and rumor. That is not the documentation's fault.

Really? If you are saying one 'must document in order to do any kind of continual improvement', I disagree.


Jane, your disagreement seems a bit empty when you ignore the existing question directly relevant to the issue: If a procedure or task is not documented, how do you improve it?


Yikes! No! I'd disagree with that one too!! I'd never give this advice. My advice is always to write a document only when you are clear that

the need really is there - eg, there are some signs/data/evidence to show that not having this documented is causing problems
you're clear about the purpose and the main audience


Are you saying that you do not need documentation unless not having it is causing problems? That advice would not seem to meet 4.2.1.d of the standard IMHO


What if your client's master craftsman that does not need no stinkin document gets hit by a bus?
What if your client gets an order that exceeds her capacity? Good luck trying to bring Joey Junior up to speed!
And lets say Joey is brilliant and comes up with a new and improved way to do his work. How does your client's organization capture that knowledge?

"write a document only when there are some signs/data/evidence to show that not having this documented is causing problems"

Betcha your clients will take you up on that advice too often... to their detriment.

Although I generally side on the minimalist side of documentation, I believe in writing your procedures in such a way that people can and actually do read them when needed (i.e. remind one how to do things, training, etc.).

My current employer has (kicking and screaming at one point) evolved to the point where we are enhancing our procedures and realizing that procedures for all key processes is a good thing when written and structured properly.

As a general rule, we eliminated most of the gibberish one sees in many manuals (re: regurgitation of regulations, long winded purposes and scopes, etc.). This doesn't mean we don't have these things; but, we do limit them to what is required or make references to them (i.e. OHS regulations)

The minimalist approach is due to the fact that in the past procedures were written for the lawyers and auditors of the world and NOT for the business.

Like anything, the pendulum swings back and forth over time and ending up in the middle. Is either approach perfect, NO - but, there are good points to both approachs that should be considered by anyone creating a QMS.

My last ISO auditor suggested we had less documentation. What it boils down to is that you have to do what is right for your company. We had some duplicated efforts in some areas and could use some streamlining. We like to use our documentation as a training tool for new employees so probably become more detailed then it needs to be. What standard were you audited to? ISO asks for 6 procedures. The rest are what processes the company decides are needed.

We like to use our documentation as a training tool for new employees so probably become more detailed then it needs to be.

Do you mean that the documents are too detailed to be effective for training, or that documentation used for training is too detailed for the system?

I mean that from an auditing QMS standpoint...it is more detailed than required...but from a training standpoint...they are useful.
I am not here to make any auditors job easier, just to do what is best for the company and its employees. It may mean more revisions and some may not agree to put more than the minimum out there. If it is out there it is auditable and you are opening yourself up to more opportunities to get NCR's or OFI's. For our company it is worth the risk. You might as well utilize this tool as much as possible.

I mean that from an auditing QMS standpoint...it is more detailed than required...but from a training standpoint...they are useful.
I am not here to make any auditors job easier, just to do what is best for the company and its employees. It may mean more revisions and some may not agree to put more than the minimum out there. If it is out there it is auditable and you are opening yourself up to more opportunities to get NCR's or OFI's. For our company it is worth the risk. You might as well utilize this tool as much as possible.

:applause: That's what I'm talking about!:applause:

Are you saying that you do not need documentation unless not having it is causing problems?

Nope. :nope:

I said:


to write a document only when the need really is there, and
you're clear about the purpose and the main audience


I gave only a single example of when 'the need really is there' - when you'd write as part of CA perhaps. I did assume some background & intelligence on the part of a reader to know that yes of course one also writes documents as part of good planning and management (PA if you insist) and yes, not waiting to see if there's a problem first. And no, I didn't list all of the times when one might decide a document was really needed.

Presumably my meaning was unclear - why not ask to clarify? That's what I did, requesting more information from the OP before launching straight into advice on the base of assumptions and not enough information.

Similarly, perhaps I've misunderstood your meaning about 'always write a document in order to improve'.

But I do not think your unpleasant and snide comment about potential effects on my clients was either courteous or warranted. And if that's the level of discussion you want to descend to, I don't. And won't. :nope:

What it boils down to is that you have to do what is right for your company.

Yes. Exactly.

Sorry, Jane, you are right. That was uncalled for.

I am sensitive to the minimalist approach. In my business we will often take any excuse not to write a needed procedure. Been known to done it meself.

:o

Originally Posted by JaneB http://elsmar.com/Forums/images/buttons/viewpost.gif (http://elsmar.com/Forums/showthread.php?p=303045#post303045)



My advice is always to write a document only when you are clear that

the need really is there - eg, there are some signs/data/evidence to show that not having this documented is causing problems
you're clear about the purpose and the main audience



Jane, your disagreement seems a bit empty when you ignore the existing question directly relevant to the issue: If a procedure or task is not documented, how do you improve it?

Are you saying that you do not need documentation unless not having it is causing problems? That advice would not seem to meet 4.2.1.d of the standard IMHO


Panchobook, I think you've misunderstood Jane. Jane's criterion was "...write a document only when ... the need for it is there", which is much more general than "...when not having it is causing problems".

Jane, I think you could've addressed Panchobook's specific question about possibility of improvement very simply: when the need to improve a procedure is there, and it cannot be improved (in auditable way) without documenting it first - yes, it does make sense to go ahead and document it.

The point I'm trying to make here is: I think that detection of the need to improve a procedure does not require the procedure to be documented. But, once such need is detected (and, IMHO, proven to be worth the trouble) - well, then documenting the procedure is very likely to be unavoidable.

Also I think that the real need to improve something rarely can be detected (let alone be proven to be worthwhile) without taking a look at this "something" in a bigger context first. And in that bigger context you rarely need to (ideally, shouldn't) know all the details of the procedure: usually, all you need to know is the "interface" between the procedure and the context in which it is being invoked.

In other words, document a procedure (= document particular way to perform an activity or process) from the very beginning only when the need to document it is clear from the very beginning (e.g. when the procedure is very complex, very critical, very rarely used, etc.); otherwise, documentation of the higher-level activity/process realized by the procedure may be more than sufficient as a starting point.

Perhaps it's my background (software development) that is shining through here: the key approach to "managing complexity" in my profession is to always distinguish interface of something from actual realization of that interface. "Surface" from "internals", if you wish. The more clear the distinction, the easier is it to manage complex code (and fix/improve it when necessary).

I am not sure that this approach is directly transferrable to the QMS/BMS domain, but at this point I feel like it is.

Perhaps, the key difference between the problem in question (how much to document?) in these two domains boils down to the following:
software developers cannot have unrealized interfaces (read: undocumented procedures), because computers are absolutely dumb - they cannot do anything without written code (read: very, very, very detailed and precise procedures, work instructions, whatsoever)
whereas
organization management system can have undocumented procedures because human beings are smart enough to do a heck of a lot of things without detailed instructions (including improvement of their own activities).
Peace?? :smokin:

At the risk of repeating myself, I stand by what I already wrote (emphasis added):

to write a document only when the need really is there, and
you're clear about the purpose and the main audience

To me, it's clear that there are needs in software development, for example, for user specifications, functional specifications, test cases, etc.
(But this thread isn't about that use of 'procedures' which I think is clear from the forum it's in and the context.) And to Panchobook and his particular context & improvement requirement, there also appears to be a firm need. I think he and I had reached a good understanding and appreciation of each other's positions earlier. ;)

At the risk of repeating myself, I stand by what I already wrote (emphasis added):

to write a document only when the need really is there, and
you're clear about the purpose and the main audience


What is the risk of repeating here?! I believe statements like this one are worth repeating over and over, because it's way too easy to fall into "overdocumentation" trap...


And to Panchobook and his particular context & improvement requirement, there also appears to be a firm need. I think he and I had reached a good understanding and appreciation of each other's positions earlier. ;)


I'm glad to know that you had. I just didn't see that from the previous posts (so I jumped in). I think I could blame it on ambiguity of human language: I did not realize that when Panchobook was talking about improvement, the established need for improvement was already assumed. I :bonk:, sorry.



To me, it's clear that there are needs in software development, for example, for user specifications, functional specifications, test cases, etc.

(But this thread isn't about that use of 'procedures' which I think is clear from the forum it's in and the context.)


And here I obviously failed to convey my point. :(

:topic:

I was not talking about THOSE kinds of software-related documentation. I was talking about "interface vs. implementation" distinction in software development vocabulary which seems to be a very good analogy to "process vs. procedure" and "activity vs. procedure" distinctions in ISO vocabulary (or, to some extent, to "overview vs. details", "surface vs. core", and "what vs. how" distinctions in common speak). And then I was trying to explain how that affects the thread's questions like "When to document a procedure?"

Obviously, my excursion to "analogy world" was made at wrong time (you and Panchobook already had a mutual understanding). But I maintain that it is quite relevant to the subject of this thread as a whole. After all, I hope you would not say that everything and everyone is clear about "process vs. procedure" distinction in ISO world, and that this distinction has nothing to do with documentation. Or would you? ;)

Of course, please feel free to consider this question rhetorical - at least, in this thread. ;)

Best regards,
Yarik.

Thanks to all who have posted. I've read through and have gotten a lot of great responses. Without looking back I may not have mentioned that I work in contract manufacturing for PCBoards. We have different lines that I would think could have a procedure written to each. However as mentioned in responses prior I'm sure our QM would rather be lean as possible when it comes to Auditable procedures. Myself I like the idea of having these in place where possible to maybe cause a more organized atmosphere. Not to say we are unorganized but there could be improvements that would make for easier production IMO. We have a small company and we are fairly new in our ISO acceptance. Mostly I wouldn't want to get us into something that would really get use zinged in the next audit but would love to see efforts that would make a difference in the company.

Thanks to all who have posted. I've read through and have gotten a lot of great responses. Without looking back I may not have mentioned that I work in contract manufacturing for PCBoards. We have different lines that I would think could have a procedure written to each. However as mentioned in responses prior I'm sure our QM would rather be lean as possible when it comes to Auditable procedures. Myself I like the idea of having these in place where possible to maybe cause a more organized atmosphere. Not to say we are unorganized but there could be improvements that would make for easier production IMO. We have a small company and we are fairly new in our ISO acceptance. Mostly I wouldn't want to get us into something that would really get use zinged in the next audit but would love to see efforts that would make a difference in the company.

The determination of need for documentation shouldn't be based on the danger of getting "zinged." If a document is needed in establishing control over processes and you control the processes in accordance with the requirements, you don't have to worry about auditors.