> to contribute. In a nutshell, you say what you do and then you
consistently
> do what you have said . That's about it. In many ways it makes jobs so
much
> easier  having consistent process documents. Work can be handed over to
> colleagues with confidence and the whole review process is much
simplified.
> Any engineer worth their salt, no matter how eccentric, would at one time
> have kept very detailed notes and would have been regarded as superfluous
> otherwise. QA in this context is just a way of retaining, disseminating
and

The idea behind ISO9000 is just plain "common" sense (I put "common" in
quotes because common sense really isn't very common).  So why do we need a
trendy business school graduate buzzword to invoke it?  Because the trendy
business school graduates need to justify their existence and oversized
paychecks and golden parachutes somehow ;-)

One of the difficulties with implementing ISO9000 is getting everyone to
document their procedures adequately.  This is especially difficult when it
involves any of these folks:

1) Shop (blue collar) workers
2) Engineers who are borderline incompetent
3) Primadonnas

In the case of (1), many shop workers have developed techniques or methods
over the years to do (or to not do!) their jobs.  They see any attempt to
document this as a threat to their "indispensibility".  In other words, it's
a job security issue with them.  They feel that if their job is documented,
they will be fired and replaced by a lower paid worker.  And this feeling is
not entirely born of paranoia; worker replacement happens quite often.
Sometimes it's with a lower paid domestic worker, other times it's done by
closing the factory and moving the work to an overseas factory.

In the case of (2), lack of documentation can be used by barely competent or
incompetent engineers to disguise their inadequacies.  If the "magic" is in
their head, it's not out there for anyone to critique or subject to the
scientific method.  The goal of this is once again, job security.

In the case of (3), these folks are offended that you would even question
how they do something.  Because if they do it, it by definition must be
correct.  And to try to capture the subtleties and nuances of their
knowledge and methods would be both futile and offensive!  Sometimes the
primadonnas really are good at their job.  But occasionally, you will find a
person that is both (1) and (3), or (2) and (3), that is, a blue collar
primadonna, or an incompetent engineer primadonna.  What fun that is!  These
people are incapable of learning, because they think they know it all
already.

In any case, it's amazing to me how some of these people can befuddle those
around them into thinking they are "all that".  True story:  at one of our
customer's sites, there once was a guy in their customer service department
who everyone thought was a nice guy.  And most of the time he could fix the
machines.  But no matter how many times and in how many ways you ask him to
document or explain what he did, you would never get any information out of
him.  It was rather maddening to me when I had to help him diagnose a
problem with the control system.  I would ask him questions which he never
would answer in a useful manner.  So all I could do was dream up all
possible failure modes and tell him how to solve each one.  I guess that was
his way of acquiring all the repair knowledge without having to understand
any of it.  So who was the clever one?  It wasn't me!  He worked for that
company until he decided to retire.  And everyone thought he was really good
at his job.

How would you document the engineering process?  Would it go something like
this:

1)  Brainstorm and generate ideas
2)  Draw schematics and diagrams
3)  Run simulations
4)  Design prototypes
5)  Build prototypes
6)  Test prototypes
7)  Refine prototypes
8)  Until done goto (1)

Wow, that was easy!  With engineering process documentation like this, I am
so replaceable!

Best regards,
Ivan Baggett
Bagotronix Inc.
website:  www.bagotronix.com


----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Protel EDA Forum" <[EMAIL PROTECTED]>
Sent: Friday, June 06, 2003 4:25 AM
Subject: Re: [PEDA] A little OT - PCB labelling


>
> How about a debate on QA then... perhaps not. (so here I go)... I was
> involved with writing QA for 9000, in fact every engineer and manager had
> to contribute. In a nutshell, you say what you do and then you
consistently
> do what you have said . That's about it. In many ways it makes jobs so
much
> easier  having consistent process documents. Work can be handed over to
> colleagues with confidence and the whole review process is much
simplified.
> Any engineer worth their salt, no matter how eccentric, would at one time
> have kept very detailed notes and would have been regarded as superfluous
> otherwise. QA in this context is just a way of retaining, disseminating
and
> applying this knowledge.
>
> Rob




* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to