IMPROVEMENT IN PRODUCT DEVELOPMENT: USE OF BACK-END DATA TO SUPPORT UPSTREAM EFFORTS OF ROBUST DESIGN METHODOLOGY

Quality Management (QM) has been applied, enhanced, an modernized in the past two decades (Porter and Parker, 1993; Dahlgaar d nd Dahlgaard, 2002; Dalrymple and Drew, 2000; Holmlund, 2007; Douglas a nd Judge Jr, 2001; Sousa and Voss, 2002; Kaynak, 2003; Gibson et al., 2003). In one of the many definitions, QM is seen as a management approach ch ara terized by principles, practices and tools, in which each principle is imp lemented through a set of practices, which are then supported by a number of tools (Dean Jr and Bowen, 1994). Customer focus and continuous improvement, a mongst others, have been mainly focused upon in terms of principles of QM (H ellsten and Klefsjö, 2000; Dean Jr and Bowen, 1994). In applying such an appro ach, in the effort of achieving high customer focus, for example, organiz tions have moved towards involving customers in product design decisions, i. e. the front-end of the product development process (Kim and Wilemon, 2002; Gruner and Homburg, 2000; Tollin, 2002). Quality Function Deployment is an ex ample of a tool which can be applied to design a product to meet spoken and unsp oken customer needs (Cristiano et al., 2000). Further, the principle of continuous improvement is commonly identified specifically with practices in manufacturing, such as process control. A lack of continuous improvement p ractices in product development has been identified (Nilsson-Witell et al., 2005). In order to emphasize the efforts of continuous improvement in product development, there is a need to focus not only at the front-end of pro duct development in terms of tools and knowledge, but also at the back-end, such as t e utilization of customer claims data to support continuous improvement.


