【转帖】notes on drawings not being read

yang686526

notes on drawings not being read
had the manufacturing engineering manager up here today saying that people aren鈥檛 reading the notes on drawings, especially assembly drawings.  primarily shop floor but also other engineers etc.
apparently, just training them to do so isn鈥檛 an acceptable solution.  so i鈥檓 meant to come up with some kind of policy to make the 鈥榬elevant鈥?or 鈥榠mportant鈥?ones stick out/easier to read.  (in my opinion if it鈥檚 not relevant/important it shouldn鈥檛 be there but my definition of important doesn鈥檛 match some others.)
specifically notes that relate to assembly requirements or notes referencing procedures that need to be followed during assembly are getting missed.  a lot of the manufacturing personnel have english as a second language.
we have a template of about 20 鈥榮tandard notes鈥?that are meant to be deleted/modified/added to to suit the needs of the individual drawing.  the first few are references to 14.100, 14.5 etc which end up on pretty much all drawings.  after that comes things like roughness note, different finishes, different part id options, different cleanliness etc.
part of the problem is that people aren鈥檛 deleting all the non relevant notes so the notes are longer than needed.  however, even on drawings with relatively few notes things are getting missed.
i鈥檝e looked at asme y14.100-2004 section 4.26 but nothing stands out.
a couple of ideas i鈥檓 thinking of are:
1.  move the notes referencing the asme standards & what units are being used that go on every drawing to the title block or border.
2.  break the notes into 2 sections on assy drawings, the first being general notes the second being 鈥楢ssembly requirements鈥?or something like that.
any suggestions?  any of you had similar issues.
(please note we鈥檙e (starting to be) careful not to put processes/assembly instructions on the drawings iaw the asme specs, complex assemblies get separate work instructions.)
kenat, probably the least qualified checker you'll ever meet...
i like your two ideas, but would suggest different titles.  something like:
"notes you can ignore, but that the customer will read and make us scrap or rework parts."
and
"read this!"
fortunately (or not) we're our own customer for the actual drawings.  however when the tool doesn't work because no one programmed the camera, then the customer complains.
kenat, probably the least qualified checker you'll ever meet...
we create assembly procedures that are called out on the assembly drawing.  it appears to from this distance to be a lack of training and follow up.  does your company hold iso certification?
heckler
sr. mechanical engineer
swx 2007 sp 3.0 & pro/e 2001
xp pro sp2.0 p4 3.6 ghz, 1gb ram
nvidia quadro fx 1400
      o
  _`\(,_
(_)/ (_)
"first they ignore you, then they ridicule you, then they fight you, then you win." - mahatma gandhi
suggestions:
first, i would suggest training the engineers and approvers to only use the notes necessary for the drawing (and/or change how notes are generated to require each applicable note to be added instead of requiring editing of some sort after the fact, perhaps using lenny's commonnotes macro -- if these drawings are solidworks format).   i'd also say that if inapplicable notes (for example, general surface finish) are showing up on an assembly drawing, the drawing shouldn't have been approved in the first place.
i believe your first suggestion is also a good second step.  move the standards notes to the title block to reduce the clutter.  filling in n/a's or dashes in the couple extra blank fields may add a little more work though, but likely still less than editing notes themselves.  oddly enough, i'm currently working on a new title block for my company that does just this.  
i think your second suggestion is ok, but not a preference of mine.  another solution is to create assembly procedures.  this provides a segregated list of steps, and may allow more freedom with how the steps are described. depending on your system, changes to this document may not necessarily require changes to the drawing, so there is the opportunity for more freedom in that respect as well.  however, i don't like to be the guy that has to write those procedures. lol
matt
cad engineer/ecn analyst
silicon valley, ca
i have always tried to list notes in order of assy or fab. process note stay off.
if a note is to move to another line or deleted, it is removed from the old line and replace by "removed", then written on a new line. if space is limited, the notes can be moved to a second sheet.
chris
solidworks 07 4.0/pdmworks 07
autocad 06
this may seem radical, but you'll have to do it if you implement jit.  if your stuff is that difficult or unobvious to assemble, you might be better off with jit anyway.
take the manufacturing information off the design drawings.
jit doesn't have assembly drawings.  instead, it has detailed, step by step, station by station, illustrated manufacturing instructions.  
it wouldn't be a huge step to make them language- independent, i.e., totally visual, or to make them in two parts:  a visual part, and a text part.  the text part could be translated into whatever language is required for the individual worker.
generating the first set is a huge effort, but there's a hidden gift.  they are maintained by someone else; the manufacturing engineers, right on the factory floor.  that eliminates manufacturing documentation as a headache for you, and it eliminates design department inertia as a headache for the manufacturing engineers.  everybody wins.
mike halloran
pembroke pines, fl, usa
well thanks for the input everyone, i felt kind of stupid asking the question but i鈥檓 tired of doing what seems reasonable then finding out later that it either contravenes the asme standards that we invoke or that it鈥檚 a pain to do.
forgot to explicitly state that because historically design documentation has been awful here we鈥檙e trying to implement asme y14.100 series fairly strictly.  once we鈥檝e got people generally following the standards we may become a bit more liberal with our interpretation/enforcement when there鈥檚 a compelling case but at the moment if we introduce shades of gray it seems we鈥檒l be back to square one.
in answer to some of your points:
heckler:
historically we had a mix of:
1.  some assemblies with a drawing that was half drawing half assembly instructions (basically didn鈥檛 give enough detail to be used to check it had been assembled correctly/detail final item as a drawing but didn鈥檛鈥?give full unambiguous assembly instructions either) which contravenes asme standards.
2.  other assemblies, especially mid size ones had a bill of material and some kind of assembly/work instruction based on photos of the tool being built and no drawing.  sadly a lot of the assembly procedures weren鈥檛 very good and didn鈥檛 give you anything to work to when you had to install new equipment etc.
3.  finally many assemblies just had a bom and nothing else.  again these were pain to work with when incorporating changes at the assembly level.
we are now standardizing on the drawing being the defining document except for the very top level of our complex tools.  for more complex assemblies a separate work instruction is created as well.  only if how the assembly is done affects the performance of the end product is the work instruction usually referenced on the drawing, otherwise it is only linked in the mrp system.  we are also now applying the 鈥淢aster model鈥?concept using 3d cad so we can create illustrations from this for many of the work instructions.
no we don鈥檛 hold iso 9001 (or whatever) certification.  in fact when my boss was hired to lead the efforts to improve design documentation/introduce industry standards one vp explicitly told him not to take us down the iso route.  my previous employer in uk was iso, i almost miss it.
fcsuper:  
i鈥檓 hoping that training will form part of the solution if i have the time i may even be proactive on the training for the engineers.  our drawing approval process is, or at least historically was, massively flawed/inadequate.  although we鈥檝e introduced a formal checking process it has no teeth (checker isn鈥檛 on eco approval board) and can鈥檛 stop drawings being released so some people circumvent it.  that said on drawings that come across my desk i鈥檓 pretty brutal with getting rid of unnecessary notes.
references to standards were in the format/title block at my last place, my bosses too so i鈥檓 looking at that option.
one concern with the second suggestion is how individuals decide which notes go in which section, but it would be easier to introduce
we鈥檝e already taken the step of starting to create separate assembly documents which has reduced the amount of notes (especially the process ones which contravene the spec).  apparently not enough though, the example the manf guy gave was one of my drawings with only 5 notes, the 4th of which referenced a procedure for down loading the correct software.  they missed this step.  
also i agree with the point about more freedom in work instructions, i鈥檝e pushed for this strongly.  
ctopher:
me too, although i just found y14.100 says at 4.26.6 that the order of notes has no meaning unless otherwise stated.  removing process notes is something we鈥檝e been doing and is part of the justification for separate work instructions.  they aren鈥檛 strict on tracking changes to notes here, and at this stage it鈥檚 not something i鈥檓 planning to cause a stink about.
mike:
i think this is what they were aiming at with some of their bom/work instruction combos but it didn鈥檛 work well/they didn鈥檛 do it well.  also as i mentioned eliminating assembly drawings doesn鈥檛 give much to work to when you have to modify the tool in future.  now that we have a full model it might be possible but i have my doubts.
we are taking manufacturing steps off the assembly drawings but still have the drawing to delineate the finished/assembled item as designed.
my last place did jit for high rate of production items but they still had assembly drawings.  however most of the work on the floor was done to simple routings or even placards at each station with minimal verbage.
as mentioned we are creating work instructions for all but the simplest of assemblies.  yes it is an effort.  you鈥檇 think that was what manufacturing engineers would do but here they are far to busy making drawing and design changes so design gets to make and to some extent maintain the work instructions.
we trialled a software called interactive product animator last year which helps create interactive assembly instructions in a web site format based on animations of the model.  it鈥檚 pretty cool and the couple we sent down to the shop floor were well received but nothing else has happened on it in the last year.
thanks again everyone, appreciate the input.  sorry this post was so long, i know it means most of it wont get read.  must learn to be less verbose.
kenat, probably the least qualified checker you'll ever meet...
kenat,
quote:
... the order of notes has no meaning unless otherwise stated
i agree. it's just a personal preference to list them in order, at first. but, they do change during revision changes and is ok.
mike,
i agree about the jit. imo, i think all assy's should have jit's, and referenced on the dwg. the assy dwg should only have the minimum notes necessary to explain some steps. it is more pictorially vs text on a jit. they work together.
chris
solidworks 07 4.0/pdmworks 07
autocad 06
kenat,
it sounds like you have inherited a bit of a mess to clean up.  i try to work along the following hierarchy.
if it can be defined on how to make/assemble/test it on the drawing, do so.  it gives you a single document to work with and it is under eco control.
more complex parts/assemblies may require additional documentation, it could be in the form of build sheets, tooling lists, and work instructions.  we revision control these but they are not eco'd.
testing procedures are developed if performance criteria cannot be successfully/suitably defined on the drawing.  these are eco controlled as it directly relates to performance/traceability/safety etc.
regardless of what you come up with, what jumped out at me in your first post is the need for proper supervision and training.  these are not your problem and need to be addressed by others (hopefully they are aware of this).  no documentation method is going to solve the problem by itself.  people need to be trained in it's use and monitored to ensure work is being done correctly and problems identified.  documentation, training, and supervision all carry the same weight in terms of importance for achieving success.
regards,
thanks pse,
the protocol you describe is pretty much what we're trying to do, at least on new releases.
the training thing has come up before and i've offered to lead some of it if they assign me the time to prepare it, this hasn't happened.
the thing i don't get is at my last place i received minimal training but, they had a reasonable set of procedures which i was expected to familiarize my self with and follow.
when i started here we didnt' have that many procedures, at least not that bore any relevance to what happened.  however i asked around, looked at how other things had got done etc and worked out how most stuff went.  
we have since released some standards/procedures.  however, hardly anyone familiarizes themselves with them or works to them.  we had the qa director send a message around when they were released saying to follow them and at least some of the department directors also said they were to be followed.  several people have complained that they wont/dont want to read procedures etc.  (don't get me started on why there's no enforcement.)
so am i a freak in that i can happily teach myself from a written policy/procedure and don't complain about the time it takes me?
just realized this is off topic, sorry.
kenat, probably the least qualified checker you'll ever meet...