Prototypes and ECNs

Terry,

We generate build documents with a alpha revision.  During build, we apply ECN as needed, after completion of build and runoff, all ecn's and revisions are removed form the packages, and the customer receives a rev 0 released set.

Ive seen this done many ways...its basically what works for your company.

Terry,

We typically build quantity 4 to 10 of complex machines (flight simulators, 5K-8K unique parts, 18-24 months) so our approaches may have many similarities.

We are NOT ISO. We do have a methodology / procedure (at my insistence). Keeping people following it is the challenge.

We are still using SW2014 SP5 with PDMW. PDMWorkgroup allows for what is called the "Working Copy" revision. This basically adds a "+" to the current revision. Sort of an "in process" or "in between" revision. I have no idea if PDM Standard / Pro offer something similar.

Our process goes something like this:

• Engineering / CAD design work starts in a development life cycle. The engineer(s) can bump the development revision (numeric in our case) as much as they want to capture into the vault milestones, major design idea changes, etc. There are NO ECN requirements in development - it is the engineer's sand box.
• Before ANYTHING can "move off the desk" to be built (or quoted, or sent to an outside vendor) it has to be released (Alpha revisions in our case).
  • If the drawing doesn't have an Alpha revision you shouldn't be building anything from it
  • If you do build from it and your stuff doesn't match later, it is all on you.
  • On special-case occasions we do issue unreleased drawings for reference with a clear reminder to the receiver that the drawing is PRELIMINARY and likely will change (and with a giant "PRELIMINARY" watermark through the middle).
• Once released, changes require an ECN.
  • All Changes? No (very clear cut to me of what types drive an ECN. Just a convenient way to skip the ECN for others).
    Some examples:
    • Design Change (yes)
    • Dimension Change (yes)
    • BOM Change (yes)
    • Any change causing the revision to increment (yes)
  • For NON-ECN changes we use the "Working Copy" revision and add a plus "+" sign to the current Revision.
    Some Examples:
    • Correction of spelling error on a drawing note (no)
    • Correction of visibility issues with the model (phantom bend lines showing, for instance) (no)
    • Correction of a balloon's or drawing dimension's location on the page (no)
    • Adding a detailed view to help clarify existing information (no)
    • Anything that does not drive a change to the real item (no)

We do NOT issue an ECN to push a design from the development to the released state. Technically this should require an ECN since the revision is changing. Call it a streamlining compromise.

ECNs and their processes are always unpleasant. However, I've seen the mess caused by NOT using them. It becomes an issue of the "lesser of two evils".

I was "away" from the company for a few years. The ownership and other engineers don't really understand the ECN process - both the why and the how. They built a series of simulators all under the "development" state. Their thought process was that there would be a lot of changes and once they were all done they would just release the final drawings. There are two main problems with that: First, as changes were implemented "on the fly" no two of the machines were built quite the same and after-the-fact no one could quite remember just what changes were made to which machine, which changes got changed again, which build floor changes didn't make it back into CAD, etc. The second problem is the idea that there will somehow be plenty of TIME later to do what no one thinks they have time to do now. But there is NEVER that kind of time. Either the next project is behind before it even starts or there is NO next contract and they are letting people go.

The point of all that is to process your ECNs as they arise. Although unpleasant it is the better more efficient approach.

A book that I found great value in is "Engineering Documentation Control Handbook" by Frank B. Watts. It's content is dated (still aligned with drafters creating paper drawings) but the concepts and approach are well honed. Two key points I take from it are: Understand WHAT drives an ECN / Revision change and Simplify your ECN process to its bare essentials. If it is easy to do people are more likely to do it.

As soon as your quantities cross over that fuzzy line from Job-Shop to Production Run the above approach may not make sense. But for the low quantities we work in it has helped with my sanity retention.

I hope this gives you some ideas.

Daen

Hello Terry,.. for proto work (x1, x2,..)... on tight/fast schedules (get it out last month, chop-chop).. the only ECN I recall managing were for medical devices (FDA paper trails)..otherwise,.. and most of what I've worked on is non-critical so, only very/very basic liberal notes on changes were ever managed or carried over or released to the client or the cpm.   If notes were requested/needed.. we always preserved folders to send if needed.

We generate ECN's as the changes come.  We do mass production and ordering and sometimes having the ECNs being frequent puts purchasing back a week or two. 

I've worked at a couple of companies that have a similar situation. They have standard items, but lots of customizing so 90% of orders are one-offs. The best idea I've heard keeps the ECNs to a minimum, but documents the changes perfectly. Use PDM to track versions for changes. Set it up so that major revisions only happen on drawings (not models), but set up your titleblock to display both the alpha "Revision" level and a numeric "Issue #" on the drawing. Alpha rev changes can be only after prototyping is done, and then only for what you can define as major changes to the drawing. The prototype rev level can be "0" and then change to "-" once it's released. Minor drawing changes, also defined by you, don't increase the alpha rev level, but PDM automatically updates the numeric Issue #. The issue # can be smaller and less obvious than the rev letter on your title block. I think this is a great compromise solution so that rev levels don't change just for a spelling correction, for instance. You can also set up PDM to automatically generate a PDF with the alpha-numeric level displayed in the file name every time you change the drawing. ECNs can also be generated automatically with PDM and PDM can prompt the user to add comments to the revision or whether or not to generate an ECN. Just set up your guidelines and follow them. That's all ISO requires.

Daen's line here: "Before ANYTHING can "move off the desk" to be built (or quoted, or sent to an outside vendor) it has to be released (Alpha revisions in our case)."

This single "control" is critical. It can save HUGE headaches/costs later on.

I also agree with the rest of his comments and procedures. It allows for the simple, fast development stage, yet still captures necessary information at the right time.