Darrel, and all,
You are absolutely right in your answer here; it depends. I tend to
forget that not every business is the same as the one I am currently
working at. This issue is not a single issue, by any means. Whatever
system is used has very far-reaching implications for not only the OEM,
but also for their customers.
I probably jumped because of the fact that I know many of the
simplifications of a rollup can also create a full time job for somebody
who needs to determine backwards compatability, for example. "Can this
assembly xxxxxx-01 be put into final device xxx-03?" or "We have a
number of subassemblies 1234567-890 that were reworked into a new part
2345678-901, will we be able to use them on devices 98765432-10?" And so
on and so forth. Keeping this info on the BOM as alternates helps. 
And again, your statements about the MRP system's ability to control all
of the various aspects of a single part number can make it a formidable
task to configure for one system, but much easier for the other.
So, I need to qualify what I said before. What works for one company may
not work at all for another. But generally speaking, having to bump the
revision on everything above the level actually being changed does
create a lot of extra work.

-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Darrel Therriault
Sent: Monday, October 10, 2005 1:29 PM
To: [log in to unmask]
Subject: [TN] Revisions

Richard,

It's been interesting reading all of the different replies on revisions
and documentation.  I think the real answer is "it depends" on what you
need to accomplish.  Rolling revs to the top for everything takes more
effort and work, but I always thought it was the cleanest too, so it
depends on if you want to do that or not.

In my experience with several different systems, I found that
compatability or interchangeable/non-interchangable was the key for me.
Bumping a rev does make it a unique p/n, but when you have the same
class code and base number, sometimes people just don't look at the rev
and it can easily get missed.

Which brings me to another "it depends" moment.    How much intelligence
is in your p/n?  If you have fields for charting, compatability or other
items that make it easier to identify, you might do one thing and if
they are just sequential numbers, you might choose to do something else.
It depends.

I always try to take out a new p/n for things that are not compatable
and build a whole doc package around it.  Takes extra work, but with all
of the editing, cut and paste and make from capability, I don't think
its as bad as it used to be.  With multiple CMs and offshore, it seems
making it bullet proof to whomever needs it a high priority, so a little
extra doc work is much less costly then not having it built the way you
want it and all that that entails.

One thing I did years ago was create a "Top Sheet" for the doc package,
which listed all the documentation items and their revs, along with the
ECO that changed them.  It allowed different revs for each item, but you
could see it all on the one sheet.  It worked for most items.

Like most things, experience is the great teacher, and we all have our
experiences that drive our preferences.  Mine was an artwork change to a
PWB that Engineering thought was so simple ( a few cuts and jumps on
outer layers only), that they did not want to spin the fab but just edit
the existing Rev A PWB, do the cuts and jumps and bump it to Rev B,
without taking a new p/n.  You guessed it......CM did not even notice
the rev B requirement, procures the Rev A since it had the same Class
code and base number, and we ended up with a bunch of boards that did
not work.

Since then, I try to take new p/ns for any change, rather then bump
revs, for incompatable things.  Having different revs for compatable
changes is okay, but not as clean as rolling to the top, just takes a
bit more work.
It depends on what you need and how much documentation push back you
get, but I always thought knowing something changed at all levels made
sense.
Then there are marketing p/ns, but that's a whole different can of
worms......



---------------------------------------------------
Technet Mail List provided as a service by IPC using LISTSERV 1.8e To
unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF Technet To temporarily halt or
(re-start) delivery of Technet send e-mail to [log in to unmask]: SET
Technet NOMAIL or (MAIL) To receive ONE mailing per day of all the
posts: send e-mail to [log in to unmask]: SET Technet Digest Search the
archives of previous posts at: http://listserv.ipc.org/archives Please
visit IPC web site http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for
additional information, or contact Keach Sasamori at [log in to unmask] or
847-615-7100 ext.2815
-----------------------------------------------------
DJT

---------------------------------------------------
Technet Mail List provided as a service by IPC using LISTSERV 1.8e
To unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF Technet
To temporarily halt or (re-start) delivery of Technet send e-mail to [log in to unmask]: SET Technet NOMAIL or (MAIL)
To receive ONE mailing per day of all the posts: send e-mail to [log in to unmask]: SET Technet Digest
Search the archives of previous posts at: http://listserv.ipc.org/archives
Please visit IPC web site http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for additional information, or contact Keach Sasamori at [log in to unmask] or 847-615-7100 ext.2815
-----------------------------------------------------