AnsweredAssumed Answered

Prototypes and ECNs

Question asked by Terry Raymond on Feb 7, 2019
Latest reply on Feb 8, 2019 by Daen Hendrickson

Like • Show 1 Like1
Comment • 12

Process question for other users who design 1-off products.

We design and manufacture large custom machinery, with order quantities typically 1; essentially everything is a prototype. We’re also ISO 9001 and API Q1, so we have to have strict process controls, meaning ECNs are required (to some extent). During builds, the typical unforeseen issues arise (component delivery/availability issues, tolerance issues, VORs, etc) and we have to adjust drawings and BOMs to keep up with the project. I’m sure this is typical for many users here.

My question for those in the same situation: Do you generate an ECN for every one of these incremental design changes that occurs during the build? Or do you have a more efficient way to get the “prototype” built, without your designers spending half their time doing ECNs, yet staying ISO/API compliant?

If you have an efficient process, I'd love to discuss offline if you're able.

Thanks in advance

Daen Hendrickson Feb 7, 2019 12:38 PM

Correct Answer

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

See the reply in context

No one else had this question

Outcomes

Cad Admin Feb 7, 2019 10:42 AM

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.

Actions

Frederick Law @ Cad Admin on Feb 7, 2019 10:48 AM

Exactly, you write the ISO procedure and follow it.

No ECN until customer approved the design.

Most of the time its a paper trail of who said what and who pay for the extra time and material.

Actions

Daen Hendrickson Feb 7, 2019 12:38 PM

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.

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".

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

I hope this gives you some ideas.

Daen

Actions

Terry Raymond @ Daen Hendrickson on Feb 7, 2019 2:05 PM

Daen,

Wow thanks very much for sharing all that. I like that + trick on the revision for cosmetic changes, I'll bring this up in our next process meeting. And your comments on balancing giving the shop leeway vs requiring designers drive everything is spot on; this is exactly what we are wrestling with. Understood you are of the opinion the extra ECN time, though not directly value added, pays for itself later in other ways.

And the comment on capturing as-builts made laugh, so true re no time. Some companies hire (cheap) contract drafters to capture all the as-built notes.

I ordered that book ($6!), thanks much for the reference.

Actions

Daen Hendrickson @ Terry Raymond on Feb 7, 2019 2:16 PM

The book goes well with LOTS of caffeine! A real "snoozefest" of a read. But good info.

Actions

Daen Hendrickson @ Daen Hendrickson on Feb 8, 2019 6:10 PM

And sometimes there are "Gray" areas. Uncanny timing that this should pop up right after I blathered on about our process...

I had an exploded view with balloons. With certain drawings I like to stack balloons with the leader attached to the main component of concern and the associated fasteners attached in the balloon stack. In this case I picked the wrong fastener to "add to stack".

Does this drive a revision bump or is it cosmetic?

The Assembly did not change.
The BOM Table did not change.
The Ballooned callout did change.

I finally decided the first two items far outweighed the last item and the last could be considered a spelling error of sorts. I decided this change did NOT warrant an ECN and Revision bump. The CAD model imported into our ERP generated the correct quantities. However, the build floor was following the balloons and grabbed the wrong fasteners. But the right type and quantity of fasteners were ordered and available (as long as the build folks restocked the incorrect fasteners instead of tossing them...)

So our system is far from ideal.

Actions

Paul Salvador Feb 7, 2019 12:43 PM

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.

Actions

Brad Meador Feb 7, 2019 2:06 PM

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.

Actions

Barry Watkins Feb 7, 2019 2:50 PM

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.

Actions

Terry Raymond @ Barry Watkins on Feb 8, 2019 10:54 AM

Barry thanks for this input. I think I am doing pretty much what you are saying:

All designed parts/assemblies/model files just get revision 0. That never changes.

Drawings start off as A1, A2, A3 (unreleased, marked PRELIMINARY), until released.

Initially released drawings get rev A. When this happens, PDFs are automatically generated and put into our ERP system for routers.

During the build, minor issues that pop up on the shop floor just get redlined paper/pdf prints. These are saved in PDM.

More complex changes get an ECN, where drawing is reved to B1, B2, etc until it is approved to rev B.

I like Daen's "+" note on the rev, I think I will add that to our redline process, which will also allow me to make cosmetic changes in Solidworks. I think I understand that you're one step further than the "+" annotation, in that you increment the number for every minor document change. Your method, if I understand you correctly, conflicts a bit with our preliminary review stage process... I need to chew on this a bit though as it does have value.

I'm still wrestling with how much leeway to give the shop. When they need to add little brackets, make plumbing run changes, etc, the time lost waiting for drawings and time spent creating new drawings can end up being significant.

Actions

Barry Watkins @ Terry Raymond on Feb 8, 2019 12:30 PM

Here are my suggestions. Increment your number for each change whether it's preliminary or not. Keep the preliminary stamp until the change is approved, then just remove the stamp. Call prototype revisions 0, issue 1, 2, 3, etc. Once it's ready for release after prototyping change the rev to A, issue 1. Increment the issue # for minor revisions to A after it's been released 2, 3, 4, etc. The next major change call rev B, issue 1, with the preliminary stamp showing until it's approved. If you want to increment the issue number for changes to B as 2, 3, etc. while it's still preliminary that's fine, just keep the issue # unchanged at whatever level it's at at the time of release. Say it's rev B, issue 3 that gets released. Just remove the "preliminary" stamp, keep the rev and issue # and you're good to go. Like I said, I would make the alpha rev level more prominent on the title block and make the Issue # a smaller font. This covers both uses for all changes in between revisions. Just my 2 cents worth. Sounds like you're on a good track.

