4

In my company, we distinguish prototype from production prints by numbered vs. lettered revisions in the title block, and numbered revisions don't require an ECN in the title block. This allows us to efficiently track prototype revisions during the engineering phase and then maintain tight control on revisions during production. I think this is a very common practice.

However, when moving from one lettered Rev to the next, there must be a way to test out the new rev before finally releasing it. If I produce a part (say, circuit boards), I have to release a print to my circuit board vendor. The part is already at Rev A, so I can't do a numbered release. So now I have to release at Rev B - but now production sees a Rev B print in the system. I would rather production continues to see only Rev A until engineering is done testing Rev B.

Additionally, it is standard practice for us to print the part number and rev on circuit boards. So if the board says "Part Number-Rev B", production knows that lettered revs are good to use in their assemblies. So now a danger exists that if any of these parts make into a production bin, before testing is complete (or if the parts turn out to not work properly) there is no control to stop production from using them. If, on the other hand, they have a numbered rev, production knows not to use them except for engineering specified builds.

What is a recommended best practice for identifying prototype parts that are post-production release?

Note: Our assemblies are small, so we don't have room for a bunch of red tags, printed notes, emblems, or other things like that.

I can't find appropriate tags for this post - am I posting in the wrong community?

rothloup
  • 149
  • 4

4 Answers4

2

When I worked at an (in theory) ISO shop, we did the same thing as the OP, and in-development designs were uncontrolled and informally and inconsistently versioned.

A recent question here (talking about docs rather than parts) had an answer that described formally keeping distinct Rev and Draft codes.

Many people including me do this informally anyway, like

123456.A (released) 123456.A2 , 123456.A3 etc (in-development)

or

123456.X.20210611.1 , where the suffix is a sortable date code, with a possible sub-date in case of more than one draft per day.

and it can be formalized by keeping a rev and draft as part of the structure of the part number or part identifier.

I am experimenting with this at the small company level too and I would be very curious to hear other experiences on this!

Another issue that may arise is in case multiple parallel draft-edits are made by different people or groups based on the same released doc. In this case there would be draft-naming conflicts (corresponding to the change-merge issues that would also arise when the second ECN is processed). I haven't seen this resolved without human oversight, although a "checkout" process could be used.

Pete W
  • 1,367
  • 1
  • 4
  • 11
1

We (ISO 9001 and 13485 certified) have a 'version number' after the revision number at all times, so you would go:

NUMBER-A-00 : production release

NUMBER-A-01 : prototype draft with changes on top of RevA

NUMBER-A-02 : Self explanatory

NUMBER-B-00 : Updated production release.

Only parts with an -00 on the end should ever be used for production, so it is easy to see if a prototype part has 'fallen into' a production bin

Jonathan R Swift
  • 7,727
  • 1
  • 14
  • 27
  • 1
    Out of curiosity how do you control the last element (-01 etc)? – Pete W Jun 12 '21 at 13:29
  • 2
    There is no formal control process on the last element - you can increase the number whenever you want. If you are going to have a design review where you are referring to a version in the minutes, you should up the version number before the meeting, and then refer to the 'fixed point' that is the version before - so anyone can find the old one in the archive and know exactly what you were looking at. – Jonathan R Swift Jun 12 '21 at 13:41
  • 1
    This same process works for pre-production. We would increment the "revision" (and reset the version to -00) if at a milestone e.g. sending a pack out for initial quotation etc., But it then immediately gets up-versioned to -01 as the 'working copy' on the system. – Jonathan R Swift Jun 12 '21 at 13:43
  • 1
    Thanks. I saw that in another answer you posted and am trying to get it standardized in our docs process where I now work, which is slowly being solidified into a more mature form. Although it's not an issue at this company's size, this question made also me wonder about naming drafts to also reflect parallel WIP changes. In the previous company where we had to merge parallel changes, we checked out proposed-ECO numbers (pretty painless). Thinking out loud, that code could be a prefix to the draft, get concurrent draft revs unique and ordered... but the p/n's or docID's would get kindof long – Pete W Jun 12 '21 at 13:57
  • 1
    Parallel WIP is not something that happens with SolidWorks files, and it's easy to make collaborative edits on a single draft file using SharePoint or similar for office docs. This covers our use cases. I know parallel WIP is much more common with coding projects - so you may find some insight from someone who works on software? – Jonathan R Swift Jun 12 '21 at 16:49
  • 1
    yep. software uses a checkout process. I've seen "PLM" addons to mechanical cad that have that, but in this case am looking for something more general and lightweight and not bound to any software to implement it – Pete W Jun 13 '21 at 14:36
0

Seems like the safest solution in your situation would be to create new R&D part numbers for parts between rev A and B. You should also have proper document/BOM control in place to prevent unreleased parts from being able to be used for final products, and to also prevent older rev parts from being used.

jko
  • 2,347
  • 3
  • 13
0

You need to not have the same "system" to hold both in-development and in-production revisions.

A new revision is designed and tested and is then rolled into production. Only when the revision is approved should it be available to the production department. Allowing the production department to have access to the not yet tested rev is a disaster waiting to happen. This is how software development works and is fairly standard.

Tiger Guy
  • 5,369
  • 6
  • 17