Production Revision Lettering Method

[ET50]

I'm aware of the standards of revision control, however I have a question as a result of a new company policy. I asked this in the document control area as well but I think this is a more appropriate place to ask this.

First our old revision policy was to start with A at the initial Production Release and then increment up (B,C,D..). This is normal as I see it. The new policy they want to employ would start with A as the initioal Production Release as before. Where it differs is they want to incorporate alfa numeric revisions within the Alfa system. An example would be if say the current revision is B and they discover a typo.They want change the revision to B1 at that point and release it. Now say the same drawing has another insignifact error in the notes or is missing a reference dimension. They would say this is another minor revision and change the revision to B2 and release it again.If the drawing has a major error they would then up the revision to C and release it again. In summarry the revisions would be A,B,B1,B2,and then C.

My opinion is that once a production drawing is released no matter how small the change (ie spelling error) you should continue to up the revision through the Alfa sequence. To mix and match Alfa and Alfa Numeric revisions doesn't make any sense to me. Am I wrong and not seeing the big picture. In all my xperience (over 40 years) I'venever seen this done.

 

[hydtools]

My choice would be to correct the minor errors on the next major change. Perhaps, a better use of time rather than break down the revision levels to sub-levels.

Ted

 

[fcsuper]

Major (Full) and minor (non-content) revisions are common practice, just as you described. The important thing is to make a very clear definition of what non-content changes are. They are literally only typo corrections and format adjustments (moving notes around, but not changing what they are pointing to; or moving a table from the top to the bottom of the drawing). The problem is that there will always be someone who believes they have the right to redefine the rules to include content changes in minor revisions. "I'm just changing the units of measure" or "I'm just moving increasing the tolerance for the hole, I'm not moving it". "This is an emergency! We need this change done as quickly has possible. We have to use minor revision even though I know we are really completely redesigning the part and need a new part number." It is a slippery slope that needs policing.

I've found that vendors don't like minor revisions, because each time you change the drawing, they have to treat it as a new revision. Your definitions for major and minor revisions have no meaning to their processes.

And, of course, when an engineer says "I didn't change anything", but they still insist on rev'ving the drawing, you should always be very suspicious. I have found that "I didn't change anything" usually means, "I've completely redesigned this part, but as long as no one is paying attention, no one will notice until long after the revision has been implemented (when it's too late for anyone to stop me from what I want to do)." I don't want to overstate my claim, but I have prevented documentation nightmares by caughting individuals in the process of trying to pull fast ones on the system.


Matt Lorono, CSWP
Product Definition Specialist, DS SolidWorks Corp
Personal sites:
Lorono's SolidWorks Resources & SolidWorks Legion

 

[EngineerErrant]

My company uses the mixed-rev scheme. It makes a lot of sense for us, as we do a lot of custom work for architectual design firms that love to redline things to high hell, without actually changing our design. ("Add a note about installation here. Add phantom lines for all surrounding structures here. Add a dissertation analyzing what part, if any, the works of Immanuel Kant played in the collapse of Soviet Russia, and the philosophical implications thereof.") Secondary revisions let our customers feel like they're not being ignored, while safely letting our production team know what "changes" they can ignore.

As with every documentation strategy, context is everything. It makes sense for what I do, but I wouldn't expect it to make sense for everybody.

"Engineers like to solve problems. If there are no problems handily available, they will create their own problems." -Scott Adams