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]>
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.