INTRODUCTION
Quality Management (QM) has been applied, enhanced, and modernized in the past two decades (Porter and Parker, 1993;Dahlgaard and Dahlgaard, 2002;Dalrymple and Drew, 2000;Holmlund, 2007;Douglas and Judge Jr, 2001;Sousa and Voss, 2002;Kaynak, 2003;Gibson et al., 2003).In one of the many definitions, QM is seen as a management approach characterized by principles, practices and tools, in which each principle is implemented through a set of practices, which are then supported by a number of tools (Dean Jr and Bowen, 1994).Customer focus and continuous improvement, amongst others, have been mainly focused upon in terms of principles of QM (Hellsten and Klefsjö, 2000;Dean Jr and Bowen, 1994).In applying such an approach, in the effort of achieving high customer focus, for example, organizations have moved towards involving customers in product design decisions, i.e. the front-end of the product development process (Kim and Wilemon, 2002;Gruner and Homburg, 2000;Tollin, 2002).Quality Function Deployment is an example of a tool which can be applied to design a product to meet spoken and unspoken customer needs (Cristiano et al., 2000).Further, the principle of continuous improvement is commonly identified specifically with practices in manufacturing, such as process control.A lack of continuous improvement practices in product development has been identified (Nilsson-Witell et al., 2005).In order to emphasize the efforts of continuous improvement in product development, there is a need to focus not only at the front-end of product development in terms of tools and knowledge, but also at the back-end, such as the utilization of customer claims data to support continuous improvement.
Robust Design Methodology (RDM) is a key QM methodology applied at the front-end of the product development process (Fazl Mashhadi et al., 2012;Hasenkamp et al., 2009).The objective of RDM is to design a robust product which is minimally affected by sources of variation in various stages of the product cycle (Andersson, 1996;Goh, 2002).RDM is to be ideally applied throughout all stages of a product creation process, where insensitiveness to variations, or noise factors, are applied through systematic efforts (Arvidsson and Gremyr, 2008).A product creation process here indicates the typical stages of design, manufacture and usage (Hasenkamp et al., 2007).RDM has been widely perceived as a useful methodology during the product design stage (Park, 1996) in an attempt to create insensitivity to potential variations to be encountered at later stages of production and usage.A main challenge faced by designers and engineers in the design stage is imprecise or incomplete information on design requirements and constraints (Qin, 2000;Wang et al., 2002).These constraints may be linked to the presence of unknown noise factors affecting products during the use stage.Noise factors are parameters caused by any sources of variation that cannot be controlled (Phadke, 1989).
Adopting the same characterization as pertaining to QM (Dean Jr and Bowen, 1994), RDM may also be characterized by certain principles.Similarly, these principles are implemented through practices, which are then supported by a number of tools.Based on the three principles of RDM, Hasenkamp (2009) have identified a number of related tools and practices.More importantly, the authors have identified a lack of practices for one of the principles; continuous applicability.The continuous applicability principle in RDM aims at the application of systematic efforts to achieve insensitivity to noise factors at all stages of product design.
Although front-end focused RDM efforts present many benefits, there is an opportunity for improvement by use of back-end data.Noise factors encountered during the manufacturing stage are fairly convenient to identify by designers and engineers as these processes take place on the premises of the manufacturer.On the other hand, variations encountered during the product use stage are not as easy to identify (Wu and Meeker, 2002;Rai, 2009).This is where back-end data, such as customer claims and warranties, take a valuable stance.Such back-end data deserves emphasis in terms of its usability in RDM, to facilitate the identification of variations during product use stage.The proper utilization of back-end data, tied to an established practice, could serve as a learning platform in product development.Here, the back-end data is unique in its use for identification of noise factors during product use.
The purpose of this paper is to suggest practices for application of back-end data, such as customer claims, to support a front-end RDM approach.The results from claims data analyses are then used in product development in order to support continuous improvement in product development.This results in two outcomes.First, a new practice will be introduced addressing the lack of RDM practices to support continuous applicability through the use of back-end data.Second, by using back-end data as an upstream RDM effort, continuous improvement in the product development process is supported.This paper presents a case study at a medium-sized manufacturer in Sweden, where the practice of analyzing claims data has been tied to a Failure Mode and Effects Analysis (FMEA).The structure of the paper is as follows: The methodology of the case study is described in Section 2. Section 3 provides the theoretical background in the related areas.The results are presented in Section 4, followed by analysis in Section 5.The discussion is presented in Section 6 and the paper is concluded in Section 7.

METHODOLOGY
The empirical setting is a medium-size organization located in Sweden.The organization is a manufacturer of an internationally leading brand of components for trucks and heavy trailers.The author has collaborated with this organization in analyzing customer claims data and RDM practices.The single case study approach, although known to limit the generalizability of the outcome, comes with its own rationales (Yin, 2009).One such rationale is that this study be longitudinal in nature.A longitudinal, real time case study increases the internal validity of the study (Leonard-Barton, 1990).The collaboration with the company spanning over a year and a half was initiated by a study on claims data and RDM within a conceptual framework using historical data of customer claims.The use of the framework in the upstream efforts of the product development process is analyzed through this study by means of interviews, observations and an affinity exercise.
The case study involved several data collection methods (Yin, 2009).A total of six interviews were conducted, face-to-face, with a number of employees directly responsible or involved in the customer claims process, Project Management (PM), Quality and Environment (QA), and Technical, Operations, Research & Development (R&D), and Human Resource (HR), comprising managers and engineers.Each interview lasted between 45 to 90 minutes.All interviews were recorded and transcribed.Further clarification was done by e-mail and telephone, as and when needed.The questions were prepared in a semi-structured way, and contained open questions (Flick, 2009).The questions were prepared beforehand.The follow-up questions were formulated based on the responses received from interviewees.The information gathered during interviews was then supplemented by analyses of relevant documents made available by the interviewees.Those documents contain the detailed description of the flow of the organizational product update process, new product planning process, and claims database.
Observation and hands-on experience were gathered during an activity of defective product inspection.This activity took a total of two work days.The defective products inspected were returned by customers through a product exchange campaign.Different items were thus returned in different conditions, during which some were faulty due to misuse or an unexpected application environment.Others were just worn to varying degrees.A total of 85 units of coupling mechanisms were inspected and recorded.
Finally, an affinity diagram, one of the seven management tools, was applied in an exercise consisting of five participants as a method of compiling unstructured verbal information (Shahin et al., 2010;Scupin, 1997).A question was presented to those participating in this exercise: What are the major problems in using claims data for improvements?The exercise contained several rounds of idea presentation followed by a compilation of similar ideas into categories.This exercise was moderated by an external researcher, and was completed in three hours.

