I am a product development engineer working with this company and found something interesting: once I developed a product and it's in production, any sustaining engineer can change the drawings/parts without my knowledge. I am just wondering if this is also the case in your company or if this is considered as normal? Then why I have to go through all the design review process and sustaining engineers don't have to? Any ISO code says you can't do this? Thanks!
Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
Can sustaining engineers change production drawings without product development engineers' knowledge 2
- Thread starter ThinCap
- Start date
Sounds like a sideshow, not an engineering office following standard lean/agile design philosophy. Regardless of where a product is in the lifecycle, changes need thorough testing and peer review. A change during production should be treated just the same as an iterative change made during initial development.
If a product or part isn't per-print then the supplier is legally responsible for all "reasonable" costs due to its failure. Ultimately its a legal decision, their lawyer will say your employer should've inspected their part/product/process quality better and your company's will point back to the part not meeting some detail of the print. If there's any ambiguity in the print then your employer will likely lose. Similarly, if you called out a specific part instead of a spec or standard then again - you lose due to ambiguity.
If you have to ask this question then you're either in the wrong company or profession. Engineering is peer-reviewed to ensure quality among other concerns. Anybody looking to point fingers should be pointing to multiple experienced engineers, with more brought in for more-complex or higher-risk project reviews.....which generally means more documentation and testing, and is why finger pointing doesn't really happen.
If a product or part isn't per-print then the supplier is legally responsible for all "reasonable" costs due to its failure. Ultimately its a legal decision, their lawyer will say your employer should've inspected their part/product/process quality better and your company's will point back to the part not meeting some detail of the print. If there's any ambiguity in the print then your employer will likely lose. Similarly, if you called out a specific part instead of a spec or standard then again - you lose due to ambiguity.
If you have to ask this question then you're either in the wrong company or profession. Engineering is peer-reviewed to ensure quality among other concerns. Anybody looking to point fingers should be pointing to multiple experienced engineers, with more brought in for more-complex or higher-risk project reviews.....which generally means more documentation and testing, and is why finger pointing doesn't really happen.
- Thread starter
- #22
90 days to 1 year is a good idea. There shouldn't be any more surprises after that. But still any significant change afterwards should go back to the drawing board, which is the new product development. Otherwise, sustaining can make a new product based on the old one all by themselves!
- Thread starter
- #23
@CWB1: well, the whole purpose of documentation/tractability is for finger pointing. Otherwise, if it's a success mission, everybody will point the fingers to themselves...
Not only government can dictate who makes the part (sole source), they can dictate where that part is made too. The reason made in China could be even illegal with government funding.
Not only government can dictate who makes the part (sole source), they can dictate where that part is made too. The reason made in China could be even illegal with government funding.
No, the purpose of documentation and traceability is to be able to quickly/easily locate sources of error and efficiently resolve issues. In this case the documentation/traceability should point back to flaw(s) in your incoming inspection process(es), which should be a process that is reviewed & re-approved at least annually by senior management and a few select technical experts.
Private industry uses single-safe-source suppliers regularly too, but that should be controlled through purchasing and quality systems, not via engineering systems or documents. Just like the govt, we also commonly go as far as sending engineers into supplier plants to nitpick manufacturing and quality processes as is expected and normal. None of that changes the fact that calling out supplier p/ns on a print is considered lousy practice for critical parts.
It is rather ironic btw that you mention finger-pointing and govt work in the same breath. IME those two go together almost exclusively, along with a culture often lacking professionalism and competence.
-
2
- #25
Documentation is so that you know what you are actually doing, as opposed to what someone thought they might doing 20 years ago. Lack of documentation is a violation of ISO guidelines and makes it impossible to do process control or process improvement. If you think you don't need documentation, you ought to find another job.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
- Thread starter
- #26
Just give me one example anybody ever tried to use documentation/traceability to find who is responsible for a success mission.
Also this is actually the topic of this thread: if sustaining engineer can change documentation (drawings) without design engineer's knowledge, then what is the purpose of this documentation (drawings)? Show it off to ISO inspectors only?
Also this is actually the topic of this thread: if sustaining engineer can change documentation (drawings) without design engineer's knowledge, then what is the purpose of this documentation (drawings)? Show it off to ISO inspectors only?
I get called with questions about past projects regularly because my name is on various design review presentations, print revisions, and other documentation. Management knows what I do/did because bottom line - they assigned me the work, I reviewed the work regularly with them for approval, and ultimately they wrote my annual personnel reviews based on that work. If they don't recall who did something, there's documentation. If anybody else wonders who did something, there's documentation.
They aren't really "changing" documentation, they are creating new, updated documentation to add to the existing pile from product engineering. Anybody should be able to go trace print revisions and other documents backward in time to see design logic, hence why its "traceability."
They aren't really "changing" documentation, they are creating new, updated documentation to add to the existing pile from product engineering. Anybody should be able to go trace print revisions and other documents backward in time to see design logic, hence why its "traceability."
We use documentation all the time, particularly when it comes to re-using products that were a "success." Moreover, in support engineering it is imperative that you know exactly what the customer's product is, and how it was configured.
If the sustaining engineer is documenting an actual product change, then what is the issue? Would you rather that they make changes and NOT document? Do you want a product being delivered to customer where you have no idea what the configuration is? Again, there are Class Two changes that do not affect form, fit, or function, which the production process should be able make without running back to the design engineer to assuage his feelings.
If this is so bothersome, then you should advocate for a process that ensures that ANY changes made after product verification is documented and validated for compliance to requirements, regardless of whether the design engineer is involved.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
If the sustaining engineer is documenting an actual product change, then what is the issue? Would you rather that they make changes and NOT document? Do you want a product being delivered to customer where you have no idea what the configuration is? Again, there are Class Two changes that do not affect form, fit, or function, which the production process should be able make without running back to the design engineer to assuage his feelings.
If this is so bothersome, then you should advocate for a process that ensures that ANY changes made after product verification is documented and validated for compliance to requirements, regardless of whether the design engineer is involved.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
- Thread starter
- #29
That's a process problem, as I suggested; either you train your sustaining engineers or your process forces them to do the analysis. The fact that they can replace space qualified parts with non-space qualified parts is actually YOUR problem, since your Bill of Materials (BOM) is not sufficiently specific. If your BOM specifies Class S, then no one can, or should, change to a non Class S, unless you have no process for allowing changes.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
Another lack of process
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
- Thread starter
- #33
Didn't I already say/imply in my very first posting it's process/system problem? Or if it's considered as normal in your companies? Most of you believe it's normal until the last couple of days...
As why sustaining engineers know nothing of the parts they are inheriting? Well, because they are not trained that way.
As why sustaining engineers know nothing of the parts they are inheriting? Well, because they are not trained that way.
No, we told you that a process was needed in my first response. And you still have not say whether you even have a process; if you have no process, then there is no failure, is there?
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
- Thread starter
- #35
I still don't see an issue so long as the changes aren't Class 1 changes. After all, you could leave the company tomorrow, and they would have to carry on without you.
Did you specify the parts to be space-qualified? If not, then that's on you.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
Did you specify the parts to be space-qualified? If not, then that's on you.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
- Thread starter
- #37
Space hardware is Class S. Class 1 refers to form/fit/function changes, while Class 2 refers non-consequential changes.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
- Thread starter
- #39
truckandbus
Automotive
You could always insert yourself as part of the change request process or as part of the change review process.
If that isn't feasible you could get a copy of upcoming engineering releases - better finding out later than never.
As part of your production release you could familiarize the sustaining team with your design intent and highlight the critical elements of the design. Wouldn't be a bad idea to include the service team as well.
If that isn't feasible you could get a copy of upcoming engineering releases - better finding out later than never.
As part of your production release you could familiarize the sustaining team with your design intent and highlight the critical elements of the design. Wouldn't be a bad idea to include the service team as well.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question