Actions

Phil Johnston Feb 8, 2019 10:07 AM

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.

Actions

12 Replies

Cad Admin Feb 7, 2019 10:42 AM
Mark Correct
Correct Answer
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.
Like • Show 4 Likes4
Actions
- Frederick Law @ Cad Admin on Feb 7, 2019 10:48 AM
  Mark Correct
  Correct Answer
  Exactly, you write the ISO procedure and follow it.
  No ECN until customer approved the design.
  Most of the time its a paper trail of who said what and who pay for the extra time and material.
  Like • Show 4 Likes4
  Actions
Daen Hendrickson Feb 7, 2019 12:38 PM
Unmark Correct
Correct Answer
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
Like • Show 7 Likes7
Actions
- Terry Raymond @ Daen Hendrickson on Feb 7, 2019 2:05 PM
  Mark Correct
  Correct Answer
  Daen,
  Wow thanks very much for sharing all that. I like that + trick on the revision for cosmetic changes, I'll bring this up in our next process meeting. And your comments on balancing giving the shop leeway vs requiring designers drive everything is spot on; this is exactly what we are wrestling with. Understood you are of the opinion the extra ECN time, though not directly value added, pays for itself later in other ways.
  And the comment on capturing as-builts made laugh, so true re no time. Some companies hire (cheap) contract drafters to capture all the as-built notes.
  I ordered that book ($6!), thanks much for the reference.
  Like • Show 3 Likes3
  Actions
  - Daen Hendrickson @ Terry Raymond on Feb 7, 2019 2:16 PM
    Mark Correct
    Correct Answer
    The book goes well with LOTS of caffeine! A real "snoozefest" of a read. But good info.
    Like • Show 2 Likes2
    Actions
- Daen Hendrickson @ Daen Hendrickson on Feb 8, 2019 6:10 PM
  Mark Correct
  Correct Answer
  And sometimes there are "Gray" areas. Uncanny timing that this should pop up right after I blathered on about our process...
  
  I had an exploded view with balloons. With certain drawings I like to stack balloons with the leader attached to the main component of concern and the associated fasteners attached in the balloon stack. In this case I picked the wrong fastener to "add to stack".
  
  Does this drive a revision bump or is it cosmetic?
  The Assembly did not change.
  The BOM Table did not change.
  The Ballooned callout did change.
  
  I finally decided the first two items far outweighed the last item and the last could be considered a spelling error of sorts. I decided this change did NOT warrant an ECN and Revision bump. The CAD model imported into our ERP generated the correct quantities. However, the build floor was following the balloons and grabbed the wrong fasteners. But the right type and quantity of fasteners were ordered and available (as long as the build folks restocked the incorrect fasteners instead of tossing them...)
  
  So our system is far from ideal.
  Like • Show 0 Likes0
  Actions
Paul Salvador Feb 7, 2019 12:43 PM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
Brad Meador Feb 7, 2019 2:06 PM
Mark Correct
Correct Answer
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.
Like • Show 1 Like1
Actions
Barry Watkins Feb 7, 2019 2:50 PM
Mark Correct
Correct Answer
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.
Like • Show 1 Like1
Actions
- Terry Raymond @ Barry Watkins on Feb 8, 2019 10:54 AM
  Mark Correct
  Correct Answer
  Barry thanks for this input. I think I am doing pretty much what you are saying:
  All designed parts/assemblies/model files just get revision 0. That never changes.
  Drawings start off as A1, A2, A3 (unreleased, marked PRELIMINARY), until released.
  Initially released drawings get rev A. When this happens, PDFs are automatically generated and put into our ERP system for routers.
  During the build, minor issues that pop up on the shop floor just get redlined paper/pdf prints. These are saved in PDM.
  More complex changes get an ECN, where drawing is reved to B1, B2, etc until it is approved to rev B.
  
  I like Daen's "+" note on the rev, I think I will add that to our redline process, which will also allow me to make cosmetic changes in Solidworks. I think I understand that you're one step further than the "+" annotation, in that you increment the number for every minor document change. Your method, if I understand you correctly, conflicts a bit with our preliminary review stage process... I need to chew on this a bit though as it does have value.
  
  I'm still wrestling with how much leeway to give the shop. When they need to add little brackets, make plumbing run changes, etc, the time lost waiting for drawings and time spent creating new drawings can end up being significant.
  Like • Show 1 Like1
  Actions
  - Barry Watkins @ Terry Raymond on Feb 8, 2019 12:30 PM
    Mark Correct
    Correct Answer
    Here are my suggestions. Increment your number for each change whether it's preliminary or not. Keep the preliminary stamp until the change is approved, then just remove the stamp. Call prototype revisions 0, issue 1, 2, 3, etc. Once it's ready for release after prototyping change the rev to A, issue 1. Increment the issue # for minor revisions to A after it's been released 2, 3, 4, etc. The next major change call rev B, issue 1, with the preliminary stamp showing until it's approved. If you want to increment the issue number for changes to B as 2, 3, etc. while it's still preliminary that's fine, just keep the issue # unchanged at whatever level it's at at the time of release. Say it's rev B, issue 3 that gets released. Just remove the "preliminary" stamp, keep the rev and issue # and you're good to go. Like I said, I would make the alpha rev level more prominent on the title block and make the Issue # a smaller font. This covers both uses for all changes in between revisions. Just my 2 cents worth. Sounds like you're on a good track.
    Like • Show 1 Like1
    Actions
Phil Johnston Feb 8, 2019 10:07 AM
Mark Correct
Correct Answer
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.
Like • Show 1 Like1
Actions

Prototypes and ECNs

Outcomes

Related Content

Recommended Content