THEORETICAL BACKGROUND
QM is a management approach practiced by using various quality tools and techniques (Hellsten and Klefsjö, 2000;Tari and Sabater, 2004;Bamford and Greatbanks, 2005;Sousa et al., 2005;Yong and Wilkinson, 2002).In recent years, research on QM shows an increased focus on its practices, as opposed to its tools and techniques.QM practices are defined as the observable facet of QM, in which a single practice, for example, Process Management, can be supported by techniques such as Statistical Process Control in order to support the QM principle of Continuous Improvement (Sousa & Voss, 2002, p. 92).Recent studies have focused on QM practices and their relationships to organizational performance (Lu et al., 2011), customer satisfaction (Lenka et al., 2010), productivity and innovation ( de Oliveira Matias and Coelho, 2011), and project management (Bryde and Robinson, 2007).

Robust Design Methodology (RDM)
RDM practices have been widely emphasized on the front-end of the product development process in past years (Hasenkamp et al., 2009).In order to address the continuous applicability of RDM in all stages of product design, there is a need to identify practices related to the back-end of the product development process.RDM is described as an approach to reduce performance variation in products and processes (Andersson, 1996;Goh, 2002;Shoemaker et al., 1991).Manufacturing process variations are commonly identified, and at times understood, through the application of certain tools, for example process control charts (Bersimis et al., 2007).In understanding and addressing these variations, process improvements are put in place to increase performance.On the other hand, product performance variations are not easily visible.Many sources of variation exist in the daily application of products, such as environmental conditions, product utilization methods, user variations, etc.In order to acknowledge and understand such conditions, it is necessary to utilize field data (Rai and Singh, 2003).Customer claims databases constitute one such key access channel to field data.
Identification of noise factors affecting a system is crucial in RDM.Through that knowledge, settings of control factors that make the design of products insensitive to noise factors can be identified (Tsui, 1992).The sources which result in variations of product performance are traditionally categorized as: manufacturing imperfections (internal sources), environmental variables (external sources), and product deterioration (Johannesson et al., 2012).Manufacturing imperfections are seen in unit-to-unit variations of products due to manufacturing process variations.Examples of environmental variables are temperature conditions, dust, vibrations, etc. Product deterioration is seen in examples of wear and degradation of components over time during usage (Mekki, 2006).
Designing robust products is achievable through an understanding of the conditions during which products fail.Such conditions, or in some cases incidents, are most often referred to as noise factors.Back-end data such as customer claims is one way of identifying these conditions, or noise factors.Failures, when associated with noise factors affecting products, present an untapped opportunity to improve products.The application of back-end data based on RDM principles could, therefore, be supportive of improvements in product development.

