Engineers often like to use "best practices" (data, information, knowledge, wisdom) during product development. Some of the data/information come from their experiences working on the job. Others (best practices) are derived from analytical, functional, logical or physical phenomena.
Dear Prasad,
It is an great and wonderful question...
Most of the product design do not consider the following in Initial Stage of the Design, resulting in product quality issues.
1. Design For Abuse - An example I take in my workshop and classes is the 'Hand Rest' designed in Chair of the Plane / Rail Car... Most of the time even in International flight, I have seen (including me) people shorter in height climb on the chair and then on the handle to dump the cabin baggage in over head career... If the product designer does not consider this abuse, design hand rest with all wisdom of loads for hand rest and safety factor, then it will result in product failures.
2. Unspoken Needs of Customer - The famous KANO Model explains Un-Spoken, Spoken and delightment needs of the customer in any product. Designers normally address spoken needs which is explicit, unspoken needs by comparing benchmark and competitor
These two elements are mostly missed and are very impactful in product development. I can confidently say this with my multi product experiences in my career.
Kindest Regards
Ramanan
I am not sure why heuristics are required in product design. Fortunately product design is now a very well established procedure with the best practices that are identified for various stages of product design. That is how we teach our students with proper tools to combine the information collected from the customer requirements to translate into a design. Some of the best practices are:
Specification development using QFD
Use of Kano’s model
Functional decomposition
Concept mapping
TRIZ
DFM, DFA, DFX, DFR, DFE, etc.
Hello,
our research team has experiences from industry cases. Most successful cases are when the workshops are facilitated. We use cause-effect mapping capturing the most important product parameters and how they interact.These are connected to customer needs.
The engineering knowledge changes from tacit to explicit in these sessions also. This enables the company to validate the design reasoning for their products. Then the company has better ability to manage the design and the properties of the artefact i.e. the product.
Ramanan, Nageswara Rao Posinasetti and Tero Juuti:
Due to complex interdependencies between subsystems, components and their parts that exist in a product today, changes are very difficult to predict.
"What ifs" need to be answered recursively throughout a supply-chain cycle? Product and Process tree structures, knowledge and experience of the engineers, together with manufacturing best practices, legislation, costing and other rules must be leveraged across the work-groups and reused.
The product and process knowledge or rules should be applied and executed during any design development process to accelerate the product development process.
All those best practices, you mentioned like Specification development using QFD
Use of Kano’s model, Functional decomposition, Concept mapping, TRIZ, DFM, DFA, DFX, DFR, DFE, etc. require heuristics, which can be formulated in the rule-form or in terms of what-if evaluations to speed up the product realization process. Those need to be applied if necessary. But applications of those best practices take time and resources. How to get to the end-product solution faster and quicker is the real question?
Take a look at this web link:
http://www.KnowledgeSol.com/
Let us know how have you achieved the time-compression during a typical & complex product design & development process?
Thanks!!!
The stated objective is getting to a design solution quicker. In general, I think that good tools exist for an engineer to design; many have been named. The main issue in obtaining a design solution quicker is to solve the problem of design refinement during collaboration. A lone designer working on a small product usually does not have difficulty to converge to a solution quickly. Also, existing design and communication tools support engineering in the small reasonably well (20-50 people collocated). What is still problematic is engineering in the large, for example, aircraft development with 40-50 tier 1 suppliers and 50+ tier 2-4 suppliers where many are collaborating on designs. In such a development environment, there are the order of 100,000 documents which are exchanged between the OEM and tier 1 suppliers. There are probably 2-3 times that many documents exchanged when all the suppliers at the different tiers are considered. There are almost no tools to track documents on this scale and to facilitate multi-party collaboration. Most companies have created their own ad hoc tools that help them coordinate the design refinement process on some scale. In this environment, engineers waste about 60% of their time in meetings, rework, etc.
My research has attempted to look at some of these issues. If of interest, see
Thomson, J. and Thomson, V. 2013. Using Boundary Management for More Effective Product Development. Technology Innovation Management Review. October 2013: 22–27.
Thompson:
Is your article listed on ResearchGate or on any web site? Can you add a link to the article you have refereed in here?
- Badges
- Science topic