Mike,
Tania hits the nail on the head with her comments. Something that I find useful in this situation is a "Process Flowchart". These can be used for more than just chemical production. It more graphically illustrates the processes, interrelationships, and possible sequencing involved, especially when multiple people/departments are involved. These can be "nested" so that a high level flow chart can be shown to upper management (who only need the big picture) or initial trainees (who haven't a clue). More detailed ones can be used within departments or functions. Each one gives those within the process a bigger picture of what is suppose to be happening and gives them more information and motivation with which to make informed decisions. If one knows the impact of a decision outside their immediate realm of influence they may (and I emphasize may) make a decision that is positive for the entire process and not just their own little piece of it. It also makes it easier to spot failures/faults in the process. This leads to the ability of fixing the problem or revising the process. Where necessary, each of the blocks on the flow chart can have a more detailed flow chart showing the internal process (nesting). This could be continued until you actually reach a level where you are writing procedures; but, its main use is higher level viewing. A point of Tania's response to which I wish to emphasize is the need to involve others in the development. That cannot be stressed to much. It is amazing what comes out of the discussions as to how a process operates when those doing the work are asked how they think the process works. You will usually find a very diverse understanding of what people think is actually going on. Expect to be surprised yourself as to what actually is going on beyond your daily sight and the understanding others have of their roles. It is only at this point that you find out how different the "actual" process is to the "printed" one. It is at this time that you have to decide which is better, the "actual" process, the "printed" one, or another one altogether. You will probably find that both the "actual" and the "printed" processes have good elements and that somewhere in the middle is a more "optimum" process. There are some good software packages that are intended for process flow development. You can do the same with slide presentation graphic package but those intended for flow charting allow you to spend your time thinking instead of drawing. Well worth the minor cost. Oscar Overton [email protected] (OAMO) Opinions are my own. "Tania Grant" <taniagrant%[email protected]> on 11/21/2001 12:18:24 AM Please respond to "Tania Grant" <taniagrant%[email protected]> To: "mike harris" <teccomco%[email protected]>, amund%[email protected], "'EMC-PSTC Discussion Group'" <emc-pstc%[email protected]> cc: (bcc: Oscar Overton/Lex/Lexmark) Subject: Re: Quality Assurance and product approvals Hello Mike, It sounds as if your efforts were very well spent. I probably did not clarify that, in my opinion, people use the term "procedure" very loosely. Without having read your document (and therefore leaving myself open for criticism; but that's O.K.) I would say that what you wrote is not a procedure but more of a guideline or a higher level policy document. You are mostly explaining many things, providing information as to who is responsible to do what, but I don't believe you are really describing "how" those who are responsible are to perform their tasks. Thus, a procedure addresses repetitive tasks in detail, where the details are many and could probably be even very complex, and where probably the sequence of tasks is very crucial, and where you don't want people making mistakes no matter what their level of training is. Your document explains and describes "what" and describes "who" is to do what. If it is multi-departmental, it really falls into a category of a company wide policy. I can see that engineering, purchasing, regulatory, etc, would have their own procedures to support this higher level document. Now, why am I so fixated on not labeling such documents "procedures"? The problem with procedures is that there is usually a very defined format (usually Outline format) that lends itself beautifully to "order" and also to bureaucracy. There are times when you want bureaucracy and strict order, and there are times when you want to communicate, when you want people to understand and follow guidelines but you don't want to institute needless bureaucracy. How many of you have worked in a "procedurized" bureaucracy where there were many procedures that hardly anyone could follow or wanted to follow? The reason is because either the procedures were badly written and, most likely, were written at the wrong level. Proper people with training have no trouble working without any procedures provided they know what is expected and who the other players are. You don't need a "procedure" to define this. But very often the purpose of actions, what is expected, and who the players are, are not explained, but the "how" is rendered in ludicrous detail. Thus, you end up with a "procedure" that is unworkable after 7 months. Procedures should be written either by the people who are performing the work, or at the next higher level; test engineering usually writes procedures for the test technicians to follow. However, I believe that it is better if the test technicians wrote their own test procedure and gave it to the test engineers for review. It is amazing how much knowledge can suddenly be gained during this exercise by both sides! I have written many multi-functional multi-departmental procedures, but I went to a great deal of time and effort to obtain input from those performing the various tasks. I was often surprised to receive different inputs from workers and their managers. Beware of highly placed managers writing detailed procedures telling others how to do their jobs, without honest input. Bureaucracy reigns! [email protected] ----- Original Message ----- From: mike harris Sent: Tuesday, November 20, 2001 3:29 AM To: Tania Grant; [email protected]; 'EMC-PSTC Discussion Group' Subject: Re: Quality Assurance and product approvals Hi Tania, I just finished writing a procedure on agency certifications for a client (prompted by their ISO 9000 audit). It became partly glossary & partly encyclopedia so sales, marketing, etc could find definitions and explanations of what the agencies are and why we need the certifications. It identifies the different levels & types of certifications & why they are needed by various parties. It outlines who does what, as far as design (initial & ongoing), purchasing (ongoing - no stealth changes of critical parts), parts/materials inventory (traceability), etc. It defines who gets notified of new certifications & what records are kept & for how long. I agree with you completely that it would be never-ending to try to write a procedure to allow the untrained to do it all, so it does not explain how to conduct a project at any agency except in the most basic terms (tell the agency what you want to certify, get their cost estimate, write PO, provide samples & documentation, assist as needed). Much can be gained by having such a document, which will seem basic for any competent compliance engineer. It will so nice to refer people to the procedure for the routine questions, instead of doing Agency 101 for the umpteenth time. Mike Harris/Teccom -----Original Message----- From: Tania Grant <[email protected]> To: [email protected] <[email protected]>; 'EMC-PSTC Discussion Group' <[email protected]> List-Post: [email protected] Date: Monday, November 19, 2001 1:18 AM Subject: Re: Quality Assurance and product approvals Amund, Since I transferred, over more than 20 years ago, from Quality Assurance to Regulatory compliance/product safety, I will share with you my opinions and my experience. However, I would also be interested in hearing about the experience of others. In my opinion, QA and regulatory compliance are different enough functions that require different experiences and disciplines that would not necessarily make it effective for a QA organization to either write or enforce procedures on the regulatory compliance functions. That does not mean that regulatory compliance shouldn't have a more formal process and a procedure to go with it. For myself, I know that having a QA background made me a more effective regulatory "guru" at the company. But I don't see how the two can be meshed under the same umbrella without diluting one or the other. Both require focus but it would be a rare Janus that could manage this effectively. However, the regulatory processes could, and should, be integrated into the whole engineering design process;-- and so should the QA process. Thus, the two can and should help each other, but I just don't see that a QA oversight by itself would make the regulatory process better or more effective. Now, I have a problem with your statement "...have your companies made procedures which in details describes the product approval process from beginning to end ?" You are quite right that any procedure should describe a process in detail from beginning to end. This lends itself quite well to any and all test procedures, assembly of various parts, and other such functions where the same process is repeated over and over again. However, with the regulatory approval process, each product is different enough, that a procedure, especially one that is "detailed", would not work. And the approval process is not always "from the beginning to end" but very often just a test or two have to be repeated, but not all, and sometimes you just notify the authorities about this and that, and sometimes you don't, but only document it or write up a justification why a particular test is not required. So how do you write a procedure around this? If I had to religiously do all this, I would be writing a procedure practically every time I was submitting a new or providing changes to a product. And I sure as heck would have been very upset if someone else (say from QA) were writing these "procedures" for me, especially since they wouldn't know what was required, or how to achieve this. A procedure describes "how" something is done. If I don't know how to do it, I shouldn't be working in that position. If the QA person is writing such a procedure (and assuming they are effective at it, which is problematic) then they should be working in that position and not me. Thus, I am not in favor of "procedures". However, I am very much in favor of regulatory compliance plans that should be written for each new product, or a major regulatory up-date to a product. This compliance plan is really a communication device that informs Marketing, Engineering, QA, etc., the regulatory strategy: what the requirements are for this particular product, for which countries, to which standards, where the various tests will be performed, the approximate time assuming only one sample is available, and so forth. I am in favor, when a later update is made to the same product, to add an addendum to the same plan rather than generate a brand new plan. This way you can only add the delta tests that have to be done rather than start from scratch. And you have a history of the compliant process in one convenient location. Note that a compliance plan describes "what" is to be done and sometimes "why", if that is crucial, but it does not really go into the details of the "how". I don't want to start writing "how" I thermocouple the various components to get the product ready for safety heating tests! That, I consider, is part of training;-- and I have trained many to do this, all without benefit of writing any "procedures." However, I do insist (and I believe that all companies also do this) that there is a Hi-pot test procedure available (and I usually review it), and that designated personnel are properly trained on how to run these tests, whether this function is under the QA or manufacturing test umbrella. Thus, I consider that the regulatory functions (safety, EMC, telco, Bellcore, etc.) should be part of the overall design process, to the release to manufacturing production, and finally, to the eventual "death" of the product. Note that this product life cycle procedure is for the overall product process, and not just for the regulatory approval process alone. It is desirable that the design process be documented, probably under a series of procedures, and, therefore, the regulatory requirements be inserted in the appropriate sections. However, no way are they "detailed" at that point or describe "how" the job is to be done. For that, we need trained and experienced people. [email protected] ----- Original Message ----- From: [email protected] Sent: Sunday, November 18, 2001 1:49 PM To: 'EMC-PSTC Discussion Group' Subject: Quality Assurance and product approvals Hi all, What is your experience with Quality Assurance and product approvals ? I mean, have your companies made procedures which in details describes the product approval process from beginning to end ? I have participated on many test projects during my time in a test lab. When I today evaluate that type of experience, I think a lot of the manufactures were not prepared at all and a lot of the sources-to-trouble could have been avoided if they had some kind of check list during the product development and preparation before test. Even good EMC and Safety folks need a kind of procedure to follow. TDo you have the same feeling / experience ? Any comments from test labs on this topic ? Best regards Amund Westin, Oslo/Norway PS: Do they only make QA-procedures to keep track on customers satisfaction and so on, and then forget the product approval process? ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: [email protected] with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson: [email protected] Dave Heald [email protected] For policy questions, send mail to: Richard Nute: [email protected] Jim Bacher: [email protected] All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Hello Mike, It sounds as if your efforts were very well spent. I probably did not clarify that, in my opinion, people use the term "procedure" very loosely. Without having read your document (and therefore leaving myself open for criticism; but that's O.K.) I would say that what you wrote is not a procedure but more of a guideline or a higher level policy document. You are mostly explaining many things, providing information as to who is responsible to do what, but I don't believe you are really describing "how" those who are responsible are to perform their tasks. Thus, a procedure addresses repetitive tasks in detail, where the details are many and could probably be even very complex, and where probably the sequence of tasks is very crucial, and where you don't want people making mistakes no matter what their level of training is. Your document explains and describes "what" and describes "who" is to do what. If it is multi-departmental, it really falls into a category of a company wide policy. I can see that engineering, purchasing, regulatory, etc, would have their own procedures to support this higher level document. Now, why am I so fixated on not labeling such documents "procedures"? The problem with procedures is that there is usually a very defined format (usually Outline format) that lends itself beautifully to "order" and also to bureaucracy. There are times when you want bureaucracy and strict order, and there are times when you want to communicate, when you want people to understand and follow guidelines but you don't want to institute needless bureaucracy. How many of you have worked in a "procedurized" bureaucracy where there were many procedures that hardly anyone could follow or wanted to follow? The reason is because either the procedures were badly written and, most likely, were written at the wrong level. Proper people with training have no trouble working without any procedures provided they know what is expected and who the other players are. You don't need a "procedure" to define this. But very often the purpose of actions, what is expected, and who the players are, are not explained, but the "how" is rendered in ludicrous detail. Thus, you end up with a "procedure" that is unworkable after 7 months. Procedures should be written either by the people who are performing the work, or at the next higher level; test engineering usually writes procedures for the test technicians to follow. However, I believe that it is better if the test technicians wrote their own test procedure and gave it to the test engineers for review. It is amazing how much knowledge can suddenly be gained during this exercise by both sides! I have written many multi-functional multi-departmental procedures, but I went to a great deal of time and effort to obtain input from those performing the various tasks. I was often surprised to receive different inputs from workers and their managers. Beware of highly placed managers writing detailed procedures telling others how to do their jobs, without honest input. Bureaucracy reigns!
|