Back-End Data in Product Development
In moving towards a customer-oriented business, many organizations have adopted various tools to understand customer needs, such as Quality Function Deployment (QFD) (Shen et al., 2000), customer surveys (Peterson and Wilson, 1992), focus groups (Kaulio, 1998) and product seminars (Cooper and Kleinschmidt, 1986).These tools are appropriate for handling data from the front-end of the product development stage.Front-end data, such as customer demographics and locations, for example, are used in order to gather information related to the needs and wants of customers before the development of products begins.In the opposite continuum of the development process is back-end data.The back-end of the product development process points to production data, as well as customer claims data from customers during the product use stage.Here, the back-end data focuses on customer claims.
Warranty claims data was defined (Blischke et al., 2011, p. 61) as data collected during the processing of claims and servicing of repairs under warranty, where data are obtained from the post-sale support system for data collection.There are various methods of data collection and data analysis applied in claims processing (Boersma et al., 2004).As an example, data collection may be done by a quality officer assigned this task in an organization, or an external agent, namely a distributor, or by service centers acting as middlemen.The claims data are then transferred into organizations and stored in a database.The stored claims data are normally grouped into categories relevant to the application of the data, such as (Blischke et al., 2011): • Product related (inclusive of product design): Mode of failure, failed component, age, usage at failure, etc. • Customer related: Operating mode, usage intensity, operating environment, maintenance, etc.
In both categories above, the specific details of the failures can be connected to noise factors caused by environmental variables and product deterioration as defined in RDM.In the instance of failed usage, the information points to a certain condition to which the product was subjected, which caused the failure.Such conditions are construed as noise factors.A broken leg of a coffee table could be due to the loading of a heavy object onto the table.The differing loads placed on the coffee table act as noise factors.An example of usage intensity is a rubber-band that breaks when it is stretched past its elasticity.The variation in the stretch is considered a noise factor affecting the rubber-band.Hence, failure modes are often connected to noise factors.
The views on claims data have moved from traditional to strategic.This is connected to the contribution of claims data analysis towards new product development (Wu, 2012).Information related to product failures can be extended to product reliability measures (Buddhakulsomsiri et al., 2006).Such information could be advantageous to the improvement of current products and operations (Attardi et al., 2005;Majeske et al., 1997).Such improvement could also be related to learning and transfer of knowledge in terms of improvements in product development projects (Antoni et al., 2005).Warranty claims data can be considered the voice of customers articulated at the back-end of a product cycle.These 'voices', when analyzed and interpreted, with the assistance of, and integration into, quality tools and methodologies, can be translated into product improvement ideas (Zhou et al., 2012).This presents an opportunity to create a proactive mechanism in order to react quickly to deviations in product performance through the implementation of a field feedback loop (Magniez et al., 2009).Such a mechanism could be designed based on the customer claims database to measure actual field reliability of products to generate valuable information to be fed back into the design process (Lawless, 1998;Meeker and Hamada, 1997;Meeker and Escobar, 2004;Thomas and Rao, 1999).
Customer claims analysis is also referred to as a feedback process in terms of customer dissatisfaction (Fundin and Bergman, 2003).The question remains how to utilize the feedback to improve the development of new products.In other words, how do we increase the satisfaction of customers by applying their own dissatisfaction feedback?The lack of a systematic approach in claims handling is identified as one of many challenges in the effective management of claims.
Other challenges include lack of appreciation towards customer claims and the inability to integrate feedback into an appropriate quality management methodology (Zairi, 2000).
An approach towards the systematic analysis of claims data would be to structure the flow of information from the back-end to early design phases in connection to a quality improvement tool, as shown in Figure 1.One such tool is FMEA, commonly used as an analytical tool to identify failures affecting the performance of systems or products (Onodera, 1997).FMEA is a commonly applied tool in addressing potential failures in the product development process and its effects on systems or products (Smith, 2001, Kus̆ar et al., 2004).FMEA also offers an approach to ensure product reliability (Ahmed, 1996), and is, therefore, strongly connected to product usage conditions and environments.
Figure 1 -Claims data analysis flow, adapted from Blischke et al. (2011) The claims analysis flow is suggested as a key practice to support upstream RDM efforts with the use of back-end data.

