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
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:
Some examples:
Some Examples:
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