--- Begin Message ---
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: owner-emc-p...@majordomo.ieee.org
[mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Gary McInturff
Sent: 19 November 2001 16:35
To: 'Tania Grant'; am...@westin-emission.no; '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:taniagr...@msn.com]
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 <mailto: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.
--- End Message ---