RESULTS
The existence of a customer claims process and database is well known and acknowledged by all interviewees.This could be pointing to the fact that none of the interviewees is new to the organization.Each of them has been an employee for more than 10 years, ranging from 13 to 30 years of service.On the other hand, when asked how much each of them is involved in the process, with the exception of two Quality employees, the responses were similar, i.e. they were not at all involved.A few responded that they were unaware, or not informed, of the flow of the claims system or the outcome of the claims analysis.
One of the functions of the PM leader is to schedule and perform a field test of all products developed within the organization.The field tests are seen as a requirement in the process of developing new products and simultaneously, as a confirmation to the government regulations in assuring the safety of the products.
The field test results are then used as input to solve design issues or as improvement ideas, when necessary, by the PM team.
We normally schedule field tests in November, to have a winter test.I talk to the drivers, ask them about different technical functions, and then I disassemble, take photos and store information in the field test database.
Then we work on the issues, if any.
In reality, various conditions, for example, driver lack of attention to the product or lack of knowledge of the maintenance of the product, could lead to product failures.Such conditions may not present themselves during a field test.A product update proposal system is maintained, in which each employee is allowed to present ideas for product and process improvements.Most of these proposals come from Production personnel, for example, requesting a new jig for a certain process, change of specifications in an old drawing, request for a new tool required for a process, or improvement of a process flow.Such proposals are reviewed and approved, by R&D personnel, as an entry in the product update proposal system.These entries are then prioritized and opened to execution by a cross functional team.
The product update proposal system also includes a number of improvements which originate from the customer claims process.This, however, does not occur consistently, or systematically.The trigger to analyze a customer claim as part of an improvement is an unusually high number of returned products, possibly from very dissatisfied customers.When the monthly claims statistics are generated and an anomaly is detected, where one product or part is claimed by customers in high quantities, or a certain customer has returned a batch of products under the same failure code, it is brought to the attention of everyone involved as a major quality problem.Such instances require both the R&D and QA personnel to analyze and investigate the root cause of the problem.The analysis and investigation are then initiated through the cross functional team operating the product update proposal system.The problems are recorded and prioritized for execution.One of the requirements of the PM process is to carry out FMEA for each product or part that is developed or improved.
The lack of structured and systematic analysis of claims was also identified as a result of the Affinity Diagram exercise in trying to establish the barriers to using claims data for improvements in the organization.The following statements were picked out from the first round of the exercise during which ideas were written down by each participant on what hinders the usage of claims data for improvements.

• Lack of communication about the claims system between departments
• There is little communication between claims handling and product development

• Claims system is not used by all departments
• Lack of structured process in handling claims • No systematic linkages between claims and improvements

• Poor support of systematic analysis of claims
The suggestions as to what were the problems in using claims data for improvements were combined into a single sentence in a subsequent round of the exercise: One of the biggest problems in using claims data for improvements is that there is a lack of structured and standardized process flow of the claims process internally.
It was unanimously agreed by all participants that a structured and standardized flow is required in the claims handling process, where linkages are clearly identified between departments.Process ownership and responsibility shall also be identified in order to increase flow and the content of communication regarding claims system and analysis towards improvements.

