Here, here !

Best regards,

Daniel E. Teninty, P.E.
Managing Partner
DTEC Associates LLC
http://www.dtec-associates.com
Streamlining the Compliance Process
5406 S. Glendora Drive
Spokane, WA 99223
(509) 443-0215
(509) 443-0181 fax

  -----Original Message-----
  From: owner-emc-p...@majordomo.ieee.org
[mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Tania Grant
  Sent: Sunday, November 18, 2001 10:32 PM
  To: am...@westin-emission.no; '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.

  taniagr...@msn.com

    ----- Original Message -----
    From: am...@westin-emission.no
    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:
         majord...@ieee.org
    with the single line:
         unsubscribe emc-pstc

    For help, send mail to the list administrators:
         Michael Garretson:        pstc_ad...@garretson.org
         Dave Heald                davehe...@mediaone.net

    For policy questions, send mail to:
         Richard Nute:           ri...@ieee.org
         Jim Bacher:             j.bac...@ieee.org

    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.

Reply via email to