Documente Academic
Documente Profesional
Documente Cultură
221
8
Change Requests
221
222
Field Failures
Listen to your customers. React to their questions, complaints, reports,
feelings, and suggestions. Every communication from a customer should be
logged and followed to conclusion. Every communication should be divided
into its parts and every part followed to a conclusion (closed loop). Every
portion of a customer communication that pertains to the product, should be
sent to the responsible engineer for evaluation. Every customer letter should
be copied for each responsible engineer who might be affected. The
management must train people to do this, demand that it be done, and do it
themselves.
Rule:
Reason:
Change Requests
223
Production Problems
When the machinist or assembly operator believe that they have a
design problem or wish to request a change, there needs to be a simple
method of communicating to the Cognizant Engineer. This could be a simple
form to fill out. This form may be called a Request for Change, Engineering
Action Request, etc. An email containing the required information is
effective. Have the requests sent to CM. The change form should generally
not be used for reasons that will be discussed.
Rule:
Reason:
224
should be limited. Keep it simple. Prepare a form and form instruction that
indicates those blocks that must be completed by the requester.
Origination date
Control number
Change Requests
225
226
Change Requests
227
Avoid Temptation
Avoid the temptation to add more information than is shown. The more
information added, the higher the likelihood that you are trying to preprocess an actual change. This is a mistake that many companies make. They
228
Reason:
Rule:
Reason:
Change Requests
229
Realize that we are dealing with the design of the product. Therefore,
there is no reason for the Production Supervisor, Manufacturing Engineer,
Production Engineer, Industrial Engineer, or any one else (except CM) to get
between the requester and the Cognizant Engineer. These people can submit
a request of their own if they wish. If they are in the process they will delay,
edit, modify or change the original request.
230
Change Requests
231
232
Request List
Probably the most important element of a request process is the
creation of a request list. Whether the process is on line, hard copy, email
based, or whatever, a list of problems must be made and worked. The list
should be similar to the team action list mentioned in ch. 6 for new
development.
Headings for Action Items List
ECR Number
Origination date
This list can be used for the change request process as well as the
change control process. It must be very clear however as to whether or not
engineering has taken ownership of the problem. The requester must be
notified by some method that the request is now the responsibility of
engineering. The team should be involved in the request/list preferably
before engineering accepts or rejects a request. The team can often offer
very constructive advice that will sort out unproductive requests.
All forms of requests (other than the ECR) should probably also be
placed on this problems/challenges list. This gives design engineering a
complete things to do list on existing product.
Summary
If this chapter seems short to you, it is purposely so. The request
process begs for simplicity. It begs for separation from the change process.
When the change form is used there is usually confusion as to where the
engineering organization takes ownership of the problem. A list must be
made and followed to conclusion. Care must be taken to avoid the
compulsive urge to treat every request as though it were a change.