ANALYSIS
Back-end data or field data is a source of information specific to product usability and reliability (Petkova et al., 2005).Products are subjected to various conditions of usage, including user knowledge and environmental conditions.These are connected to product usability information.Back-end data such as customer claims is a source of such information, especially those relating to product failures.As noise factors are often connected to product failures, claims data presents an opportunity to extract such information.Claims data, raw or analyzed, is of critical value to an organization, especially to designers in R&D, project management (PM) leaders, and members of the sales team (Murthy and Blischke, 2000).Through systematic analysis of claims data with a tool such as FMEA, improvements in the product development process becomes feasible in terms of product robustness, where noise factors affecting products during usage are identified and addressed.As elaborated on previously, RDM, characterized by its principles, practices and tools is adopted for the application of back-end data.The continuous applicability of RDM in product development is practiced through a systematic analysis of claims data with the use of FMEA as a quality improvement tool.
The lack of a systematized claims analysis structure in addressing improvements is a major challenge (Zairi, 2000).The case study results show that claims data lacks a systematic analysis structure and, therefore, does not contribute to any improvements.Furthermore, the claims data analysis is not suitable for sharing organization wide.In order to create a practicable connection between claims data and product or process improvements, a systematic root cause analysis of claims could be included and tied to a quality improvement tool such as FMEA (Blischke et al., 2011).The analysis of claims could be, first, categorized into product groups, where engineers or designers responsible for the product groups are involved in the analysis.Secondly, the claims of each product group could be broken down based on failure codes, where failures are investigated and classified under various types of problems, such as customer, production or design related.This could narrow down the analyses of root causes towards specific noise factors connected to the failures.Such systematic analysis of claims processes contributes to the continuous improvement cycle in product development (Nilsson-Witell et al., 2005).Sharing product knowledge related to failures and functions is also viewed as valuable inter-project learning in product development (Antoni et al., 2005).
The existence of FMEA as a quality improvement tool in product development at an organization presents a convenient opportunity.The claims analysis flow shall generate input or feedback data to the FMEA.Upon the identification of the problem, customer, production or design related, through claims analyses, FMEA could be initiated with respect to the problem.Details such as usage at failure, for example, could lead to the identification of related noise factors.This, then, allows for the opportunity to address those noise factors through systematically formulated action plans in the FMEA.The case study results show that FMEA draws on selective claims within the organization, when deemed necessary and purely on a case-by-case basis.The lack of structure and integration of claims analysis activity within the organization are seen as obstacles towards the utilization of back-end data for improvements in product development (Zairi, 2000, Fundin andCronemyr, 2003).The claims analysis flow, as presented in Figure 1, is suggested as a viable approach for creating a systematic and integrated application of claims data for the purpose of product and process improvements in product development.
The FMEA template shown in Table 1 can be adapted to the current application at an organization.Due to confidentiality purposes of product and customer information, the template below is void of real-time details of the FMEA.
The grey shaded section on the left of the table is an added feature to the current FMEA template based on the suggested claims analysis flow.The 'failure code' and 'failure mode' columns contain information derived from the claims database.The systematic analysis of failures in the FMEA is hereby connected to the failure modes identified in the claims database.A hypothetical example of a product failure is presented here in order to exemplify the usage of the template.
Table 1 -FMEA Template as per the practice at the organization

Hypothetical example
The presentation of this example is based on a training manual of FMEA: Failure Mode Avoidance Guide on thought experiments, mistake prevention, robustness and clever testing as used internally at the organization.
An example of an item in the FMEA is described as a "sleeve".During an inspection of the returned product, a sleeve was found covered in a large amount of grease and oil.Upon disassembly and cleaning of this sleeve, it was found to be slightly rusted.Applying grease or anti-rust oil is a probable practice to maintain the components of the product.Nevertheless, it was concluded here that the user or users were unaware of the proper method of protecting a sleeve from rust.The excessive amount of grease and oil attached to the sleeve could be identified as a noise factor affecting the performance of the sleeve, or in the least as a factor contributing to the improper maintenance of this sleeve.The failure mode of sleeve shall be categorized as malfunction of the sleeve.The cause of failure here is an indication of poor or improper maintenance, which contributes to the failure mode.Therefore, the cause here could be summarized as a lack of awareness or training for users in product maintenance.The sources of variation or noise factors in play here make up the difference in user knowledge in terms of product maintenance.
During product design, the designers may not have prioritized user knowledge or an adequate amount of grease or type of anti-rust to be applied.Upon analyzing claims data in the case of the sleeve, an opportunity to understand these uncontrollable factors is presented.An analysis of claims data with the use of FMEA provides a systematic way to analyze defects and further, the noise factors affecting the products.Understanding the noise factors such as variations in user knowledge and/or variations in the types of anti-rust to be used for maintenance of parts, the corrective actions to be implemented might involve:

