Public version
Using risk categories for a customized
development process to improve quality.
A case study at the Special Products Engineering Department (SPED) of
NMHG
Thesis
MSc Technology Management
Company Supervisor: Roy H. op ten Berg (Special Products Engineering Manager) Email: Roy.Op.Ten.Berg@nmhg.com
Tel: +31 (0) 243742455
Supervisor RUG: dr. W.M.C. (Wout) van Wezel Co-assessor RUG: prof. dr. G.B. (George) Huitema Author: Hans Westerhoff
Student number: s1468839
Abstract
Contents ... ii
Abbreviation ... iv
1 Introduction ...5
1.1 Introduction to the problem. ...5
1.2 Introduction to the Company...5
1.3 Theoretical context ...8
1.4 Research design ... 11
1.5 Problem mess - management problem ... 12
1.6 Problem definition ... 12
1.7 Outline of the paper ... 13
2 Analysis and Diagnoses ... 14
3 Theoretical approach ... 16
3.1 Types of design ... 16
4 Solution design... 22
4.1 Solution Methodology ... 22
4.2 Result of improvements... 24
5 Conclusion and further work ... 43
5.1 Summary ... 43
5.2 Conclusion - main improvements of the process. ... 44
5.3 Evaluation and further work for science ... 46
Appendix I. Additional information of the SPED processes ... 48
Appendix II. Change propagation in redesign. ... 49
Appendix III. SQ and SPO number overview ... 52
Appendix IV. Instructions methods and tools. ... 53
IV - 2. Product requirements list ... 55
IV - 3. Requirements checklist and information management. ... 56
IV - 4. Functional Analyses and System Technique ... 58
IV - 5. Concept creation and selection ... 59
IV - 6. FRAT ... 60
IV - 7. FMEA ... 61
DCN Document Control Number: A unique number assigned to all controlled documents and records recorded in the master index system of NMHG.
EMEA Europa, Middle East & Africa
FAST Functional Analyses System Technique
FEA Finite Element Analyses
FMEA Failure Mode Effect Analyses
FPI Field Product Improvement - Process for making changes to field population
FRAT Function Requirements Answers Test
HVL High Volume Line
LVL Low Volume Line
NACCO North American Cool Company
NCR Non Conformance Report
NCR-30 Non Conformance Report (up to 30 days after PDI)
NMHG NACCO Material Handling Group
NPC Nijmegen Production Control
NPD New Product Development
PDI Product Delivery Inspection
PDP Product Development Process
PQIP Process Quality Improvement Process
RFQ Request For Quote
SO Sales Order
SPD Special Product Designs
SPED SPED has an double denomination: Special Product Engineering Department or Design
SPIRA Special Project Initiation, Request and Approval
SPO Special Product Order
SQAS Special Quote Application Sheet
TDQ Team Delivered Quality
Introduction
1 Introduction
In this chapter an introduction is given to the research paper. First, the problem is introduced; secondly, the company used for this case study is introduced. Then, the theoretical context is described. Followed by the research design, including the methodology, problem statement and main research goal. At the end of the chapter an outline of the paper is discussed.
1.1 Introduction to the problem.
A product development process is mainly important for managing the risks involved, documenting the decisions and results and including all the different requirements and needs. Over the last decades an extensive array of development processes are created. Most of these processes focus however on new product development. Next to the new product development also al lot of products need to be redesigned or customized, this can be in a range from a small adjustment up to a complete redesign of a product. These tasks are often too small to put through a general development process. Resulting in bypassing them, this leads to no (standardized) structure for these tasks, no or less documentation and no good argument for the go / no go decision. Another issue with customized products is that before an order is made often a quote of the (re)design work is needed. There should be a balance in the effort done before the quote and the quality of the quote. This paper uses an adjusted method for customizing a development process recently provided by a series of papers (Unger & Eppinger, 2009); (Unger & Eppinger, 2011). This adjusted method is used in a case study to provide a customized development process for a range of customer request at the Special Product Engineering Department (SPED) of NMHG. These requests differ in size, complexity, scope and risks involved. The company used for this study is introduced in the next sentence.
1.2 Introduction to the Company
The company which is used in this case study; NMHG is one of the largest manufacturers of counterbalance trucks and reachstackers. The company designs, engineers, manufactures, sells and services a comprehensive line of lift trucks and aftermarket parts, marketed globally under the
Hyster® and Yale® brand names.
1.2.1 NMHG - Nijmegen
Hyster was the original brand of the factory in Nijmegen, which started to build trucks in 1952.1
Nowadays the location in Nijmegen is the global centre for the development and manufacturing of big trucks. These trucks are capable of lifting loads bigger than 8 tons and up to 52 tons. There is a big variety in usages, from container handling to coil handling.
The site in Nijmegen has a state of the art facility for new product testing (BTDC) and also houses the Special Products Engineering Department (SPED) for the Hyster big trucks. Also the European Parts Operation (EPO), which is a customer service centre and has aftermarket support functions is located in Nijmegen. Parts can be sent within 24 hours to all over Europe. NMHG have implemented a quality management
system such as described in the DIN EN ISO 9000 and are a certificated company. The NMHG Nijmegen plant produces both ‘Hyster’ and ‘Yale’ trucks.
The Nijmegen plant has two production lines; the High Volume Line (HVL) and the Jumbo Line (Low Volume Line; LVL). They are capable of producing 8 trucks a day on the HVL and about 2.5 trucks a day on the LVL. See production of last 2 years in Table 2 below and explanation about the series produced on the HVL vs. LVL (Table 1)
Table 2 Truck production 2011 and 2012
1
http://www.hyster.com/Europe/nl-NL/AboutHyster/Geschiedenis.htmx
Table 1 Assembly lines HVL and LVL
Line Series
HVL 6 - 16 ton counterbalance trucks
LVL 16 - 48 ton counterbalance trucks & all reach stackers Omitted due to
Introduction
All the parts of the trucks are manufactured by other locations or companies. In Nijmegen they are assembled to the final truck. The trucks in Nijmegen are produced based on the Make to Order (MTO) principle, or when SPED is involved Engineer To Order (ETO).
1.2.2 Special Products Engineering Department (SPED) The department that is central in this paper is the
Special Products Engineering Department (SPED). The SPED department located in Nijmegen has the role to find engineering solutions for applications where standard Big Trucks need to be adapted. Within this department there are working to develop and design adaptations to the standard Big Trucks. They are involved when a customer requires a truck that isn’t within the already wide range of standard product options. The sizes of the projects are varying,
such as a paint job in specific colours, through to big developments requiring longer frames, a wider chassis or even higher capacity. They work closely with the customer and distribution partner to ensure that the correct specification is identified and then followed through to delivery.2 SPED will
be analyses and discussed in more detail further on in this paper. In the next section the theoretical context about development processes is discussed and a way to categorise them is shown.
2Information used from interview with Roy Op Ten Berg, 2010 (
1.3 Theoretical context
In literature there are a lot of efforts been done to assist the designers and engineers with generic models to describe the design and development process. The main purpose of these processes and methods are to manage the risks involved, reduce the development time and create better products. This process can be seen as “an interdisciplinary activity requiring contribution from nearly all the functions of a firm” (Ulrich and Eppinger, 2008). The three main functions are: Marketing, design and manufacturing.
The most common form of these methods is the “Top- down” method. (Johnson R. , 1978) (Dym, 1994) (Pugh, Total Design, 1990) (Pahl & Beitz, 1996) (French, 1985) (Cooper R. , 2001).
Although the design and development models are all a bit different in terms and detail, the general process can be described as (Dixon & Colton, 1998):
• Product Specification
• Concept exploration and selection • Conceptual design.
• Layout design • Detail design • Manufacturing
Introduction
Figure 2 The traditional staged PDP by Unger and Eppinger, 2009
Unger and Eppinger, 2011 describe two metrics which can be used to describe and compare different PDPs: Development iterations and development reviews. See Figure 3 below for the accompanying matrix.
Figure 3 Scope of PDPs by (Unger & Eppinger, 2011)
The above figure divides the different PDP’s into four categories: the ‘Staged’ and the ‘Spiral’ process and two Hybrid forms. The general staged process has been described above.
A spiral process is more common in software development processes, but also become more popular in other disciplines. (Cooper & Edgett, 2008). This spiral process is a more flexible method and uses planned iterations to manage risk in an early stage in the process (McConnell, 1996), (Hicks & McGovern, 2009). The development process goes through the different phases multiple times
This matrix will also be used to categorise the current process of SPED (Chapter 2) and will come back in the conclusion to compare it with the recommended process.
Introduction
1.4 Research design
In this chapter the research design is discussed. First, the used research methodology is shown. Then the management problem is introduced, followed by the problem statement and research question. 1.4.1 Research methodology
The methodology used for this project is a problem solving cycle also known as the ‘regulative cycle’ (Van Strien, 1975) this model is shown in Figure 4.
Figure 4: regulative cycle (Van Strien, 1975) This cycle contains of 5 stages.
• Problem definition • Analysis and diagnosis • Solution design • Implementation • Evaluation
This project does not cover all the 5 stages in the regulative cycle, the first three stages are completed, however some solutions might be implemented already during the project.
1.4.2 Research scope, restrictions and limitations
departments and/or stakeholders who are involved in the SPED process will be included; this does however not mean it is a companywide research.
This project is conducted in an 8 – 9 month period. In this period I was an intern in the SPED with NMHG Nijmegen. Because of the limited time and interfaces with this subject in other disciplines, there is no guarantee that all relevant literature and theories are included.
1.5 Problem mess - management problem
The standard big trucks are thoroughly designed by the new product department that uses a 6 stage development method for the design of a new truck. In these designs a lot of requirements, regulations and laws are included.
When the SPED order has an adaptation requested, the restrictions and laws can be overlooked. The adapted truck should comply with legal requirements and should also retain the basic functional truck options (standard options). Within the SPED department there is not enough time nor is there a systematic way in which these conflicts are incorporated or can be checked. Due to the variations in special customer requirements, as mentioned earlier and the lack of time it is also not necessary to check this for every adaptation.
As a result, there is no guarantee that after a redesign the truck does comply whit these laws and restrictions and therefore is of less quality.
Another problem is the customer requirements, they are often not clear ore are already formulated as a design solution. These customer requirements come from dealers all over the world. They speak on behave of the customer and therefore it is difficult to ask additional information from the end user.
1.6 Problem definition
Introduction
1.6.1 Goal of the research
The goal of this research is to search for improvements in the design and development process of the SPED and to bring the total quality of the SPED designs to a higher level. Recommendations for the implementation of these improvements should be made. This improvement should maintain the current lead-time as much as possible.
1.6.2 Research question analyses and diagnoses
Considering the problem statement and the goal of the research, the research question for the Analyses and Diagnoses phase can be formulated.
Research question analyses and diagnoses
What is the current status of SPED-Nijmegen, and what kind of quality issues are there?
For answering the above question some sub questions need to be answered in the Analyses and Diagnoses.
Sub questions:
• What is the current process of the development of special designed trucks / parts? (SPED process)
• Which designs are commonly made by SPED and how often (also in comparison with the standard products)?
• Which departments / stakeholders are involved and what is their role in this SPED process?
• What quality issues involving SPED can be identified and what is the extend of these issues?
1.7 Outline of the paper
2
Analysis and Diagnoses
Due to confidentiality this Chapter is almost entirely omitted, only a simplistic version of the conclusion is shown in the figure below following by an explanation of the terms.
Discrepancy in (functional) requirements
During the process of making a custom design for a truck (this process is discussed in: Chapter 2.1
Omitted due to confidentiality) and Appendix I Omitted due to confidentiality), special customer
requirements for the truck are demanded. The customer requirements are merged with all the existing requirements. This leads to the designs or redesigns which meets the demand of the customer. During the quote and design process these requirements are transformed into a set of designs. When the finished truck does not completely fulfil these requirements (or expectation of the customer) the cause of the incident is considered a discrepancy in requirements.
Design error
Analysis and Diagnoses
Communication error
When the incident or error can be related to a miscommunication within the SPED department or between SPED and others involved, such as: Dealer, assembly, sales etc. This is considered a communication error.
Quality issue SPED parts
These are parts which become defective after use. These defective parts are a responsibility of the SPED designer; mostly it’s more an indication of the quality of the parts, than of the design. Also most of these claims are reclaimed at the supplier
Assembly error
3
Theoretical approach
In order to come with a proper solution and improve the quality of the SPED designs a further literature study is done. The literature discussed in this chapter will focus on reducing the three main variables in the causal model shown in the previous chapter: “Design errors”, “Discrepancy’s in requirements” and “Quality issue SPED part” The chapter starts with the formulation of types of designs, following by some theory about: approaches to redesign, risks and uncertainties involving this process and customizing a design and development process. This last part will be the basis for the used methodology for the solution design.
3.1 Types of design
When talking about a design and development process, this design can be constrained by previous designs or concepts, which also limits the freedom of the engineers. Culverhouse (Culverhouse, 1995) identifies four types of design tasks which are more or less constrained by existing designs. He uses two dimensions of knowledge: New knowledge in design and new knowledge in production, to distinguish the different categories of design. The four categories are: “reorder”, “variation”, “innovation”, and “strategic”. This is graphically shown in Figure 5 below. For each category, Culverhouse defines a set of constraints, which are indications of portions of existing products that cannot be changed for the redesign and also limitations on specifications, concepts, functions, and test.
Theoretical approach
The SPED design tasks can mostly be covered by the first two categories: Reorder and Variant designs.
Also in the specific case of the SPED designs which are requests from the customer, this are customized designs. Customized products can be described as products with need a slight variant of the standard configuration and are often a response to a specific order by a customer. (Ulrich & Eppinger, 2008). As already described earlier the most design and development models are for new product design and not for customized designs. But there can be found some recommendations when redesign is involved (customization is also a kind of redesign.) these recommendations are discussed below.
3.1.1 Redesign process models.
With NPDs, a designer or project team starts with a new product idea, and has no tendency toward a particular solution or component set. In cases of redesign the starting point and the goal is different. A redesign process starts with an already existing product ore set of solutions, and has the goal to maximizing the reuse of the existing product which already has been proven and tested into the field. This reuse will minimize the resources needed to come with the redesigned product. In case of a redesign, these methods are less useful for guidance of these “short cut” processes. These models, if possible first have to be modified, in order to be useful to a redesign process. When only using the standard new-product process, regardless of the project size and risk level, there is as risk that redesign projects like customer requests are seen as too small to move through the process and bypass it.
Pugh, (Pugh, Creating innovative products using total design, 1996) made two modified models for coping with a more fixed design concept. He modified his original “dynamic” model by switching the order of two phases of the design process. These changed sections of the process are shown in Figure 6
In Figure 6, (a) shows the original “dynamic” model; (b) is for “static” products were the concept is fixed, like a standard automobile design. The last (c) is for other redesign processes were the start is an already existing design or product.
Basically instead of translating the market requirements directly into design specifications, first a fixed concept design in model b or an already existing design or product in model c is taken as base. This fixed concept or product is then used to translate the market requirements into specifications. In case of SPED the market would be a single customer. The current process of SPED, does not describes how to cope with already existing SPED designs which need a redesign.
Another recommendation comes from Cooper, who recommends a differentiation in his stage gate process (Cooper R. , 2008) see Figure 7 below. After the idea stage, the major new product project goes through the full five stage process. The Moderate risk projects, including extensions, modifications and improvements, use the three stage process and the Sales-force and marketing requests (very minor changes) use the two stage process. For SPED the Lite option could be considered for the improvement of the SPED process. For the basic model this could be guidance but the linkage to the causes of the issues could not be made.
Figure 7 Stage gate process - three sizes by Cooper, 2008
Theoretical approach
Processes (PDPs) require careful design to reduce development time, create better products and manage the risks of bringing new products to market” (Unger & Eppinger, 2009)
The method of Unger and Eppinger, 2011 is based on managing information flows, risks, and iterations. A product development process must be able to manage and mitigate the risks involved. In the product development design method the risks are matched to specific process iterations and reviews. In this manner companies or departments can design processes that are customized to their risk profile and abilities. What the risks are and how they can be linked to the result of the analyses is elaborated below.
Risk can be defined as situations or circumstances that are likely to occur and have negative consequences, like danger or loss. Balancing between risks and potential reward is an important issue in the process.
Risk can lead to several failures in the design and development process: A product may not be ready in time, a new complex product can be impossible to design, or may not provide the expected features or quality. Also the product specifications may not fulfil the customer needs or expectations and therefore not be ordered or accepted. (Awny, 2006).
A good way to categorise these risks is by the source of uncertainty underlying the risks (Cross & Sivaloganathan, 2005), Ward and Chapman endorse this by arguing in their paper that “a focus on
‘uncertainty’ rather than risk could enhance project risk management, providing an important difference in perspective” (Ward and chapman, 2008)
In a development process there are four major risks that should be managed or mitigated; these are not all encompassing or total mutually independent: (Unger & Eppinger, 2009)
• Technical risk: Uncertainty about the technological feasibility and performance of the product.
• Market risk: Uncertainty as to whether the product meets the requirements of the customer • Schedule risk: Uncertainty about if a product can be developed in the time available.
• Financial risk: Uncertainty about if a product can be developed on budget and ROI.
In PDPs these risks are addressed through product development iterations, integrations, and reviews. (See Figure 2 The traditional staged PDP by Unger and Eppinger, 2009, p9.) Iterations are often related to market risks while reviews are often related to technical risks. (Unger & Eppinger, 2011).
The full PDP design method is graphically shown in Figure 8 below.
Figure 8 PDP design method by (Unger & Eppinger, 2011) The method consists of four steps:
• Identify uncertainties and prioritise risks
• Assign risks to iteration cycles, reviews, or stages. • Plan iteration and integration cycles to address risks • Schedule key reviews
Theoretical approach
.
Figure 9 The Spiral PDP by Unger and Eppinger 2011
4
Solution design
In this chapter the used methodology and method to come with a proper solution is explained. First the main objective is formulated. Secondly the method to improve the development and design process is discussed which leading to the solution methodology used. In the last section the results will be shown.
Main question:
How can the discrepancies in requirements, design errors and quality issues of SPED parts be reduced in order to improve the total quality of the SPED designs?
Main objective:
Recommend improvements to the design and development process of SPED to reduce the discrepancies in requirements, design errors and quality issues of SPED parts in order to improve the quality of the SPED designs.
4.1 Solution Methodology
To improve the SPED development process, the method of (Unger & Eppinger, 2011) is used as a basis for the design of the development process. This method is already explained in the previous chapter. The described method can be used to design or improve a design and development process for a specific situation. However in this case there cannot be spoken of one specific situation. The special design requests handling by SPED vary in complexity and new knowledge needed. Also the risks involved will diver in this range. The method of Unger and Eppinger, 2011 is mainly based on the uncertainties and risks. It would not be a good idea to design a single process for this range of requests. Cooper, 2008 also makes a differentiation in the size of a project (see Figure 7, page 18). This will also be recommended for the situation of the SPED requests. These different development processes can be designed by using the method and make distinguishes per category. Therefor an extra step is added to the method to include a categorisation based on risks. The method also could be done separately for each category, but this has a disadvantage. In separate processes for the categories there might arise significant differences, which would be confusing for the engineers. This extra step has to be done after Step 1.
Solution design
The final used methodology is summarised below. 4.1.1 Adjusted development and design method
The steps of the adjusted development design methods used are: • Step 1: Identify uncertainties and identify risks.
• Step 2: Create categories based on these uncertainties and risks. • Step 3: Assign risks to iteration cycles, reviews, or stages.
• Step 4: Plan iterations and integration cycles to address risks. • Step 5: Schedule key reviews.
• Step 6: Plan tasks within the stages to address the risks and specify the deliverables for the reviews.
See Figure 10 for a graphically representation of the adjusted development design method.
Customized Development Process 1: Identify uncertainties and prioritize risks 2:Create categories based on the risks
3: Assign risks to iterations cycles, reviews, or stages
4: Plan iterations and integration cycles to
address risks.
6: Plan tasks within the stages to address the
risks and specify the review deliverables 5: Schedule key reviews. Customized design development method Specific Development Situation
4.2 Result of improvements.
For designing and improving the Product Design & Development Process of the SPED, the above described method is used; this method is based on the method of Unger and Eppinger, 2008. It uses the risk analysis as a main factor in the design. In this paragraph the results of the six steps are shown.
The result of the issue analyses can be translated to the uncertainties and risks which are involved in the design process. This will be explained in the first step below.
4.2.1 Step 1: identify uncertainties and prioritise risks
The analyses and diagnoses from Chapter 2 has given a good understanding of the tasks and process of SPED also a couple of causes were found responsible for the majority of the SPED related Issues. The three most important causes:
• Design errors
• Discrepancy’s in requirements • Quality issue SPED part
From this analyses and diagnoses the most important uncertainties and risks involved in the development process of SPED can be derived.
These issues were allocated to the main four risk categories earlier discussed. In the range of SPED requests, the most imported risk categories are: market and technical risk.
Discrepancies in requirements can directly resolve in a market risk (not quoting or designing the correct product). Whereas Design errors and Quality issues SPED parts can directly cause a technical risk (the product is not correct designed or manufactured.)
Generally speaking these risks can be translated in the following two main risks and uncertainties and have the highest priority:
• Market risk - Do we Quote and Design the correct product
• Technical risk - Do we Design and Manufacture the product correct.
Solution design
4.2.2 Step 2: Create categories based on the risks and uncertainties
As can be concluded from the SPO/SPD analyses, there is a large variety of special requests, varying from an extra-option like a mirror or working light up to a rotating seat or special attachment. Also the risks of such special request have a wide range. And therefore the steps and tools needed in de development of these request can also be different. In order to give a differentiation in this customized development process, the request will be classified into three different categories. A schematic diagram of these categories is shown in Figure 11 below.
Market Risk
Do we Quote and Design the correct product
Technical Risk
Do we Design and Manufacture the product correct
Category 2
- SQAS needed
- Application dependent/new - Different application/truck - Known and proven concept - No templates available
Category 3
- New concept - Not proven in industry - Safety involved - Complex interactions
Cate
gory
4
- Marke t analysis nee de d - Ne w application re quests - Multiple customers (e nd use rs )Increasing financial and planning risk
Category 1
- Known (and proven) concept - Template available - Same application/truck - No SQAS
Category 5
- Specialists needed
- General development project
Figure 11 Risk categorisation of SPED requests
The categories are based upon the two major risk discussed earlier: the market risk on the horizontal axis and the technical risk on the vertical axis. Also the relation with the financial and planning risk is illustrated. In general a higher market and technical risk will lead to a higher financial and planning risk. These risks are higher in C2 and C3 and therefor, not to be forgotten in these categories.
The categories are formed based on the market risks and technical risks. These risks are related to other factors which are outlined by risk below.
Market risk
a slight adjustment and can be considered within the first category (C1). When there is no experience with a typical request or it’s concerning a different application or environment or a different truck type or series, the request is of the second category (C2). In C2 more (new) information (e.g. requirements, restrictions, and standards) needs to be processed to come up with a proper solution. When a requests needs to be suitable for a new application concerning multiple customers, the request no longer falls under C2. For this kind of projects a more thorough market analyses is needed (C4), which lies not in the scope of the Sped projects and therefore is not incorporated in this process.
Technical risk
For the assessment of the technical risk, complexity, knowledge and experience are two important aspects to consider and are used to make differentiation between C1, C2 and C3 and between C3 and C5 (see Figure 11, above).
In the literature there are multiple views on complexity. The key type of complexity from an engineering change perspective is connectivity (Johnson J. , 1995) & (Sosa, Eppinger, & Rowles, 2007). The measure of complexity is given by the linkages between elements and their interactions within a system. A lift truck as a hole is a complex product; there are a lot of linkages between parts and systems. For a SPED request the degree of change and the involved systems and parts are an important measure for the complexity of the request. These two aspects are also related to the chance of change propagation, change propagation is discussed in more detail in Appendix II. All these aspects about complexity above and the knowledge and experience present within the company are used to determine the boundary between C1 & C2 and C3. This can be difficult to assess. The knowledge and expertise of the application engineer is therefore very important in this judgement. An extra factor for this decision is when safety is involved. With safety involved extra analyses have to be done to analyses the risks, this could be done by using an FMEA, and will fall under category 3.
When the complexity is at a point that the expertise’s of specialist(s) are actively needed, the request will no longer fall in the range of C3, and will be too large to handle by SPED. This C5 will not be in the scope of the design and development process of SPED. For this kinds of projects a more comprehensive process and resources is needed.
Solution design
Category 1
The SPED request covered by category one has non to little market risk and has also non to little technical risk.
Conditions
• Known and proven concepts.
• Templates and documentation are available.
• The request is independent of the application, no SQAS3 needed.
• For this category some often used options, templates can be made. Important steps in the development process
• Requirements analyses. • Verifying the differences. Category 2
Category 2 has little to medium market risk and no too little technical risk. Conditions
• Concept is known and is proven in industry or truck platform. • Low complexity (little affected systems and components). • Not safety related.
• The request is dependent on the application, SQAS is needed. • No documentation is available (for truck platform or application). Important steps in development process
• Customer initiation (SQAS). • Requirements analyses.
• Functional decomposition and requirements linking. • Verification of the functions and requirements. Category 3
Category 3 has no to medium market risks and little to medium technical risks Conditions
• No concept is known or not proved in industry or platform • Small project - SPIRA4 needed
• No templates available
3 SQAS: Special Quote Application Sheet is a document developed by SPED and Sales for electing knowledge about a specific application or environment related to the Quote Request. De sheet is designed to only ask the questions which are relevant to the request.
4
Important steps in development process • Customer initiation (SQAS)
• Requirements analyses
• Functional decomposition + requirements linking • Verification of the functions and requirements. • Concept creation and selection
• Complete FRAT documentation
• Validation of requirements and design (FMEA, FEA, Calculations, Tests)
In exceptional cases a SPED request comes from an (new) application and needs to be for a range of customers. In this case a more thorough market analyses is needed. (Multiple SQAS + interviews) This is not covered in this paper.
Category 4 - Market analyses needed (out of scope)
Category 4 has no to little technical risk and high market risk. This category is mostly not in the range of an SPED request. If such requests (from a group of customers or special application) occur then a general development process is needed.
Conditions
• Design is for more than one customer • Application in unknown or new.
Important steps in development process (extra) • Requirements need to be ranked.
• Matrix QFD needed
Category 5 – Project based – (out of scope)
Category 5 consists of high market risk and high technical risk and is therefore also not in the range of SPED requests.
Conditions
• Concept is new or unknown • Technical risk is very high • Market risk is very high
• Design for more than one customer in industry or application not known by NMHG • Complexity is very (more systems affected and specialist(s) needed)
• Safety is unsure
• Specialists knowledge are needed
Solution design
Classifying the Special Request into categories
Figure 12 Category decision tree
In the above figure a simple decision tree is shown to classify the Special Request into the risk categories described above. Is the design done before, completely documented and does it concern the same application or truck series, than the request will fall under category 1. The complexity and the fact if it is a proven concept make a distinction between category 2 and 3. The questions are not all unilateral, and of course the engineer needs to be careful in using this tree and consultation with design engineers might be needed.
3 are variant designs. As last also the experience and knowledge of the engineers affects the answer to this question.
The risk categories will be used to make a distinction in the tasks, iterations, reviews and deliverables in the process and will further be noted as C1, C2 and C3. The categorisation and the use of this tree will take place in the Initiation and planning stage, see Figure 19 below and Figure 15 Flowchart stage 1) on page 34.
It is possible to change the category in a later stage however this might have negative impact on the planning and can have financial risks
4.2.3 Step 3: Assign risks to iteration cycles, reviews or stages
In this step the risks described in step 1 are assigned to: iteration cycles, reviews or stages. First the stages of the process will be described. Then the two main risks and uncertainties are assigned to the iteration cycles, reviews or stages.
When analysing the current SPED process, this process could be divided into four stages. The four stages are:
1. Initiation and Planning 2. Concept design & Quote 3. Detailed design
4. Manufacture and Validation
Solution design
Figure 13 - Custom Development Process Flow Chart
Continuing on the next part of step 3 the two main risks and uncertainties are assigned to the iteration cycles, reviews or stages. The differences between the categories (C1, C2, and C3) will not be taken into account here; this will be handled in the steps following.
Market risk - Do we Quote and Design the correct product
Technical risk - Do we Design and Manufacture the product correct.
The great majority of the technical risk will be handled in the “Detailed design phase”, were the concept solution is developed into a final design. The first technical risk is the risk of not being able to make or offer a solution to the customer’s problem(s) (technical feasibility). This risk needs to be minimized as early as possible in the process, before cost or agreements are being made to the customer (quote). This feasibility shall be identified in the first review.
In the detailed design stage the uncertainty of making the product correct, which all the requirements form the earlier phase incorporated needs to be minimized. This process often occurs in an iterative way inside this stage. In this third stage it might be necessary to have a cross-stage iteration, back to the concept design stage, to be sure that the product designed provides all the requirements or to reconsider earlier made decisions. A review after this stage is necessary to verify all the requirements.
Also the last stage: “Manufacturing and validation” is important in minimizing the technical risk. All functions or specifications which could not be verified before the design release need to be validated by inspection or test. Validation is needed to guarantee all requirements are met by the product.
4.2.4 Step 4: Plan iterations and integration cycles to address risks.
In step three the risks are assigned to iteration cycles reviews or stages. In this step these iteration cycles are planned. Also a differentiation will be made for the different categories earlier described in step 2.
Figure 13 on page 31 shows the planning of all the iteration cycle(s). There is only one planned cross-phase iteration cycle. This is in the Concept design & Quote cross-phase. The iteration will reduce the uncertainty of designing and quoting the correct solution. For category 1 (see step 2) there is no need for this iteration because of the low market risk (is a reorder). An internal iteration in the detailed design stage is also very common in a development process; this should only be necessary for Category 3 because of the complexity of the solution and resulting in a higher technical risk. The model also shows two unplanned iteration, between stage 2 and 3 and between 3 and 4. These unplanned iterations should only be necessary when failure occurs.
4.2.5 Step 5: Schedule key reviews.
Solution design
step; also the different categories will have different deliverables for these reviews. In general the first review will mostly consider the market risk. In the second review both market and technical risk will be considered. And the last review will mostly be dedicated to the technical risks.
4.2.6 Step 6: Assign steps within the stages to the risk categories and formulate deliverables for the reviews
In this last step of the custom design of the development process, the details of the stages, reviews and iterations are designed. This will result in a detailed flowchart of the total process, which also incorporates the three risk categories. The stage will be discussed in a chronological way. For every stage the following subject will be discussed: Flowchart with steps and tasks to be taken, the iteration and the review with deliverables.
STAGE 1: Initiation and planning Steps of stage 1
Flowchart
Figure 15 Flowchart stage 1 Review Stage 1
The review in this development process does not require a review board, the deliverables are known and the review is done by the application engineer himself, or in doubt together with Manager or Lead application engineer.
Deliverables
• Application sheet with:
o Objectives and needs (C1, C2, C3) o Classifying request (C1, C2, C3) o Planning (C2, C3)
• SQAS (C2&C3)
o All relevant information concerning request
Solution design
STAGE 2 (Requirements, Specification, Verification & Quote) Steps of stage 2
The first step in this stage is the requirement analyses. Not only the requirements of the customer but also (company) standards and legal requirements need to be involved. This requirement analyses can be documented in a product specification list. An example of such list can be seen in Appendix IV - 2. A requirements checklist could also help in this task. (See for example of such checklist Appendix IV - 3). The second step will be a functional analysis; the FAST 5 method
(customer orientation variant) is an example of such analyses. The FAST method is easy to use, which helps coming to a proper solution. It also helps not jumping to solution, but thinking in the functions needed. This will result in a more satisfying concept and also not restricting the design engineers to much in their design freedom. Another advantage is that the method can also be easily understood by the different persons responsible in de development process, an example can be found in Figure 26, Appendix IV - 4. The third step is mapping the requirements and specifications to these functions. There might be one or more iterations needed to be sure all requirements are covered. The fourth step is developing and selecting a concept which fulfils all the requirements and specification up to the level that a quote can be made. In this step also verifications are needed to be sure the requirements can be met (e.g. calculations and simulations).
Iteration
With a category 2 or 3 request, iteration (verification) by sales and customer might be needed.
Flowchart
Figure 16 Flowchart stage 2 Review Stage 2
This review is intended to mitigate both the market and technical risks. The deliverables need to show that the request is technical feasible and that it fulfils all the (customer) requirements, functions and specifications.
Deliverables
• Product requirements list (see example in Appendix IV - 2) o A list of all the requirements.
o Functional analyses
• Design specification (see FRAT document as example in Appendix IV - 6) • Verification of the requirements
Solution design
STAGE 3 (Detailed Design, Verification and Validation plan & Design Release) Steps of stage 3
When a Quote is also filled as order, this Stage will start. First the documentation from the earlier stages needs to be prepared for the design engineer. The design engineer’s first step is to complete the design specification (FRAT documentation). After this document is completed the detailed design can start. When the detailed design is finished the requirements are verified and an optional iteration takes place (C3). Within the verification of validation, simulations and calculations (C2, C3) might be needed (e.g. FEA). For C3 also an FMEA6 (see template in Appendix IV - 7) might be needed,
especially when safety is involved. As a last step a validation plan is made, this plan includes: the optional test plan (C2 & C3), were the last mostly physically validations are done and an inspection plan for manufacturing. This stage ends with a review and the release of the design.
Iteration
Iteration in this stage might be needed to completely fulfil the requirements and design a proper solution.
Flowchart
Figure 17 Flowchart stage 3 Review
The review of stage 3 is mostly to mitigate the technical risk. All the requirements and specifications need to be verified or a plan to validate them in a later stadium is required.
Deliverables
• Design specifications (see FRAT document; Function Requirement Answer Test.) • Requirements and Design Validation
o FMEA (C3)
o Simulations and calculations (FEA, etc.) (C2, C3) o Inspection / Test plan (C1, C2, C3)
Solution design
STAGE 4 (Validation) Steps of stage 4
When the design is released the documentation for manufacturing is prepared. This step might also include a meeting with manufacturing to discuss the upcoming SPED designs. Next, the manufacturing process will start. This process will not be discussed in detail. After the truck is assembled the truck is inspected, including the SPED designs. After inspection the optional test can start. As last the truck and the results of inspection and test will be reviewed by the design engineer responsible.
Flowchart
Figure 18 Flowchart stage 4 Deliverables
• Review of the results of inspection and test. • Final SPED documents
4.2.7 Complete detailed flow chart.
Solution design
Figure 20 Four stage SPED process with deliverables
Application Engineer Application Engineer Design Engineer Design leader
All categories All categories All categories All categories
SPED Application sheet SPED Application sheet SPED Application sheet Final SPED Application sheet Classifying request Product Requirements Document (PRD) Detailed design Full documention design
C2 Quote (SQ) C1 C2
feasibility check C2 Design specifications (FRAT) Review inspection
Planning Function structure (F) C2 Review testresults (optional)
C3 Allocating requirments (FR) Design specifications (FRAT) C3
feasibility check Requirements verification Inspection plan Review inspection Planning Concept creation and selection (FRA) Test plan (optional) Review testresults
C3 C3
Sales Function structure (F) Confirm planning Manufactoring
All categories Allocating requirments (FR) Design specifications (FRAT - new) All categories
Customer objectives/requirments Requirements verification FMEA Inspection
C2 Manufactoring note
SQAS Application & Design Engineer Inspection Plan Test center
C3 C3 Test plan C2
SQAS Concept creation and selection (FRA) Testresults (optional)
C3 Sales Testresults All categories Verify Quote S P E D R e q u e s t S i g n O f f R e q u i r e m e n t s V e r i f i c a t i o n S i g n O f f D e s i g n V e r i f i c a t i o n S i g n O f f S P E D T r u c k S i g n O f f
Initiation &
Planning
Requirements,
Specification,
Verification & Quote
Detailed design, Verification, validation
plan & design release
Manufactoring,
Inspection and Test
I II III IV
Conclusion and further work
5
Conclusion and further work
5.1 Summary
The analyses of first, the current process and background from SPED of NMHG and second, the quality issues involving SPED designs of the last three years leaded to a couple of causes.
This answered the main research question of the analyses and diagnoses phase:
What is the current status of SPED-Nijmegen, and what kind of quality issues are there?
A simplistic causal model summarises the answer:
Figure 21 Simplistic causal model of quality issues.
These causes are used to improve and redesign the development and design process for SPED. To design such an improved process, a recent described method from Unger and Eppinger, 2011 is used. This method describes a couple of steps to design a customized development and design process. A little adjustment of this method was needed in order to fulfil the range of design request which are involved with the SPED requests.
These risk categories are further used to distinguish the necessary steps and deliverables, which mitigate the risks and reduce the quality problems. As a result of this method an improved process for the SPED is designed and recommended. The most important improvements will be elaborated below.
5.2 Conclusion - main improvements of the process.
The causes formulated in the analyses and diagnoses can be dedicated to the associated risk and uncertainty. These relations and the most important improvements in the process related to the risk and uncertainty are summarised in figure 28 below.
This figure also summarises the answer to the main research question of the solution design phase:
Conclusion and further work
Figure 22 summary of improvement results
The current development process of sped is compared in the development matrix of (Unger & Eppinger, 2011). This can be seen in Figure 23 below. Also the differentiation between the risk categories is shown in this matrix. Category 1 is just slightly different than the current process. Whereas the Categories 2 and 3 are moved more towards a staged process and also have a little more and comprehensive iterations.
Figure 23: Development matrix comparison
5.3 Evaluation and further work for science
In order to fully evaluate de recommended process, this should be implemented and the differences should be measured. This was however not possible in the time available. Below the used method will be evaluated.
Conclusion and further work
The way the method is using the risks to improve and redesign the process model was very satisfactory. This case study was initiated by quality issues, resulted from the design and development process. These quality issues could easily be translated into one of the four risk categories prescribed by the method. The risk identification and prioritizing helps to address these risks to the right steps in the process (stage, iteration and review).
5.3.1 Further work for science
Appendix I. Additional information of the SPED processes
Appendix II - Change propagation in redesign.
Appendix II. Change propagation in redesign.
One of the most difficult issues in redesign is that when a component is changed, it may also change its related components. (Ariyo, Eckert, & Clarkson, 2009). This situation is in the literature called change propagation. The reason why changes propagate is because of the dependency between components (Fei, Gao, Owodunni, & Tang, 2011)
These change propagations can lead to design conflicts. The conflict can occur in three different design domains (Fei, Gao, Owodunni, & Tang, 2011):
• Functional domain • Physical domain
• Manufactory/assembly domain. Functional domain
Change of functional requirements can come from different reasons, examples are: change of customer demands, change of government policies or change for product improvement. (Clarkson, Simons, & Eckert, 2004) Changes to functional requirements can have effects on three aspects of product design.
• Changes have to be verified to make sure the original customer demands stay intact.
• Changes may result in changes of other functional requirements depending on the connections between them.
• Changes will affect physical structures which are constructed according to these functional requirements.
Physical domain
Changes of the physical structure may also affect the three other domains. (Fei, Gao, Owodunni, & Tang, 2011)
• The functional domain. • The physical domain.
• The manufacturing & assembly domain.
Figure 24: Design changes between functional and physical domains.
The impact a change has on a product, or the amount of propagation occurs, is largely determined by three factors: The complexity of the product, the architecture of the product and the degree of change within the product.
Product complexity
In the literature there are multiple views on this term. The key type of complexity from an engineering change perspective is connectivity (Johnson J. , 1995) & (Sosa, Eppinger, & Rowles, 2007). The measure of complexity is given by the linkages between elements and their interactions within a system, as shown above.
Changes to complex products (products with many linkages and interactions between elements) are far more likely to propagate than with changes to more simple products. Also the control of all the relevant parameters and their impacts on each other is more difficult (Fricke, Gebhard, Negele, & Igenberg, 2007). Also other factors such as number of parts, size of the design team and development cost will rise if the complexity is higher (Ulrich & Eppinger, 2008).
Product Architecture
Appendix II - Change propagation in redesign.
Degree of innovation and change
Appendix III. SQ and SPO number overview
Appendix IV - Instructions methods and tools.
Appendix IV. Instructions methods and tools.
In this appendix several recommended methods and tools and strategies are further discussed and explained.
IV - 1. Pre SPED request strategy
In the analyses of the SPED designs can be seen that curtain types of request occur more frequent then others. To get a fast response and still doing all the steps described in the customized development process. Work can be done before the request comes from the dealer/ sales department.
The first stage of the process can already be prepared by creating a library of Product requirements documents including Requirements lists, FAST diagrams and FRAT documents. This library can be built beginning with the most common requests, focusing on their needs, objectives and functions. The place and kind of storage used and the search ability to find these is important for the reuse of this stored knowledge.
There might also be software on the market which makes is easy to create such libraries. When implementing the process a research towards possible software could be useful
To start fast and easy the software from Microsoft office can be used. (Words, Excel, Access, Visio) Also web based could be an option. This totally depends on the specific knowledge of the software and resources available.
It is also important for the reuse of these libraries / templates that the three parts of the process are hold together. This concerns: Requirements list, function diagram (FAST) and FRAT (requirements mapping document). When these documents are reused and only the FRAT is used to start the development process the origin of the requirements and specifications may not be known and/or requirements can be missed.
The recommended steps for preparing the requirements phase.
1. Begin with the basic truck in mind and make a general FAST diagram of the Truck.
2. Take a frequent occurring category of SPED requests in mind and think of the main function(s) needed to fulfil the needs objectives and functions required. This is the start of the FAST diagram.
4. Expand the FAST diagram up to the level of concepts/solutions.
5. Use the checklist and other information sources to complete the requirements list and FAST diagram
6. Map the requirements to the functions in the FRAT document. 7. Iterate step 3 to 6 until all the requirements are included in the FRAT.
8. Store the documents together in one map. (Make logical mapping structure and numbering, the mapping structure can be seen as real library with rows, shelf’s, books etc.)
Appendix IV - Instructions methods and tools.
IV - 2. Product requirements list
ID Type Description (Shall, Should statement) from/referenceOriginate TypeVER.
Primary requirements
1 Functional
1.1 The area behind the truck shall be illuminated Customer D 1.2 The Illumination direction shall be adjustable Customer D 1.3
The light should be automatically activated
when dark Customer
1.4 Customer D
2 Performance
2.1
The work light shall have enough power to
illuminate up to 10m behind the truck self A 2.2
The light direction shall be adjustable for about
20 grades? up and down self D
3 Interface
3.1
A on/off/auto switch shall be available in the
cabin customer D
3.2
The light shall be provided with enough
electrical power self A
=B15 Secondary requirements
4 Environmental
4.1
5 Reliability / durability
5.1
The light shall be protected to support reliability & durability targets.(from possible external
impacts) Frat library T
5.2 The light shall be shock proof Frat library T 5.3 The light shall be water proof (IP66) Frat library T 5.4 The light shall be dust proof Frat library T
6 Safety
6.1
7 Physical
7.1
The illumination color of the light shall be warm
white (temperature(2700 - 5700 K?) customer A
IV - 3. Requirements checklist and information management.
To support the requirements analyses (Brace & Cheutet, 2012) developed a framework. In this framework also a requirements checklist is used. See Figure 25 for a model of this checklist.
Figure 25 - Requirements checklist structure by (Brace & Cheutet, 2012)
Appendix IV - Instructions methods and tools.
Table 3 Requirement categories
# Requirement category class Description
1 Functional Primary Define what functions need to be done to accomplish the objectives/needs
2 Performance Primary Define how well the functions need to perform
3 Interface Primary Define the interface requirements. (human machine and between systems) 4 Reliability / durability secondary The ability of a system or component to perform its required functions under stated conditions for a specified period of time. 5 Safety secondary Define what specific Safety requirements are needed or affected
6 Physical secondary Dimensions, heights, ground clearance, colours, labels etc.
7 Environmental secondary specific for the application
8 Legal /standards secondary Define which legal or standards are required concerning this design. 9 Manufacturing tertiary Special manufacturing(the actual manufacturing of the parts.) requirements which need to be dealt with
10 Assembly tertiary Which assembly requirements need to be dealt with
11 Transport tertiary Which transport restrictions/requirements need to be accounted for? 11 Service / Maintenance tertiary Requirements related to the service of the truck/component.
12 Other tertiary Requirements not corresponding to the above mentioned types
Information management
IV - 4. Functional Analyses and System Technique
The figure below is an example of a FAST diagram (customer orientated), from a working light. The FAST method is an example of a functional analysis, many other slight different method exits to perform these analyses.
Figure 26 Example of a FAST diagram
Provide illumination behind the truck
Switching lights (on/off)
Manual switch light Automatic switch
light Adjust direction lights
Adjust verticaly Adjust horizontaly
Protect light
Provide waterproof sealing Protect against dust
Provide dustproof sealing Clean lamp cover
from dust Protect against
shocks Protect against
objects Transform energy Provide electrical power
Appendix IV - Instructions methods and tools.
IV - 5. Concept creation and selection
Two examples methods to use in this step are described.
Morphological chart
A morphological chart is used as a method to create a matrix of possible solutions. These solutions are based on the functions structure. In the first column the sub functions are listed with possible solutions in the corresponding row. These solutions are often based on earlier design or known concepts.
Pugh’s selection method (datum)
IV - 6. FRAT
Appendix IV - Instructions methods and tools.
IV - 7. FMEA
Failure Mode and Effect Analysis (FMEA) is a proven method for analysing risk, and taking action to reduce the risk. A FMEA is used as a system reliability study, by reviewing all the components assemblies, and subsystems to identify failure modes, and their cause and effects. The results are documented on a specific FMEA worksheet. There are different variations of these sheets, an example of a FMEA worksheet is shown below. Much literature is written about FMEA and their variations. A thorough explanation of the FMEA method and how to use it can be found in a book from Stamatis; Failure mode and effect analysis: FMEA from theory to execution, (Stamatis, 2003).
FMEA worksheet
# Functions, systems Potential Failure mode Potetial failure effects SEV Potential Causes OCC Current Control DET RPN recommendedActions Responsibility Actions taken SEV OCC DET RPN
1 2 3 4 5 6 7 8 9 10 Action Results
Bibliography
Ariyo, O., Eckert, C., & Clarkson, P. (2009). Challenges in identifying the knok-on effects of engineering change. International journal of design engineering(2), 414-431.
Awny, M. (2006). Product development strategy: a perspective of enterprises. International Journal
of Product Development, 3(2), 143-151.
Brace, W., & Cheutet, V. (2012). A framework to support requirements analysis in engineering design. Hournal of Engineering Design, 23:12, 873-901.
Bstieler, L. (2005). The moderating effect of environmental uncertainty on new product development and time efficiency. Journal of Product Innovation Management, 22(3), 267-284.
Bytheway, C. (1971). The creative aspects of FAST diagramming. Save Proceedings, 301-312.
Clarkson, P., Simons, C., & Eckert, C. (2004). Predicting change propagation in complex design.
Journal of mechanical design, 126(5), 788-797.
Cooper, R. (2001). Winning at new products: Accelerating the process from idea to launch (3d ed.). MA: Perseus Booka.
Cooper, R. (2008). Perspective - The Stage-Gater Idea-to-Launch Process-Update, What's New, and NexGen Systems. Journal of Product Innovation Management, 25; 213-232.
Cooper, R., & Edgett, S. (2008). Maximizing productivity in product innovation. Research Technology
Management, 51(2).
Cross, M., & Sivaloganathan, S. (2005). A methodology for developing company-specific design process models. Journal of Engineering Manufacture, 219(3), 265-282.
Culverhouse, P. (1995). Constraining designers and their CAD tool. Design Studies(16), 81-101. Dixon, L. A., & Colton, J. S. (1998). An anchoring adjustment process model for redesign. Journal of
engineering design, 9(4), 297-314.
Dym, C. (1994). Engineering Desig: A Synthesis of Views. Cambridge: Cambridge University Press. Fei, G., Gao, J., Owodunni, O., & Tang, X. (2011). A method for engineering design change analysis
using system modelling and knowledg managment techniques. International journal of
