You are all making some excellent points. It would seem that many of us share commonality. Perhaps that is one of the underlying purposes of the quality organizations. When followed, the effects are positive and things move correctly, and in synch, but when exceptions are present... In my case, the compliance group and the engineering group are one. This obviously has good and bad implications. Brian makes an excellent point that has at times caused my hackles to raise more than once...the independence (or lack thereof) between the compliance department and the engineering department. In the company documents filed by two of these quality agencies, i.e. ISO 900x, A2LA, TUV or COMPASS, there is a clause that specifically mentions the requirement for this independence. Or, is it more of a 'suggestion'? There does not however, seem to be an audit check for departmental independence. I recently have become an ISO auditor, and I am uncertain there is, UNLESS I want to take it upon myself to press the issue. Since I work in the department, I cannot be assigned the task of auditing it, but I could express my concerns with the person assigned the audit of the EMC/Safety/Design engineering department. Hmm... I dont recall where these clauses are, but the purpose behind them is to express the importance of functional isolation between the interests of the two groups. In our case, this causes a disastrous effect on scheduling and allocation of resources because the conflicts are quick to rise and there is a weak attempt to resist. At times, we find ourselves pulled in two directions simultaneously. The 'Janus'..? All the planning, procedures and methods in the world cannot overcome this conflict if no one is willing to meet the challenge and push the issue. (as in our case) My poor boss has been subdued...and our compliance group is eternaly the whipping boy. I see the problem, but I am ineffective at fighting off the 800Lb gorilla's because they do not believe a lab rat...could read, think and speak. Ah, but I can AUDIT, or cause focus by another auditor...that would attract the attention of the QA folks (who seem to be beyond reproach). In the end, the quality of our output is in the hands of the lab rats who, take it upon themselves to ensure the letter of the standards are adhered to despite the conflict associated with the work. That makes it a thankless job, with little if any, appreciation. Ha!! what's that you say...you want a medal? -for driving up COSTS and delaying product release!!! If it were'nt for the beaurocracy...you would not have a job.
[Ehler, Kyle] (my words) -----Original Message----- From: Brian McAuliffe [mailto:[email protected]] Sent: Tuesday, November 20, 2001 4:36 AM To: 'EMC-PSTC Discussion Group' Subject: RE: Quality Assurance and product approvals I think the point raised by Gary re: where the Compliance group fits into the organisation structure is more important than procedures/process, although I disagree with him about where that should be. Let me explain. Having a good working relationship with Engineering is indeed critical, however from my experience I believe it essential for the Compliance group to be organisationally independent of Engineering. If not, then there are always conflicts of interest when allocating the (usually limited) Compliance resources between: Engineering - there are 4 design reviews this week and preparation required for a safety pre-compliance test next week; Operations - the agency auditor is visiting next week and there is some prep needed; Sales/Marketing - the Russian approval is expiring in 2 weeks and you need to re-apply, prepare doc pack, .... etc. How do you prioritise without getting slack from at least one functional head ?? Obviously if the Compliance group is actually a group and not just 1 or 2 persons, then with a good understanding of the roles amongst the group members the above does not really pose a problem. However I do NOT believe this is the case, particularly in the current climate of lay-offs, with us Compliance folk are becoming less essential. Unless the role of the Compliance group is very narrow and involves only support of one function (which I doubt), I feel that an independent Compliance group is essential. It should be functionally independent to any other group and reporting to the MD, or, reporting to the QA Director/Manager. This will mean you can realistically argue for adequate resouces to do a professional job for all those groups requiring your services. You will have somebody independent at the right level in the organisation supporting the Compliance group - essential when $$$ are involved. Let's face it, no R&D Manager is going to approve headcount for a 2nd Compliance Engineer whose primary function is to do audits of the production facility to ensure critical components are controlled as they should, and, to support Sales/Marketing to achieve product approvals worldwide. (To bring this back to procedures/process) There also needs to be a 'document' which highlights: 1. What services the Compliance group offer; 2. The inputs (from other groups) required, and the outputs to be expected from each service; 3. Turnaround time (this will never be 100% accurate) With a document such as this published it raises awareness among each of the functions that the Compliance group do have organisation-wide responsibilites and are not at the beck and call of just one group. It forces them to plan for compliance also. It gives the Compliance group more credibility and visibility, and maybe people will start to appreciate the ..... Brian -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Gary McInturff Sent: 19 November 2001 16:35 To: 'Tania Grant'; [email protected]; 'EMC-PSTC Discussion Group' Subject: RE: Quality Assurance and product approvals Bottom line is that each program generates a set of milestones that identify a function, set of equipment required, and timeframe for getting them done, and there are a set of generic test suites, but generally the whole process is documented at very non-descript level. The rest of this is rational for the way it happens. Over the course of my career ( companies of 40 - to 1,000 employees) this function has 1) grown in scope, first just safety, then safety and EMC, then safety, EMC and DVT, currently its safety, EMC, DVT, and NEBS. 2) It has been shuffled from place to place. Engineering, QA, manufacturing, to marketing. I have always been able to direct it back to what I believe is the correct department - Engineering. Principally for, conservation of resources - I already have some lab rats ( I say this with humor they have saved me much time and grief over the years) , and equipment, I may have to expand the equipment set marginally but I don't have to duplicate it. Probably just as important, is that inside of engineering I have the most timely input into the design changes or recommendations up front. Being located with the design engineers gives us both immediate and personal contact. They can stop into my office, and do quite regularly, to ask questions or seek advice, and I can do the same. As for formality of process it has always been more a series of milestones rather than explicitly documented processes for the vary reason Tania states - things change and they can change rapidly. I do have a series of boilerplate tests such as temperature, etc but occasionally those tests end up confirming - not predicting - what the safety agencies find. I try to find the very earliest point at which I can submit product to the safety agencies and the product is not always 100% functional from a design perspective, but 100% representative of the tests and construction that the safety agencies focusing on. Occasionally, that means a phone call or letter telling them that there are changes before they issue the certificates and possible some re-test but it helps move this part of the design process of the critical path. The same goes for EMC, although that can be a bit trickier and almost always means that I repeat many EMC tests, but the final ones are more validation than praying for a pass as the early units are, and we are pretty comfortable that the project will conclude on time rather than going back for adjustments - which might trigger conversations with more than one outside agency. Marketing puts out a products requirement document and engineering responds with and Engineering requirements. If they have missed agency marks etc, we will feed that back to them in this document. Once everyone agrees what has to be done, the design schedule is fleshed out, and there are a fixed set of prototypes, beta, and production units that are identified and build exclusively for my area or responsibilities, along with a pretty fixed amount of time to complete each of these tasks. - 6 to 8 weeks or whatever. Exactly, what is being done inside each of these tasks left undefined, just as the basic design function is undefined, once the system architecture is defined. I am responsible for project updates and status reports but they are also on a high, rather than detailed, level. Process, problems, design changes needed etc. Gary [Gary McInturff] -----Original Message----- From: Tania Grant [mailto:[email protected]] Sent: Sunday, November 18, 2001 10:32 PM To: [email protected]; 'EMC-PSTC Discussion Group' 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] <mailto:[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?
