The application of case based reasoning to decision support in new product development. R. Belecheanu. School of Mechanical, Materials, Manufacturing ...
Other articles The application of case based reasoning to decision support in new product development R. Belecheanu School of Mechanical, Materials, Manufacturing Engineering and Management, University of Nottingham, UK K.S. Pawar School of Mechanical, Materials, Manufacturing Engineering and Management, University of Nottingham, UK R.J. Barson School of Mechanical, Materials, Manufacturing Engineering and Management, University of Nottingham, UK B. Bredehorst Bremen Institute of Industrial Technology and Applied Work Science (BIBA), University of Bremen, Germany F. Weber Bremen Institute of Industrial Technology and Applied Work Science (BIBA), University of Bremen, Germany Keywords New product development, Simultaneous engineering, Decisioin-support systems
1. Introduction
The area of new product development (NPD) is highly complex and uncertain due to a Abstract demanding environment characterised by This paper describes the increased globalisation and segmentation of application of case based markets, increased levels of product reasoning (CBR) to decision complexity, changing customer needs, and support for design managers and engineers during the early phases shorter product life cycles. These economic of new product development conditions of the industrial environment projects, in a concurrent have led to concurrent engineering (CE) as a engineering environment. The revolutionary approach to NPD, which many paper discusses the rationale of using CBR, emphasising its manufacturing companies have adopted in suitability for ill-defined, response to the ever increasing external unstructured problems, in demands (Paashuis and Boer, 1997). comparison with traditional The most valuable benefits of CE are knowledge-based systems. The overall research approach is improvement in product quality, and lower presented, the importance of case time and cost (Wheelwright and Clark, 1992). collection, case base In order to achieve them, a multi-fold maintenance and user training is implementation strategy has to be considered highlighted and the pre-requisites for effective use of the system are (Swink, 1997). In this strategy, one of the discussed. Finally, the benefits central concepts is the simultaneous and costs of the CBR system, as evaluation of multiple aspects of the product perceived by the user companies, design (e.g. manufacturing cost, quality, are discussed. The experimental reliability, serviceability, etc.), which nature of the approach is emphasised and it is shown that increases the complexity of the design the industrial environment for process. For the design managers and which the system is designed and engineers to be able to operate effectively, it in which it is used has great is absolutely essential that there is continued bearing on its capability. availability of up-to-date, high quality information (Court et al., 1997) and appropriate mechanisms to support the decisional process. However, in early stages this requirement is often unmet and decision makers have to rely on incomplete, low quality, or inconsistent information (Belecheanu et al., 1999), or on personal experience (Walsh, 1992). Uncertainty and Integrated Manufacturing difficulty of their decisions are also fostered Systems
by the lack of information on the impact of design decisions on downstream activities like manufacturing and service, because this information is not systematically recorded. If uncertain information were complemented with relevant information derived from similar past recorded situations, activities would be able to start processing earlier and increase the degree of parallelism (Gerhart and Zimmermann, 1999). Another core concept of CE is the crossfunctional team. In CE projects, multidisciplinary teams work in parallel on product and process design and start to integrate suppliers and customers at a very early stage of product design. Significant amounts of co-operation and co-ordination within and among these teams is usually required, and making good, irreversible joint decisions becomes a complex task. Therefore it becomes important to have concurrent access to a common, centralised body of information on aspects like design, testing, production, service. Furthermore, since teams may not necessarily be co-located and/ or may want to consult past project experience for their decision-making, IT becomes an enabler of information and knowledge sharing (Gerhart and Zimmermann, 1999). These issues led the authors to address a specific research question: RQ1. How can past experience enable and support design management decision making in early stages of NPD projects? The answer has been sought in a study carried out within a pan-European research project comprising academic, industrial and commercial partners. The project[1] was
14/1 [2003] 36±45
# MCB UP Limited [ISSN 0957-6061] [DOI 10.1108/09576060310453335]
[ 36 ]
The research register for this journal is available at http://w ww .emeraldinsight.com/researchregisters
The current issue and full text archive of this journal is available at http://w w w .em eraldinsight.com /0957-6061.htm
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
funded by EC and delivered a communication and decision support system for early stages of new product development. This paper focuses on the research approach, technical development and validation of the decision support system. Firstly, the need for design management decision support, based on past experience reuse, is discussed as an emergent conclusion of the engineering design literature survey (Section 2). It is then shown (Section 3) why it is believed that, out of the existing implementation technologies, case based reasoning (CBR) is the most desirable option. The research methodology is presented (Section 4), the processes of defining the user requirements (Section 5), collecting the decision cases and building the case base (Section 6) are discussed, emphasising the involvement and collaboration of the industrial and research partners. Section 7 focuses on technical implementation issues like tool selection, system architecture and search engine features. The final section (Section 8) concentrates on the pilot project case study aimed at testing and validating the system, and highlights the experimental nature of this approach.
2. Decision support in engineering design The domain of decision support in the early stages of design projects was reviewed, in order to compare and validate our approach with other decision support approaches. This review identified that the main existing approach was to support design decisions through formal methodologies, methods and tools that meet the needs of the designer engaged in various industrial sectors. However, this research effort did not find significant application in industry, and it has not become part of what industry accepts and uses as ``best practice’’. Some of the reasons found behind this situation were (Frost, 1999): even though design theories have drawn upon observations of industry, they have become far too abstract to easily provide the pragmatic outcome sought by industry practitioners; in order to be efficiently put into practice, formal methodologies require large amount of data which is either unavailable or difficult and expensive to collect or generate; designers rely far more on experiential knowledge and intuitive appreciation, coming from long hours spent in design, rather than on general methods coming from outside their design scope;
The findings led, on one hand, to the conclusion that experience-based support systems are suitable for design tasks, since a lot of the reasoning which goes into design decisions is empirical. On the other hand, they have revealed lack of support, in terms of practical approaches that capture and capitalise on these real life experiences within companies, in early project stages. These issues were thus in concordance with the authors’ belief that CBR is one of the necessary approaches (solutions) and hence it was further investigated.
3. Case based reasoning Case based reasoning is a problem-solving approach that relies on past similar cases to find solutions to problems (Kolodner, 1993). The CBR principle is based on an analogy to the human task of ``mentally searching for similar situations which happened in the past and reusing the experience gained in those situations’’ (Leake, 1996). The CBR process (Figure 1) can be represented as follows (Aamodt and Plaza, 1994): 1 Retrieve: the system searches and retrieves the case(s) most similar to the problem case, according to a predefined similarity measure. 2 Reuse: the user evaluates it in order to decide if the solution retrieved is applicable to the problem. 3 Revise: if it cannot be reused, the solution is revised (adapted) manually (by the user) or automatically (by the CBR system). 4 Retain: the confirmed solution is retained with the problem, for future reuse, as a new case in the database. Although the CBR cycle is a retrieve-evaluateadapt-learn process, a CBR system may very
Figure 1 CBR cycle
[ 37 ]
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
well implement only the retrieve step, as this is the expression of the concept of reuse of experience. The difference between a database search and CBR retrieval is that the latter employs searching mechanisms that are based on classification and decision tree algorithms, or on assessment of the similarity of cases using predefined similarity measures. As the purpose of this paper is to focus on research issues and pilot projects, the authors will avoid a discussion of these algorithms. This section, instead, will highlight the fact that unlike knowledgebased systems, where the problem solving algorithms are expressed in rules, CBR systems deal with case specific knowledge and do not require that the domain must be modelled in rules. CBR is thus suitable for domains lacking a computational model (mathematical or rule based). In new product development, design management decisions are complex and made under uncertainty. They often have a qualitative, subjective or sometimes unclear argumentation. They are ill-structured. Therefore, experiences are difficult to set within patterns, but easier viewed as distinct cases. For these reasons a CBR approach is more suitable than a KBS approach. Furthermore, in KBS considerable effort is required to set-up a knowledge base, by systematically extracting the rules knowledge from an expert, whereas in CBR systems, entering cases is simpler and can be performed by the users. CBR has been used with most notable results for customer service and help desk applications. In product design and development, knowledge reuse has focused on product data (e.g. case-based system to facilitate reuse of existing part designs (Taner and Fox, 1996; Maher et al., 1995), or managing the assignment of physical structures to the functions of a product (Nedeû and Jacob, 1997), or the integration of the structurebehaviour-function model of product with case based reasoning (Goel et al., 1997). It has been, however, hard to find CBR implementations or studies that investigate the reuse of design and management decision making experiences, from a decision-making process perspective, in the area of new product development. It has also been noticed that the reuse of design experience on the background of the project and organisational environment has been neglected (Busby, 1999).
4. Research methodology The CODESCO decision support system was designed to suit the needs of the industrial
[ 38 ]
partners enrolled in the project. A successful implementation of the decision support tool in a company requires a careful analysis of the design needs and capabilities of the company (Cantamessa, 1999). Therefore, a systematic approach driven by industrial user requirements was adopted for the accomplishment of the research and implementation tasks. The four stages (Figure 2) are detailed in the following sections.
5. Industrial needs and requirements definition The two industrial partners were ThomsonCSF and GDA. Thomson-CSF Texen is a company within the THOMSON Group, and manufactures and maintains real time computer equipment for defence and commercial applications (e.g. rugged computers, radars, avionics display systems, etc.). General Domestic Appliances Ltd (GDA) is a major UK manufacturer of cooking, heating and laundry products. Although they are both acting in highly dynamic markets, they are engaged in developing products of very different complexity, for different operating conditions, on different ranges and for different types of customers (Thomson’s NPD is based on client order, whereas GDA is market oriented). The two companies, with previous involvement in EU research projects, have joined CODESCO with a common need: to achieve structured and systematic decision support for their design projects through a shared repository of past and present design experiences. A detailed review of the companies project management procedures and processes (Weber et al., 1998) identified that there exists a case history of past projects contained in disparate ``data’’ or ``information’’ sources such as project files, databases and most importantly individuals’ memory. Following the identification of user needs, the user requirements have been established (Table I). The main requirement was that the past experience should be presented to the decision maker in a constructive way at the time of making the decision, also indicating the relevance of the information for that particular decision. The information should be accessible and examined by different functions involved in design (marketing, manufacturing, purchasing, service), in order to assess, from their viewpoint, the acceptability of the decision. This further required a client-server architecture of the
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
application, and thus determined one of the selection criteria of the CBR tool. The decision cases would contain contextual information and decision parameters of the decision situation. Thus, the industrial requirements determined the system requirements and imposed constraints on the case collection, tool selection and system implementation tasks.
6. Case base development 6.1 Data collection The user requirements were used as a basis to establish the nature and type of information to be captured from the existing
projects and cases. Thus the case collection concentrated on a set of decision situations requiring support, different for TEXEN and GDA (Table II). Questionnaires, structured and semistructured interviews, focussed workshops and company documentation were used for data collection. The data collection involved project managers, design/development engineers, production, and quality engineers. In the first stage, 15 cases from each company have been collected using structured and semi-structured interviews, and these cases have been entered by the researchers into the database, to allow for the start of the system development. Afterwards, more cases have been entered by the users themselves, all
Figure 2 Research and development phases
Table I Main user and system requirements Indu strial use r requirem en t
Im pact on system req uirem e nts
Im ple m entation co nstraints em e rge d
C on structive a nd cons istent rep resentation of th e past d ecision c ase Indicate rele vanc e of in form a tion retrieved P ast inform a tion ac cessib le by all c om pa ny fu nctions C on textual inform ation availab le fo r e ach past dec isio n R etrieval m e cha nism to consider the c om pa ny particu larities D ifferen t type s of decisions spe cific to eac h com pa ny
C ases are structured in a c om m o n form at
C ase co llec tion
C B R too l has to facilita te m easuring C B R to ol sele ction criterion the rele van ce C lien t-se rver archite cture C B R to ol sele ction criterion a nd im plem enta tion in the com pany D iffe rent form a t struc tures for eac h C ase co llec tion an d record ing com p any C B R too l custom isa ble C B R to ol sele ction criterion C ases collecte d from these typ es of C ase co llec tion decision e xperiences [ 39 ]
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
Table II Typical decisions in GDA and Texen G D A typ ical de cisions
TE XE N typ ica l decisio ns
D eta il design issu es P revent m anu facturin g or servic e problem s A nticipate the effects of ch anges in specific ation , inh ouse or supplier design, tooling and m anu facturing M ake o r buy d ecisions T oolin g investm ent decis ions
H ow to solve fun ctio nality problem s Se lec t betw ee n tec hnical solu tions H ow to red uce prod uction costs U se in-hous e expertise or ou tso urce d esign task D esig n p ro duct for autom atic or for m anu al testin g H ow to im prove rob ustness for h arsh e nviron m en ts (e.g. m arine , air)
along the project period (including during pilot projects). The cases have been selected from ongoing projects or projects no older than two years.
6.2 Data analysis The information was then analysed to define a generic decision process that is common to a range of projects. The analysis revealed different types of NPD decisions. The focus of Texen decisions was on risk analysis, cost estimation, determining strategic indicators for the project, team building, and choosing between strategic alternatives. At GDA, with the products made for a mass market the focus was more on marketing and quality issues, tooling problems, cost decisions, identifying technical risks, or more generally choosing between different design or technical alternatives. Therefore distinct databases were created for TEXEN and, respectively, GDA.
6.3 Data structuring Both Texen and GDA cases have been structured in the following format: Problem and context: Problem description (and/or design change and consequences); NPD project when it was identified: main phase and sub-phase; Product affected: product category, subsystem, component; People (functions) responsible for resolution; Company constraints (company policy); Contractual constraints. Solution development: Solution 1, advantages, disadvantages; Solution 2, advantages, disadvantages; . . .; Method of assessment of solutions; Selection criteria; Solution selected. Outcome: Positive and/or negative consequences; How different than expected. The context of the problem contained project parameters, product parameters and constraints within which the solution should
[ 40 ]
be found. Due to the differences between Texen’s and GDA’s in terms of engineering, commercial and cultural environments this information varied and hence the detailed structure varied for the two databases. The solution development section recorded how alternative solutions were developed, how they have been evaluated (in terms of advantages and disadvantages) and why one solution was preferred to the others (i.e. decision parameters). Recording the outcome of implementing that solution, in terms of performance, and positive or negative consequences, was of particular importance for identifying and analysing ``what-if’’ scenarios. The fields in the database have been represented as free text fields (i.e. searching does not consider the meaning of the words, but only the textual description), due to the complexity and variety of decision situations covered and the difficulty of structuring them in greater detail.
7. System implementation 7.1 CBR tool selection The project strategy was to use an off-theshelf CBR tool, to facilitate implementation with the resources available. Therefore, a review of the CBR tools on the market identified 16 suitable tools. An initial screening process, using criteria like reasoning mechanism and speed, customisability of interface, client-server architecture, ability to represent cases collected, etc.), reduced this list down to four potential contenders. Each of these four tools was then evaluated against six criteria and rated using a 0 to 10 scale, with respect to how well the tool satisfies that criterion (0 ± completely unsuitable; 10 ± very suitable) (Table III). The evaluation has been done by the partners responsible for system implementation. They used demo versions of each tool and implemented, with each tool, small examples of building a database and performing queries in order to test the capabilities.
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
The easy reasoner (TER), a product of The Haley Enterprise Ltd, was identified as the most suitable tool for our application. The searching engine of TER (i.e. the indexing and retrieval mechanism required by CBR is implemented in Eclipse, an expert system shell with Clips-like programming language. However, a layer of C libraries is also provided for searching, thus ensuring embeddability. Unlike the other tools researched, TER is not a ``ready-to-use’’ software tool, and therefore requires more application programming effort. The main advantages of choosing TER were that: it allows for an external database in text format (dbf format), to which any other format can be converted using Open Database Connectivity (ODBC) drivers; and it employs text based searching mechanisms, an important requirement since decision cases were recorded using textual information.
7.2 System architecture The system was built around an Internet/ intranet based client server architecture. The
search engine of TER and the C application were located on the server. The C application was run by the applets, as a common gateway interface (CGI) application, in order to execute user queries. The Web server manages the transfer of data between applets downloaded on the client and the CGI application from the server. The database of cases was implemented in MS Access, located on the server and accessed by the applets through dbAnywhere drivers, (for functions like case entering and database maintenance) and by the TER search engine through ODBC.
7.3 TER application development The CBR system solves a query containing information about ``problem and context’’ and returns a list of the `n’ most similar cases (``n’’` is user defined), or cases with similarity less than a user specified threshold. The similarity between two cases is calculated pairwise, between pairs of fields, using the `nearest neighbour’’ (NN) algorithm (The Haley Enterprise, 1997; Watson, 1997). In order to calculate the similarity, two tasks are undertaken. First, an ``index’’ of all the records
Table III Comparison of the four CBR tools selected The E asy R eason er (Th e H a ley E nterprise, Inc.) Score Ability to rep re se nt case s
C O D ESC O case structu re c ould be im p lem ented
R ea so ning dim ension C ++ im p lem e ntatio n and spe ed in creases the spee d
K ate (Aknosoft) Score
C B R -w orks (T ecInno , G m bH ) Sc ore
R eC all (Isoft) Sco re
5
C anno t rep resent case structure for C OD ESC O structure. Kate can not suppo rt adaptation
0
C A SU EL syntax for c ase repre se ntion
3
Fu ll case rep re se ntation pro vidin g com plex ob ject hie rarchy
3
3
Tw o se conds to retrieve a c ase out of 10 ,00 0 case-base on a P C
5
R etrieval in less tha n 1 se cond , out o f app ro xim ately 1 ,0 00 cases
3
Inform ation not availa ble
0
C ustom ization
C , C ++ AP I
5
Also ava ila ble as D LL allow ing integ ra tion in user applica tions
5
R eq uires know le dge o f SM ALLTA LK p ro gram m ing
3
Lib ra ries C /C ++ ca lls fo r em b edd ing your Re Ca ll ap plic atio n into oth er applications
5
D ataba se su pport
Sup ports acce ss to O D B C a nd S QL data bases
3
O pen to data bases (doe s not spec ify w hich one s) for im port/expo rt capab ilities
5
D B 2 , Ora cle , Syba se, G em Stone , O D B C c om pa tible R D B M S
5
C onn ection to R D B M S via O D B C driver
5
P latform s
W in 3.1, 95, N T, U nix
5
W in 3 .1, 95, NT , soon U nix
3
W in 3.1, 9 5, N T, U nix, O S /2, M ac, S ola ris
5
W in 3.1, 95 , N T, U nix
5
P rice
R ET E ++ 1,850 E C U TE R 4 ,00 0 EC U
4
13,875 E C U com m ercial lice nse; 2,313 EC U acade m ic lice nse
1
2 ,3 13 EC U
5
Inform ation not availa ble
0
Tota l scored
25
19
24
18 [ 41 ]
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
in the database is built by generating statistical information. Second, this information is used to determine the cases most similar to the query, using the NN algorithm. The statistical information is determined in the following way: each text field is considered a list of terms (words) and the information in the field is normalised, so that each field contributes evenly to the global distance of two cases. Hence, a weight is determined for each term in the text field of the case (record), and a weight is determined for each term in the text field of the query. These weights make part of the index and are used to calculate a normalised distance between two fields: §k Wik Wk Si ˆ q §k …Wik †2 §k …Wk †2 ; where Wk ± the weight of the k-th term in the query. An important consequence is that the similarity is calculated only from the fields with information. Therefore the results depend on how complete and detailed the query and the cases are. An example of a query with results and similarity indices calculated is shown in Figure 3.
8. Pilot project experiences 8.1 Installation and evaluation The objectives of the pilot projects were to evaluate the system usefulness, and to identify and analyse the changes in terms of concurrent engineering support.
Figure 3 User interface for query and results
[ 42 ]
In the first stage, the system was installed and tested in GDA and Texen. The installation was done using separate Web servers and database servers dedicated to CODESCO, in order to avoid interference with other company business software, due to any potential technical problems. Thereafter, user training was carried out to a small group of project managers and design engineers, who then acted as ``coaches’’ for the rest of the company users. For evaluation, feedback was methodically acquired, through a questionnaire aimed at capturing information on the benefits of the system, suggestions for improvements. In terms of usefulness, the evaluation task revealed that the effectiveness of the system depends critically on two aspects: system’s technical capability and decision maker’s attitude towards the concept of reuse of past experience. The technical capability of the system was evaluated by looking at ``how effective the reuse of previous decision making experience is through the CODESCO system’’. Analysing the user feedback, it has been realised that a quantitative approach for measuring the system effectiveness was not possible. Instead the following qualitative aspects have been considered, based on a similar evaluation for knowledge elicitation methods in engineering design (Stauffer et al., 1991): applicability: how applicable the solution retrieved is for the new problem; efficiency: how much information is in the results, reported to how much effort is required to get it (case entry and query).
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
The pilot exploitation of the software indicated that there are certain factors, characteristic to the user environment, that have important influence on the system’s performance. These factors relate to the case collection and case base maintenance tasks: The company should provide the system with a sufficient number of cases both in the test stage and during the regular use. Otherwise, the inherent risk of CBR ± that the database might not contain the ``bestmatch’’ case for the problem at hand ± would increase. Each case should contain sufficient information, as only non-empty fields are considered for similarity matching. Cases should have temporal relevance (e.g. cases older than five years are unlikely to be useful for the future, especially in high-tech industries, where technology evolves rapidly). Cases should represent decisions with practical relevance, i.e. decisions which, either of a usual type or more particular, required analysis, combined expertise and even creativity (the more creative the cases the better for future reuse). Both successful and unsuccessful cases should be recorded, as avoiding past mistakes is as useful as trying to copy old successes. It has been, thus, observed that the solution applicability is subject to these conditions. Out of these, the first two conditions have often not been satisfied by GDA and Texen, and this situation is also likely to happen again, with other companies. In general, solution applicability is not guaranteed in all situations, hence the system is limited to having an ``advisory’’ role and to suggest a possible solution to the problem at hand. One of the reasons for this is the wide range and complexity of early NPD decisions. Furthermore, there was a risk of sub-optimal exploitation of the system: different users can record same information using different words, which can affect the textual based similarity among cases. The use of a common vocabulary is beneficial in order to avoid equivocal descriptions. Therefore, it becomes a prerequisite that users share a common vocabulary across the company, and that this vocabulary is consistently used in the CBR system. It is also important to note that the user’s attitude towards the concept of reuse of past experience can affect the system’s usage and hence performance. This attitude can be, in its turn, influenced by reluctance to use
others’ experience (Busby, 1999) (especially designers), or by position in the company (e.g. design team member, or design manager) (CODESCO, 2000), or by the type of decision the user is involved in. The pilot projects have run for 11 months, during which between 60 and 80 cases have been entered in each company. After the pilot projects, the companies have reported that they continued to use the system after the pilot projects finished, but refinements were also made in terms of speed and user interface.
8.2 Example The following case illustrates one situation of successful use of the system. An alignment problem of the control knob on electrical freestanding cookers had been identified by the industrial design department. The CBR query contained the following fields: The ``problem’’ field contained ``control knob is inside the control pocket or well as opposed to sitting on top’’, ``identification phase’’ was ``feasibility stage’’, ``product category’’ was ``50cm electric single oven and double oven’’, ``sub-assembly’’ was ``control panel’’, ``component’’ was ``control knob’’. ``Not to compromise appearance’’ was the main ``customer constraint’’. Other constraints were: ``the solution would have to comply with existing tooling’’, ``time was critical to release parts for tooling’’, and ``cost was of moderate importance’’. The CBR system retrieved a list of cases of control knob problems, of which the one rated most similar was ``an alignment problem’’. It had been identified in ``the first prototype phase’’ on a ``gas cooker’’ and recorded as occurring on all products. The case contained one single solution, i.e. ``fixing the control panel to hob pressing which reduced movement of knob and hence solves alignment problem’’. The advantage of the solution was not only that it solved the problem, but also that it had an additional constraint of which the industrial designer had not been aware: a ``Six sigma’’ constraint of a ``1.5mm gap between control knob and its well, with a tolerance of 0.5mm’’. However, the solution had disadvantages: ``cost increased due to extra parts for electrical products’’ and ``assembly cost and time increased, in order to jig the control into the gas rail for gas products’’. The latter drawback was, however, not relevant for the user’s problem (electric product). After using the CBR system, the solution was implemented to the electric cooker as well, and the outcome was satisfactory, but with one inconvenience: the ``Six Sigma’’ tolerance target was not achieved (only 0.7mm
[ 43 ]
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
achieved), but the target was relieved. It has been identified that even though ``Six Sigma’’ was regularly used in design, tolerance analysis was not. More importantly, the users became concerned that there was ``no company record on how capable the existing design processes are’’.
8.3 Impact on the new product development process (a concurrent engineering perspective) The companies have identified a number of benefits from the implementation of the system: It is probably the most notable benefit that the use of CODESCO has raised the awareness of managers and engineers across functions (not only design) in the importance of not only recording decisions, but also in having a structured approach when doing so. This has, in its turn, increased transparency of the company project experiences. The system was Texen’s first experience with a CBR tool. It found it a valuable tool in supporting the exchange of knowledge across projects and saving part of the company memory on a systematic basis, considering that, frequently, employees change jobs inside the organisation or leave the company. It was also shown that an increased availability of design information was made outside the core development team. Since functions like marketing, purchasing, manufacturing, production had had little access to design information prior to system installation, the system contributed to the CE principles, by integrating the mutual projects and functions handled in parallel in the company. It thus helped the project team moving towards a more conducive CE culture. In terms of disadvantages, the companies found that significant amounts of time and training needed to be spent towards documenting and sharing decision experiences in a manner in which others can reuse. Additionally, commitment is needed to maintain and improve the knowledge base. Since the ``return’’ of the system with a small case base (at the beginning) is low, it is recommendable to use incentives for users’ motivation in this task.
environment. The application has addressed the initial research question by showing that CBR can be employed to enable the reuse of engineering knowledge in NPD, but that there are factors which can diminish the system’s performance and acceptability. Based on pilot projects in two large industrial companies, it has been shown that the application of CBR in NPD results in major advantages such as increased transparency of company experiences across functions, active support for systematic facilitation of individual decision-making processes, and facilitates the move towards CE principles. On the other hand, the main disadvantage resides in the fact that the applicability of the solution retrieved is not guaranteed, due to the complexity and fairly wide range of NPD problems. As an experimental approach, the effort has contributed to identifying feasibility conditions. In this respect, the conclusion is that the CBR application to NPD decisions is feasible, but the main danger is that if there is a wide range of decisions addressed (see, for example, Table II), decision cases cannot be classified by CBR using traditional classification algorithms (e.g. decision trees), and hence strong textual retrieval capabilities are required. In this case performance is jeopardised, but minimal conditions for case base maintenance can be employed in order to maintain performance (e.g. sufficient number of cases, complete cases, terminology consistent across cases). Therefore, designing the system has to deal with the trade-off between scope and performance. Furthermore, the paper has shown that the success of such a system, which can be costly to develop and implement, depends also on the willingness of people to use and improve the system on a daily basis. This, indeed, has substantial implications in terms of technical training and support, as well as the need for a clear company strategy for encouraging, motivating and for maintaining the knowledge base.
Note 1 CODESCO: A Practical Communication and Decision Support Environment for Managing Concurrent Product Development (ESPRIT project no. 25455).
References 9. Conclusions The paper has reported on a new type of application of CBR, i.e. to support NPD decisions in a concurrent engineering
[ 44 ]
Aamodt, A. and Plaza, E. (1994), ``Case-based reasoning: foundational issues, methodological variations and system approaches’’, AI Communications, Vol. 7 No. 1, pp. 39-59.
R. Belecheanu, K.S. Pawar, R.J. Barson, B. Bredehorst and F. Weber The application of case based reasoning to decision support in new product development Integrated Manufacturing Systems 14/1 [2003] 36±45
Belecheanu, R., Haque, B., Pawar, K.S. and Barson, R.J. (1999), ``Decision support methodology for early decision making in new product development ± a case based reasoning approach’’, in Wognum, N., Thoben, K.-D. and Pawar, K.S. (Eds), Proceedings of the International Conference on Concurrent Enterprising (ICE’99), The Hague, 15-17 March, pp. 111-19. Busby, J.S. (1999), ``The problem with design reuse: an investigation into outcomes and antecedents’’, Journal of Engineering Design, Vol. 10 No. 3, pp. 278-96. Cantamessa, M. (1999), ``Design best practices, capabilities and performance’’, Journal of Engineering Design, Vol. 10 No. 4. Court, A.W., Culley, S.J. and McMahon, C.A. (1997), ``The influence of information technology in new product development: observations of an empirical study of the access of engineering design information’’, International Journal of Information Management, Vol. 17 No. 5, pp. 359-75. Frost, R.B. (1999), ``Why does industry ignore design science?’’, Journal of Engineering Design, Vol. 10 No. 4. Gerhart, V. and Zimmermann, H.-J. (1999), ``An information system to manage information in concurrent engineering’’, in Chawdhry, P.K., Ghodous, P. and Vandorpe, D. (Eds), Advances in Concurrent Engineering (CE99): Proceedings of the 6th ISPE International Conference On Concurrent Engineering, 1-3 September, Bath. Goel, A.K., Bhatta, S.R. and Stroulia, E. (1997), ``KRITIK: an early case-based design system’’, in Maher, M.L. and Pu, P. (Eds), Issues and Applications of Case-based Reasoning to Design, Lawrence Erlbaum Associates, Hillsdale, NJ, pp. 87-132. (The) Haley Enterprise (1997), The Easy Reasoner Reference Manual, #1990-1997. Kolodner, J. (1993), Case-Based Reasoning, Morgan Kaufmann Publishers, San Mateo, CA. Leake, D.B. (1996), ``CBR in context: the present and future’’, in Leake, D., Case-Based Reasoning Experiences, Lessons and Future Directions, AAAI Press/MIT Press, Menlo Park, CA. Maher, M.L., Balachandran, M.B. and Zhang, D.M. (1995), Case-Based Reasoning in Design, Lawrence Erlbaum, Hillsdale, NJ.
Nedeû, C. and Jacob, U. (1997), ``A case-based reasoning approach towards learning from experience connecting design and shop floor’’, Computers in Industry, Vol. 33, pp. 127-37. Paashuis, V. and Boer, H. (1997), ``Organising for concurrent engineering: an integration mechanism framework’’, Integrated Manufacturing Systems, Vol. 8 No. 2. Stauffer, L.A., Diteman, M. and Hyde, R. (1991), ``Eliciting and analysing subjective data about engineering design’’, Journal of Engineering Design, Vol. 2 No. 4. Swink, M.L. (1997), ``A tutorial on implementing concurrent engineering in new product development programs’’, Journal of Operations Management, Vol. 16, pp. 103-16. Taner, B. and Fox, M. (1996), ``Constraint-based retrieval of engineering design cases’’, available at: www.ie.utoronto.ca/EIL/public/ aid96/cbret1.html Walsh, V. et al. (1992), Winning by Design, Basil Blackwell Publishers, Oxford. Watson, I. (1997), Applying Case-Based Reasoning: Techniques for Enterprise Systems, Morgan Kaufmann, San Francisco, CA. Weber, F. et al. (1998), User Requirements Definition, CODESCO Deliverable D11, ESPRIT Project No. 25455. Wheelwright, S.C. and Clark, K.B. (1992), Revolutionising Product Development, The Free Press, New York, NY.
Further reading Bredehorst, B. and Weber, F. (Eds) (2000), CODESCO ± The Final Report, Bremer Schriften zu Betriebstechnik und Arbeitswissenschaft, Band 31, Verlag Mainz, Aachen. Corrall, S. (1998), ``Knowledge management: is it our business?’’, Ariadne, The Internet Magazine for Librarians and Information Specialists, November. Gascoigne, B. (1995), ``PDM: the essential technology for concurrent engineering’’, World Class Design to Manufacture, Vol. 2 No. 1, November, pp. 38-42. Klein, R. (1998), ``A knowledge level theory of design and engineering’’, in Proceedings of the Tenth International IFIP WG 5.2/5.3 Conference PROLAMAT 98.
[ 45 ]
