 |
 |
 |
| |
|
|
DI:13.1 OVERVIEW
Ȧã§ãX§ã####################### Rework and summary required in this section
Concurrent engineering is a common sense approach to product design.
Originally (hundreds of years ago) the designer was also the person who produced the design. So during the design phase they considered production problems.
As designs, and manufacturing methods became more complex, it became necessary to break down design and manufacture to more specific tasks.
These areas of specialization caused different functions to arise in an enterprise. So it became common for the designer to have little, or nothing to do with production.
For many years designs tended to be thrown over-the-wall. This was effective in big companies, but some problems arose as a result,
But, now with the aid of computers, and other information tools, we are able to close the gap between the designer, and production. Hence, concurrent engineering.
Reasons for using the traditional design methods,
- Product development is traditionally its own organization and is physically and organizationally isolated.
- Process development and production operations are located together in a different organization labeled manufacturing.
Problems with current design methods,
- The design is driven by scheduled deliverable data items. There is pressure for drawings and specifications, which leads to a depth-first design search. Design alternatives are quickly eliminated in the interest of time, and one particular idea is pursued.
- The definition of design detail is costly in labor hours. Even with CAD/CAM tools, much manual effort is needed. It would be better to delay this task until the design is somewhat optimized.
- The design process is characterized by a rigid sequence of design decisions. The ultimate goal is usually lower cost, when the goals should include optimal performance and ease of manufacture.
- Producability and supportability issues are not considered until relatively late in the process, when a design change may be very costly.
- Production planning, support analysis, maintenance, and reliability are considered separately from the design process. The designers are left on their own to select the particular set of utilities considered in the first design iteration.
- Design data is fragmented. Documentation includes CAD files, dimensioned component drawings, sketches, process drawings, 3-D solid models, etc. It is difficult, if not impossible to maintain consistency at all times across these representations.
- Information is lost as the design progresses. The design intent may be lost by the time the documentation gets to the producability experts. They then must rely on experience and luck in guessing what changes can be made to make the item producible and also functional. Ideally, the reasons for the design features would be included in the design documentation.
- Designers are usually not aware of cost information, so they cannot intelligently set cost reduction as a realistic goal. Companies do not release cost information routinely. There are no tools for estimating costs as there are for other design domains, and when the costs are calculated, it is often too late to make major design changes.
Some of the goals of concurrent engineering are,
- Avoiding component features that are unnecessarily expensive to produce. This often happens because when a decision is made about a manufacturing feature, there is often a lack of information about the effect of the decision.
Concurrent Engineering means that during design, we consider more than just the design, we also consider how to make it, how to package it, and all of the other functions that were previously left-for-later.
The development of Concurrent engineering can be traced to 1979 Xerox, HP & Ford look at design practices, and foreign competition. Many small developments since then.
Important tasks for a concurrent engineering team are,
1. Define the design concept as behavior - The design team must define exactly how a product must perform, and rank the options. This will tend to focus the multidisciplinary team.
2. Define error recovery procedures - In effect the team must now define the challenges which the product will face. For example, if we are designing a transmission, what are the possible failure modes the transmission may face, or stacking for shipping.
3. Define how components interact - As components are defined, and detailed, their interdependence must be considered. At this stage the power of the multidisciplinary team becomes important. If all team members participate, most problems can be eliminated before they become problems.
| |
|
|