DISCUSSION
Adopting RDM in product development is widely dependent on front-end data such as new customer wants and needs (Hasenkamp et al., 2007).The wants and needs of current customers in the form of dissatisfaction feedback or back-end data are most often not taken into consideration (Fundin and Elg, 2010).The formulation of a systematic structure to analyze claims data as a means of understanding noise factors in product development is one way to utilize backend data based on RDM principles.The relevance of back-end data is emphasized in connection to the need for practices to address the continuous applicability of RDM.
Field tests are not only time consuming, but also expensive (Karim and Suzuki, 2005).Furthermore, the results obtained are dependent on selected users and known conditions during product use.Failures of products in unwarranted conditions or environments are commonly not apparent in field tests.Claims data is an extended form of field data (Rai, 2009), where product failures occur due to certain noise factors unable to be detected through a scheduled field test.In making such comparisons, field tests are not at all discredited.Although a field test is one reliable way to improve product performances, it is argued that claims data contribute to improvements in product development in an extended way by capturing product failures during all stages of use.Claims data containing information related to customer usage and conditions (Blischke et al., 2011) present a unique opportunity to improve the design of products.The feedback of such information to the front-end of product development allows product designers to act proactively in the development of new products or the update of current ones (Magniez et al., 2009).Improvement opportunities at the product development process are further extended to include the systematic handling of possible noise factors identified in the claims analysis.
A systematic and integrated claims analysis not only contributes to improvements in product design, but also to increased ownership of product failures and its causes within the organization (Boersma et al., 2004).Claims from customers are a difficult aspect of all industry (Wu and Meeker, 2002).Organizations would rather like to replace a failed product than deal with the implications that come with claims.The values of claims are most often ignored due to a possible lack of structure to handle claims constructively.Systematic analysis of claims not only addresses all customer claims, but also leads to improvement ideas in the product design phase (Murthy and Blischke, 2000).

CONCLUSIONS
Back-end data is collected, stored and maintained in a database in the form of customer claims.A well-defined claims analysis flow is essential as a first step to appreciate the value of back-end data.Nevertheless, a well-defined claims analysis flow alone is insufficient.It is necessary to create links between claims analysis and improvement tools.A systematic flow of the claims analysis leads to an in-depth description of problems.When problems are categorized in terms of customer, production or design related, they could be segregated for analysis based on team or individual expertise.The problems are then analyzed using a quality improvement tool such as FMEA to complete the claims analysis flow.
Here, the FMEA creates an opportunity to investigate failure modes of products.These failure modes are often related to noise factors to which products are subjected during the use stage.Understanding and addressing the noise factors allows for an informed decision on action plans.This complies with the principles of RDM, namely awareness of variations during the product use stage and creating insensitivity to the noise factors identified.
The results of the case study show a lack of practices linking back-end data to improvements in product development.Systematic analysis of claims data is suggested as one practice for RDM, and in support of QM principles such as customer focus and continuous improvement in product development.This practice is then linked to a quality improvement tool to not only investigate the failure modes but also address related noise factors.Understanding product usage and conditions in which it is used brings engineers and designers a step closer to identifying related noise factors.One way to such understanding is through the use of claims data.The structured flow of claims data analysis addresses failures through problem detection.The customer, production or design related problems are most often related to noise factors affecting products.The analysis ends in FMEA, a quality improvement tool capable of systematic analysis of problems.The analysis may result in design solutions to be fed back to the early phases of product development.This practice is supportive of the continuous applicability area of RDM.It further emphasizes the use of back-end data as feedback into product development based on RDM principles.Improvement in product development, with regards to QM principles such as customer focus and continuous improvement, is emphasized with the application of back-end data in connection to RDM.
that designers could solve.This was further strengthened during the interview with the R&D Department, responsible for new product development, speaking about the availability of claims data in the processes of product planning and new product updates.
Therefore, sharing claims data within the organization may bring to surface