1. INTRODUCTION
A product configurator is a software-based expert system (or knowledge-based system) that supports the specification of customized products by providing design choices to the users while restricting how different components and properties may be combined. For many engineering-oriented companies, the use of product configurators has produced a range of benefits that includes shorter lead times, improved quality of product specifications, preservation of knowledge, use of fewer man hours for product specification work, less routine work, improved certainty of delivery, and less training time for new employees (Forza & Salvador, Reference Forza and Salvador2002, Reference Forza and Salvador2007; Ardissono et al., Reference Ardissono, Felfernig, Friedrich, Goy, Jannach, Petrone, Schäfer and Zanker2003; Hvam, Reference Hvam2004; Hvam et al., Reference Hvam, Mortensen and Riis2008). In contrast, many configurator projects fail, because the configurator is never fully developed or it fails to provide the intended support. In this context, one of the biggest challenges is to define the information that forms the basis for the knowledge base of the product configurator (Sabin & Weigel, Reference Sabin and Weigel1998; Hansen, Reference Hansen2003; Edwards et al., Reference Edwards, Hvam, Pedersen, Møldrup and Møller2005; Hvam et al., Reference Hvam, Pape and Nielsen2006, Reference Hvam, Mortensen and Riis2008; Forza & Salvador, Reference Forza and Salvador2007; Haug & Hvam, Reference Haug and Hvam2007).
Much of the recent product configuration literature claims or at least strongly indicates that the difficulties of creating the necessary definitions of what to implement into a product configurator can largely be explained by the “tacit knowledge” of relevant product experts. However, these explanations are often confusing because there is no general agreement as to exactly what tacit knowledge is (Gourlay, Reference Gourlay2006), and because the configuration literature seldom defines how the term is used or gives concrete examples of what the term refers to. This represents a problem for configuration research, because a basic premise for healthy discussions of product configuration is agreement on the meaning of the applied terms and concepts. It is problematic that product configuration research applies the term tacit knowledge to a variety of different meanings, because theories and studies that apply this term can be interpreted in multiple ways. For example, an unfortunate consequence of this could be in the context of creating methods for dealing with tacit knowledge in configuration projects. In this case, such methods would be fundamentally different depending upon whether the term tacit knowledge is to be understood as only “inarticulable knowledge” or includes “readily articulable knowledge.” On a more general level, the importance of the clarity of concepts is highlighted by the philosopher of science, Roy Bhaskar. Bhaskar basically argues that, where measurements and quantitative methods make good sense within the natural sciences, the same is not true in the social sciences where objects are based on meaning and concepts. Therefore, he suggests that in social science the clearness of concepts should have the same status as the exactness of measurements has in natural science (Bhaskar, Reference Bhaskar1998).
To deal with the lack of clarity of the meaning of tacit knowledge in the configuration literature and the role of tacit knowledge in configurator projects, this paper answers two important questions. What are the consequences of the current usage of the term tacit knowledge in the configurator literature? How relevant is tacit knowledge in configurator projects? In addition to providing answers to these questions, this paper provides a recommendation of how to use of the term tacit knowledge in future configuration literature and an alternative explanation of the real problems describing what to implement into a configurator. The latter is supported by interviews with five configurator project knowledge engineers. Finally, a limitation of this paper should be noted. Because the term tacit knowledge is used in many other fields of research, at least in principle, different definitions may be useful in different contexts. Therefore, the discussion of tacit knowledge in this paper is limited only to knowledge acquisition in relation to the creation of product configurators. However, the contributions of this paper would most likely also apply to research concerning many other types of expert systems or knowledge-based systems.
2. RESEARCH METHOD
To answer the questions in focus, the paper goes through four steps. First, general literature on tacit knowledge is summarized in order to clarify the meanings attributed to tacit knowledge. Second, the configuration literature that uses the term tacit knowledge is reviewed. The purpose of this review is not to produce a complete picture of the use of the term tacit knowledge in the configuration literature, but merely to show that this seems to be a commonly encountered phenomenon. Third, the use of the term tacit knowledge in the configuration literature is analyzed. More specifically, it is deduced which meanings are attributed to the term tacit knowledge in the configurator literature and the following is discussed on this basis: if this use of the term is reasonable, the relevancy of tacit knowledge in configuration projects and the correctness of the assumption that tacit knowledge is something that is almost by definition difficult to deal with in a product configuration context.
Fourth, an evaluation of the arguments made in the preceding discussion is performed with empirical studies. More specifically, the knowledge engineers (those people responsible for the acquisition of information from product experts) of five configurator projects were interviewed. The five cases were chosen because of the relatively high complexity of the products in focus and the long project duration, because it seems that the chance of encountering problems caused by tacit knowledge would be higher in such cases. In contrast, in the selection of these cases, the author did not have prior knowledge of the role of tacit knowledge in these projects. The interviews were initiated by letting the interviewees clarify their role in the given project in order to ensure that they had actually been conducting the relevant tasks in the project. Next, the interviewees were asked a set of basic questions related to the projects in which they participated. The answers to these questions are shown in Table 1. The interviews were conducted upon the condition of anonymity, for which reason the companies are designated A to E. In all cases the knowledge engineers held the following responsibilities: acquired the relevant product knowledge, facilitated discussions of the solution space to include in the configurator, and created the diagrammatic models that formed the basis for the development of the configurator knowledge base. Furthermore, in all cases, a configurator was developed and taken into use.
Table 1. Case studies
aAssociated with the specific configurator project.
bOther product experts could supply information indirectly.
cPrimarily focusing on the first years of the project.
After providing basic information about their projects, the interviewees were asked how often they had experienced situations where product experts seemed to possess some relevant knowledge or information that allowed them to perform certain actions but that they could not readily articulate. Finally, the interviewees were asked to describe what they perceived to be the kind of knowledge/information that made the creation of definitions as to what to implement into the configurator the most difficult. In this context, it was emphasized that they should focus on types of knowledge/information that caused problems and not other issues, such as management problems and lack of motivation.
The approach of asking knowledge engineers to evaluate occurrences of different types of knowledge or information is obviously associated with some uncertainty, because such answers build on interpretation. In contrast, it seems reasonable to assume that the knowledge engineers interviewed would be aware during the process of retrieving information from product experts if particular types of problems made the process difficult. This assumption was confirmed by the answers of the interviewees in the sense that they did not exhibit any difficulty in explaining what had been the main sources of the difficulties.
3. TACIT KNOWLEDGE
Although the literature usually agrees upon definitions of the term information as being data combined with characteristics like significance, purpose, meaning, or context, the meaning of the term knowledge is much more controversial. Debates about the nature of knowledge have been a part of the philosophical literature since the classical Greek period and still are to this day. The philosophical discipline of epistemology normally recognizes three main types of knowledge: practical knowledge (knowing how); knowledge of people, places, and things (knowledge by acquaintance); and propositional knowledge (knowing that or factual knowledge). Traditional epistemology is primarily targeted at propositional knowledge, that is, a perception of “knowledge as a disembodied set of propositions about reality that are true for all times, places, and people” (Fuller, Reference Fuller2002).
A classical understanding of knowledge, which can be traced back to Plato's “Theaetetus” (c. 400 BC) and Kant's “Critique of pure reason” (1781), is a definition of knowledge as “justified true beliefs” (Bernecker & Dretske, Reference Bernecker and Dretske2000). This tripartite account of knowledge has been criticized from different angles, for instance by Gettier (Reference Gettier1963), who created counterexamples of this definition of knowledge and implied that many epistemologists thought that he had destroyed the long-standing tradition regarding the correct analysis of knowledge (Bernecker & Dretske, Reference Bernecker and Dretske2000). Despite the criticism, the definition of knowledge as justified true beliefs is frequently found in contemporary management literature, but often with reduced emphasis on the “truth” part (according to Fuller, Reference Fuller2002; Newell et al., Reference Newell, Robertson, Scarbrough and Swan2002).
Others promote a less static and impersonal view of knowledge, such as Tsoukas and Vladimirou (Reference Tsoukas and Vladimirou2001), who provide this definition: “Knowledge is the individual ability to draw distinctions within a collective domain of action, based on an appreciation of context or theory, or both.” For knowledge-based theories of the firm, Spender (Reference Spender1998) concludes that useful theories are less theories of objective entities than sets of contextualized heuristics guiding managers' interventions in their organizations as quasiautonomous systems. Spender therefore argues in favor of a pluralist epistemology, that is, a rejection of the notion of a single reference system in which we can establish truth. In this way, multiple forms of approach, evidence, and reasoning are admitted and several knowledge systems can be applicable in a specific context.
Only in the 1980s did the literature about practical knowledge have a significant impact on the development of society, although the topic had been discussed in the literature for many years before this time. Some of the most important contributions are by Ludwig Wittgenstein, Gilbert Ryle, and Michael Polanyi (Gustavsson, Reference Gustavsson and Hansen2001). In 1949, Gilbert Ryle published the book The Concept of the Mind (republished in 1984), which was to become a central basis for the discussion of practical knowledge. Ryle (Reference Ryle1984) introduces the term knowing how, which is contrasted with the traditional form of knowledge, that is, knowing that. By using knowing instead of knowledge, Ryle emphasizes that knowledge has the character of being an activity.
In the 1958 book Personal Knowledge (corrected and reprinted in 1962 and reprinted in 2002), Michael Polanyi coined the term tacit knowledge and created one of the most important contributions in relation to the understanding of tacit knowledge. According to Polanyi (Reference Polanyi2002), all knowledge has a tacit dimension. To illuminate the concept of tacit knowledge, Polanyi (Reference Polanyi2002) argues that the principle of how a cyclist keeps his/her balance is not explicitly known. Obviously, rules for how to keep the balance can be observed: when a cyclist starts to fall, the cyclist turns the handlebars, resulting in a centrifugal force that offsets the gravitational force, dragging the cyclist down, and so forth. However, this does not fully tell us how to ride a bicycle and can only be used as guiding information. This point is summed up by the often-quoted statement by Polanyi (Reference Polanyi1983, p. 4), “We can know more than we can tell.” Polanyi's use of the term tacit knowledge most often refers to subconscious processes rather than static structures: “Knowledge is an activity which would be better described as a process of knowing” (Polanyi, Reference Polanyi and Grene1969, p. 132).
In the mid-1990s, tacit knowledge began to receive a great deal of attention in certain areas of management research. Tacit knowledge is most often (but not always) defined as being individual and highly difficult or impossible to articulate (Hitt et al., Reference Hitt, Ireland and Lee2000; Nonaka et al., Reference Nonaka, Toyama and Konno2000; Newell et al., Reference Newell, Robertson, Scarbrough and Swan2002; Wiig, Reference Wiig2004). Grant (Reference Grant1996) suggests that the distinction between tacit and explicit knowledge is that “explicit knowledge is revealed by its communication, tacit knowledge is revealed through its application.” Among studies of tacit knowledge, the study by Collins (Reference Collins2001) is one of the most thorough investigations. Collins begins by saying that some scientists can carry out certain experiments while others cannot and points out that one reason may be that unsuccessful scientists lack tacit knowledge. In this context, Collins defines tacit knowledge as “knowledge or abilities that can be passed between scientists by personal contact but cannot be, or have not been, set out or passed on in formulae, diagrams, or verbal descriptions and instructions for action.”
Although the concept of tacit knowledge has been widely applied and discussed in knowledge management literature, there is no general agreement on the definition of the term. In a review of empirical studies of tacit knowledge, Gourlay (Reference Gourlay2006) describes six ambiguities concerning the nature of tacit knowledge:
1. Some perceive tacit knowledge as being only individual, while others see it as being both individual and collective.
2. In general, tacit knowledge is perceived as being acquired through experience, but some suggest that we are biologically predisposed toward certain kinds of tacit knowledge.
3. Although there is widespread agreement that tacit knowledge is acquired through personal contact and observation, some claim that it is acquired with little help from others.
4. Tacit knowledge is claimed to be essential for competent performance, but it is also claimed to be the basis of defensive routines and containing wrong theories.
5. Tacit knowledge is regarded by many as the source of innovative ideas, whereas some claim that the tacit knowledge manifested in traditions is a conservative rather than an innovative force.
6. Some claim that tacit knowledge can be turned into explicit knowledge, while others claim that this cannot be done.
When narrowing the focus on exactly what tacit knowledge is rather than how it emerges or its impact, Gourlay's (2006) review of research reveals that the term tacit knowledge has been applied in three distinct ways: where knowledge could be articulated, where only feelings of tacit knowledge were claimed, and where there was evidence of an action or behavior for which the actors could not account. For the sake of clarity of communication, Gourlay proposes that the term tacit knowledge should only be used with regard to the third category of empirical use: inarticulable knowledge. Gourlay argues that this condition seems to be the only firm ground we have for inferring tacit knowledge, given that it is not otherwise observable and upon the assumption that the behavior in focus is underpinned by knowledge. Furthermore, Gourlay suggests that the issue as to whether tacit knowledge can be made explicit should be reframed in terms of whether functionally equivalent descriptions can be produced. A similar definition has been set out by Cook and Brown (Reference Cook and Brown1999), who, in relation to the explicit–tacit knowledge distinction, argue that “it is important not to mistake using one form of knowledge as an aid in acquiring the other with one form being ‘converted’ into the other. Tacit knowledge cannot be turned into explicit, nor can explicit knowledge be turned into tacit.” Therefore, if someone uses tacit knowledge and thereby gains explicit knowledge, it is not the tacit knowledge that has been made explicit, but new explicit knowledge that has been created.
Collins recently published a book entitled Tacit and Explicit Knowledge (2010), in which he classifies tacit knowledge into three very different meanings:
1. relational (weak) tacit knowledge (things we could describe in principle if someone put effort into describing them),
2. somatic (medium) tacit knowledge (things our bodies can do but we cannot describe how, like balancing on a bike), and
3. collective (strong) tacit knowledge (knowledge we draw that is the property of society, such as the rules for language).
Collins argues that the intermixing of the three kinds of tacit knowledge has been a main reason for the confusion in the past.
The popularity of the term tacit knowledge in management studies from the mid-1990s can largely be attributed to Nonaka and Takeuchi's The Knowledge-Creating Company (Nonaka & Takeuchi, Reference Nonaka and Takeuchi1995), in which they cite Polanyi, among others. However, Tsoukas (Reference Tsoukas, Easterby-Smith and Lyles2003) argues that Nonaka and Takeuchi more or less interpret the term tacit knowledge as “knowledge not yet articulated” in the sense that tacit knowledge is knowledge that awaits “translation” or “conversion” into explicit knowledge. Tsoukas further argues that although such an interpretation has been widely adopted in management studies, it is erroneous because it ignores the essential ineffability of tacit knowledge and reduces it to what can be articulated. According to Tsoukas, tacit and explicit knowledge should be seen as two sides of the same coin, and not as two ends of a continuum, because even the most explicit kind of knowledge is underlain by tacit knowledge. Therefore, it can be questioned if “explicit knowledge” in its pure form is not simply “information” (Stenmark, Reference Stenmark2002).
4. TACIT KNOWLEDGE IN THE CONFIGURATION LITERATURE
Having demonstrated the ambiguousness of the meanings attributed to the term tacit knowledge in the literature, the use of the term advocates that a clear definition of the term be provided in order to understand exactly what is referred to in any given context. However, in the literature that deals with the topic of product configuration, this often is not the case. Examples of such literature are given in the following.
Schwarze and Schönsleben (Reference Schwarze and Schönsleben1996) present an approach for making the product configuration process more customer friendly. They describe the importance of specifications mapping in a configuration context and note that one of the major problems in specifications mapping is that “uncertain, rough and tacit knowledge has to be used.” They do not define the meaning wherein tacit knowledge is used or provide examples of such knowledge.
Tiihonen et al. (Reference Tiihonen, Lehtonen, Soininen, Pulkkinen, Sulonen and Riitahuhta1998) present a method for managing and modelling product families as configurable products. They mention that one of the deliverables when developing product configurators is an explicit configuration model and state that “in relatively common industrial practice the configuration models are only implicitly present as tacit knowledge in product experts' minds or in varied documents.” It is not defined in which meaning the term tacit knowledge is used nor are examples of such knowledge provided.
Fleischanderl (Reference Fleischanderl1999) provides an overview of configurators as tools for knowledge management. Fleischanderl is a rare exception in the configuration literature in that he provides a definition of tacit knowledge, although it is a bit imprecise. He states that “tacit knowledge is in the heads of people and cannot be captured directly.” Fleischanderl claims that “configurators make tacit knowledge explicit by codifying and modeling it in knowledge-bases (e.g., rules) or other parts software systems (e.g., user interfaces).” Fleischanderl also states that “in the spiral of knowledge (Nonaka, Reference Nonaka1991) people should be able to reengineer the knowledge from a configurator's knowledge-base and use it for new tacit knowledge.” Furthermore, Fleischanderl provides some clarification of his perspective on the relevance of tacit knowledge in configuration projects by stating that tacit knowledge is made explicit by being modelled in, for example, rules and user interfaces. However, it can be questioned whether this is, in reality, tacit knowledge that is made explicit when creating rules and interfaces or merely new information that is produced. This issue is debated in the subsequent section.
Suistoranta (Reference Suistoranta2000) deals with structuralization of sale processes for configuration. Suistoranta claims that the “tacit knowledge of experienced sales persons is needed for determining a standard, which in every sales situation is transformed into a customer-specific preference profile.” Suistoranta does not define the meaning in which tacit knowledge is used or provide examples of such tacit knowledge.
Hvam and Malis (Reference Hvam and Malis2001) focus on how complex product models can be documented in a formalized way that considers both development and maintenance. They claim that Danish industry is characterized by many small companies that have traditionally been very adaptive to customer needs and that “product-related knowledge within these types of companies is typically located as tacit knowledge in the mind of the engineers.” They do not define the meaning in which tacit knowledge is used or provide examples of such tacit knowledge.
Frutos et al. (Reference Frutos, Santos and Borenstein2004) propose a decision support system for facilitating design and customer collaboration in the process of selecting product configuration in mass customization environments. They argue that by using this system, “the customer can define rules and provide information that can be used to represent tacit knowledge.” Frutos at al. also claim that “a large part of the knowledge required for product specification has tacit characteristics.” It is not clear which definition of tacit knowledge is used, nor are concrete examples of such tacit knowledge provided.
Møldrup and Møller (Reference Møldrup and Møller2004) focus on the employment of a “change management” perspective for product configuration projects based on experience gained from 12 case studies of product configuration projects. They claim that experts, although well meaning, often provide information that is “incomplete, inconsistent or inaccurate due to forgetfulness, assumptions that further elaborations are not necessary or the difficulties in making tacit knowledge explicit.” They do not provide a definition of tacit knowledge or examples of tacit knowledge in such projects.
Pedersen and Edwards (Reference Pedersen and Edwards2004) investigate costs, benefits, and possible problems of implementing product configurator technology in an organization based on 12 case studies. In relation to one of the cases in their study, Pedersen and Edwards claim that much of the knowledge of the people doing calculations for tenders is tacit. They further argue that a critical problem when defining a product configurator is finding information about the complex products in order to modularize these and that “this information has often been a combination of tacit knowledge in possession of one or very few sellers or has a character of non specified knowledge.” Pedersen and Edwards further mention that the process of making information in the form of tacit knowledge into explicit knowledge “will tidy up in components and versions of products without much commercial relevance.” They do not provide a definition of tacit knowledge or define which part of knowledge related to making calculations is tacit.
Edwards and Ladeby (Reference Edwards and Ladeby2005) present a framework for assessing an organization's readiness for the implementation of configurators based on analyzing data from interviews of 12 companies. They state: “It is imperative to know how and why a sales person or production employee configures a product as they do and document the criteria for choosing one component in favour of another” and “this knowledge is most often tacit, but in order to develop a configuration system this knowledge has to be made explicit.” They also state that tacit process choices are often based on historical coincidence or forgotten reasons and claim that through interviews it can be determined whether product knowledge is tacit or explicit. Thus, in contrast to most such literature, Edwards and Ladeby provide some clarification as to the kind of knowledge in configuration projects that can be of a tacit nature, that is, rules for choosing one component in favor of another.
Skjevdal and Idsoe (Reference Skjevdal and Idsoe2005) present the preliminary results of a study about the advantages and challenges of introducing a product configurator system in a company that produces highly customized products. Based on a literature study, Skjevdal and Idsoe mention “externalization of tacit knowledge” as a potential advantage in introducing a product configurator. They do not provide a definition of tacit knowledge or examples of this type of knowledge.
Heiskala et al. (Reference Heiskala, Paloheimo and Tiihonen2005) analyze the conceptual differences between configurable goods and configurable services. They claim that when dealing with services (as opposed to goods) “information arguably has to flow more frequently between people” and “the intangibility of services often implies tacit knowledge at the customer interface.” A definition of tacit knowledge or examples of such knowledge are not provided.
Zhelka (Reference Zhelka2005) describes how the use of an online product configurator helped reduce costs and shorten delivery times for a company. Zhelka describes the activity of a product data expert as being a definitive example of “tacit to explicit” knowledge conversion, and that the project implied that “the know-how of subject matter experts is converted from tacit to explicit knowledge, and documented in the form of the rules and constraints that comprise each product module.” Zhelka does not provide a definition of tacit knowledge or examples of such knowledge.
Nielsen and Hvam (Reference Nielsen and Hvam2007) analyze organizational challenges associated with the implementation of configurable product models. They claim that “codification and abstraction of knowledge implies that the partially tacit knowledge of the employees in the organization is captured and documented in the form of e.g. diagrams, CRC-cards or other methods” and that “this is often a challenging and complex task as the makers of the product model need to tap into the tacit knowledge and experiences of the employees within new product development and engineering.” They refer to Nonaka and Takeuchi (Reference Nonaka and Takeuchi1995) in the context of mentioning tacit knowledge, but they do not provide examples of tacit knowledge.
Sandberg et al. (Reference Sandberg, Johnsson and Larsson2008) investigate the usefulness of rule-based IT support tools for Swedish prefabricators of domestic buildings. They argue that the knowledge acquired in their study can be divided into “e.g. heuristics (rule-of-thumb), empirical knowledge, tacit knowledge, common sense, logic and geometrical knowledge.” They do not provide a definition of tacit knowledge or provide examples of what type of knowledge this is exactly.
Hvam et al. (Reference Hvam, Mortensen and Riis2008) describe a process for the development and maintenance of product configurators. In the context of the acquisition of the knowledge of product experts for the creation of a product variant master (a diagramming technique for describing generic product structures), they mention that “a process to formalize the silent knowledge possessed by relevant recourse persons is usually necessary” (p. 169). They do not define their applied meaning of silent knowledge or go more into detail about which aspects of the information needed for creating a product variant master are based on the tacit knowledge of product experts.
Cross et al. (Reference Cross, Seidel, Seidel and Shahbazpour2009) focus on the changes that a firm may need to make for the successful implementation of mass customization. They claim that “design departments often know many of the rules and constraints of the factory allowing them to make the majority of designs fall within the factory potential without having to ask the production team” but “this information is often tacit, and requires employees to spend several months at a company to learn.” According to Cross et al., a “configurator essentially automates the design process and allows for all the tacit design information stored in employees' heads to become explicit and made readily available to the customer.” They do not provide a definition of tacit knowledge. However, they do provide some indication of the kind of knowledge that supposedly is often tacit: design rules and constraints.
Having shown that the term tacit knowledge frequently appears in the configurator literature without much explanation of what exactly the term is intended to include, the next section discusses the consequences of this.
5. DISCUSSION
As the review of the configuration literature shows, several researchers have stated or strongly indicated that they believe that the tacit knowledge of product experts is the dominant factor that renders the creation of product configurators problematic. However, there are three major problems in connection with the current use of the term tacit knowledge in the configuration literature:
1. tacit knowledge becomes an ambiguous concept, which does not tell us much about the knowledge in focus and thus may be confusing or misleading;
2. tacit knowledge may not be particularly relevant in configurator projects; and
3. tacit knowledge may not be problematic to deal with in configurator projects.
These three issues are discussed in the following subsections.
5.1. Problem 1: Tacit knowledge as an ambiguous concept
In the configuration literature studied, definitions of the term tacit knowledge are rare and detailed examples are not provided. This poses a problem when building upon existing research, because there is no general agreement upon exactly what tacit knowledge means (Gourlay, Reference Gourlay2006). Much of the investigated literature gives the impression of applying the term tacit knowledge merely to describe something (maybe not even knowledge) that is nonexplicit or unknown, that is, a remainder category. This use of tacit knowledge therefore does not tell us much more about tacit knowledge except that it is something that is not represented in explicit representations of which the observer is aware.
The use of this wide interpretation of tacit knowledge in the configurator literature may be rooted in too much focus on the distinction between tacit and explicit knowledge for explaining why the representation of some product knowledge can be difficult. To be more specific, because only explicit knowledge known by the observer can be categorized as being explicit, there is a danger that many different things are put into the category of tacit knowledge that basically have nothing to do with tacit knowledge, or even knowledge, for that matter. The implications of the use of the term tacit knowledge in the configuration literature are illustrated in Figure 1. These interpretations are subsequently discussed.
Fig. 1. The implication of the uses of tacit knowledge in the product configuration literature.
The first interpretation of tacit knowledge as “needed, but nonexisting knowledge” can include, for instance, nonexistent rules that are necessary for the creation of the knowledge base of a configurator. However, something that does not exist should obviously not be classified as knowledge. Thus, nonexisting knowledge should not be confused with tacit knowledge.
The second interpretation, “explicit knowledge, unknown to an observer,” could be documents that include necessary information that the knowledge engineer (observer) is not aware exists. The reason why the knowledge engineer does not have this information can either be that the relevant people have not been asked or that someone intentionally or unintentionally conceals this information from the knowledge engineer. However, it can be questioned if the ignorance of an observer should be a valid argument for labeling knowledge as being tacit. If so, the tacitness of a particular piece of knowledge becomes a subjective matter and thus difficult to subject to objective measures.
The third interpretation, “knowledge, which can be readily articulated,” is problematic from several perspectives. The use of the concept of tacit knowledge to explain why the creation of product configurators is difficult makes little sense if the knowledge in focus can be readily articulated. In this case, tacit knowledge poses no more difficulty than explicit knowledge. Including readily articulable knowledge into an understanding of tacit knowledge obviously does not rule out that the concept also includes inarticulable knowledge. However, still the implication would be that statements like “much of the relevant knowledge in the configuration project was tacit” become irrelevant within the context of explaining the problems of a configuration project, because this tacit knowledge may have been of the readily articulable form. Thus, to justify the use of the term tacit knowledge in the configuration literature as an explanation of difficulties in the creation of the knowledge base of a configurator, the interpretation of tacit knowledge as including readily articulable knowledge cannot be accepted.
Another and more fundamental problem of the third interpretation of tacit knowledge is that it becomes virtually impossible to distinguish the tacit knowledge that can readily be articulated from explicit knowledge. More specifically, how can a researcher know if the knowledge articulated by a product expert is tacit knowledge or something existing in explicit form in the company? Even if the researcher manages to rule out that the knowledge articulated by the product expert exists in the company in written form, it cannot be concluded that it is not explicit knowledge. The case may just as well be that the product expert has created rules in the mind without ever having articulated these rules, but the expert readily articulates these rules when asked. However, this kind of knowledge is codified in the mind and therefore is a form of explicit knowledge.
The fourth interpretation, “knowledge, difficult to articulate,” implies that the person asked is in some way capable of transforming tacit knowledge into explicit knowledge. This interpretation represents one of the greatest controversies of tacit knowledge: the question of whether (and in what sense) tacit knowledge can be made explicit. In this context, note that there is an important difference between claims of “articulating tacit knowledge” and “making tacit knowledge explicit.” The former formulation tells us something about the nature of tacit knowledge (i.e., that it can be articulated), but the latter formulation in principle only tells us that explicit representations of some tacit knowledge are made without necessarily claiming that these representations capture all of the tacit knowledge or consists of knowledge of the same nature. Because in many cases it is possible to simulate some actions that the one carrying them out cannot fully explain, the controversy must revolve around whether tacit knowledge can be articulated instead of it can be simulated. However, accepting that any tacit knowledge can be articulated has a number of inherent problems.
First, if accepting that any tacit knowledge can be articulated, it is unclear why some knowledge should be difficult to articulate, under the assumption, of course, that it is actually a form of knowledge that can be articulated and that it is possessed by the person in focus (although it may take some time if the knowledge is extensive). In other words, if a person possesses knowledge that is fully articulable, why should this be difficult to express?
Second, the implication of accepting that any tacit knowledge can be articulated, no matter how difficult it is, is that the term tacit knowledge becomes an unambiguous concept. Omitting articulable knowledge implies that some tacit knowledge is actually a form of explicit knowledge, which for some reason is either hard to remember or to actually become aware of. However, because tacit knowledge at least includes deep inarticulable knowledge, tacit knowledge becomes a term used to describe two fundamentally different concepts. Obviously, such use of the term dilutes it and makes it unclear exactly what is meant when the term is used.
Third, the problem of using tacit knowledge in a definition that includes articulable knowledge is that this is not in line with its philosophical roots. As mentioned before, the concept of tacit knowledge has become a popular term in management studies. However, although much of such literature cites Polanyi, it applies the term in another meaning, thus reducing tacit knowledge to something that awaits translation or conversion into explicit knowledge (Tsoukas, Reference Tsoukas, Easterby-Smith and Lyles2003). Tacit and explicit knowledge should not be perceived as two ends of a continuum, but as something of very different natures. Thus, the tacit knowledge itself is not made explicit, but rather simulated or described by explicit knowledge. The difference between tacit and explicit knowledge can be illustrated by the Polanyi bicycle example. To be more specific, what can be explicitly stated about how to ride a bicycle differs from the know-how that is acquired when learning to ride a bike. Therefore, if one tries to explain how to ride a bicycle, this represents the creation of new explicit knowledge based on analyzing what is done when riding a bike, rather than some tacit knowledge that undergoes a transformation. Thus, in order to avoid misunderstandings, this paper argues for a definition of tacit knowledge as being something that cannot be articulated or argues for completely avoiding the term. If using the term, however, there should be a clear distinction between the tacit knowledge that a product expert actually applies and what is represented in a knowledge representation during knowledge acquisition. More specifically, a knowledge representation created in order to describe some tacit knowledge should be perceived as something the product expert or an observer has inferred when trying to explain the actions of the product expert.
Fourth, because the use of phrases like “making tacit knowledge explicit” holds some danger of misunderstanding, this paper emphasizes the importance of exactness in formulations. An obvious solution is to follow the suggestion by Gourlay (Reference Gourlay2006), namely, that “the issue of whether or not tacit knowledge can be made explicit can usefully be reframed in terms of whether or not functionally equivalent descriptions of behaviors can be made.” If to broaden the meaning of tacit knowledge, this paper recommends applying the three classes of tacit knowledge proposed by Collins (Reference Collins2010), that is, weak, medium, and strong tacit knowledge.
Fifth, the last interpretation, “inarticulate knowledge” is knowledge that a person is incapable of articulating, but that allows this person to perform certain actions. That this should be perceived as a form of tacit knowledge should be beyond discussion.
5.2. Problem 2: The questionable relevance of tacit knowledge
Having shown the problems of using the concept of tacit knowledge as a remainder category for explicit knowledge that has not yet been acquired, the next issue to investigate is whether tacit knowledge in its original meaning is particularly relevant in the context of developing product configurators.
Expert systems (including configurators) typically include two main components: a knowledge base and an inference engine (Cawsey, Reference Cawsey1998; Jackson, Reference Jackson1999; Hopgood, Reference Hopgood2000). The knowledge base consists of knowledge/information about the relevant domain, whereas the inference engine uses the content of the knowledge base to answer questions, solve problems, or offer advice. Although there are not very concrete examples of relevant tacit knowledge in the configuration literature, there seems to be some agreement that the tacit knowledge that makes configurator projects difficult is related to the creation of the knowledge base of the configurator. This understanding may be broadened to include knowledge about the relevant design choices (reflected in user interfaces) and rules or methods for calculating various product aspects (e.g., calculation of price, expected delivery), which are sometimes placed outside the knowledge base in other programs.
Note that other types of information need to be defined in order to create a configurator. However, this is information that cannot be said to be something that product experts possess prior to the configurator project. For instance, although the relevant product information is well described, some decisions still need to be made as to what solutions, principles, particular components, and customer choices to include in the configurator. Obviously, such decisions cannot be said to be something that a product expert knows tacitly, because this represents the creation of new information. Another example is the definitions of the user interfaces of the configurator. Because the fields included in the user interface are reflections of the knowledge base, what remains to be defined is related to the layout. Such information is also decisions made, in contrast to something tacitly known before the project. Conversely, information about the existing software systems with which the configurator should interface may be difficult to retrieve. However, as mentioned before, it does not seem that this is what configurator literature is referring to.
Felfernig et al. (Reference Felfernig, Friedrich, Jannach, Stumptner and Zanker2002) describe the representation concepts for modeling generic product structures (to be represented in the knowledge base of a configurator) that are defined in the de facto standard configuration ontologies (Soininen et al., Reference Soininen, Tiihonen, Mäannistö and Sulonen1998; Felfernig et al., Reference Felfernig, Friedrich and Jannach2000) and represent a synthesis of resource-based, function-based, connection-based, and structure-based configuration approaches:
• Component types: “Component types represent the basic building blocks a final product can be built of. They are characterized by attributes.”
• Generalization hierarchies: “Component types with a similar structure are arranged in generalization hierarchies.”
• Part–whole relationships: “Part–whole relationships between component types state the range of subparts an aggregate consists of.”
• Compatibilities and requirements: “Some types of components must not be used together within the same configuration, that is, they are incompatible. In other cases, the existence of one component of a specific type requires the existence of another specific component within the configuration.”
• Resource constraints: “Parts of a configuration task can be seen as a resource balancing task, where some of the component types produce some resources and others are consumers.”
• Port connections: “In some cases the product topology, that is, exactly how the components are interconnected, is of interest in the final configuration. The concept of a port is used for this purpose.”
• Constraints: “The basic structure of the product is modeled using the aforementioned modeling concepts. In addition, constraints which are related to technical restrictions and economic factors can be expressed on the product model.”
If focusing on what information product experts need to deliver in configuration projects in order to create the types of information mentioned above, this could be translated into the following questions:
1. Which components can the product family in focus include?
2. Which attributes does a given component include?
3. Which types of a given component are there?
4. Which subparts does a given component consist of?
5. Which other components are required when using a given component?
6. Which components may not be used when using a given component?
7. Which resources does a component produce or/and consume?
8. Which ports does a given component have and with which ports may they be combined?
9. If not included in the concepts mentioned above, what additional constraints/rules (technical and economical aspects) are there?
The formulation of the relevant questions to be answered in a configuration project further illuminates the problems of using the term tacit knowledge as something that is problematic to deal with in configuration projects, while still perceiving tacit knowledge as something articulable. More specifically, if the relevant product knowledge is readily articulable, the retrieval of answers for the described questions does not seem to be very difficult (except for perhaps the last one). Thus, to claim that tacit knowledge is problematic in configuration projects makes more sense if tacit knowledge is perceived as something inarticulable, which in turn implies that explicit descriptions to simulate this inarticulable knowledge need to be created. However, claiming that relevant product information often only exists in the form of inarticulable knowledge in the heads of product experts also implies at least two major problematic aspects.
The first problem is that it appears that the information in focus in configuration projects is typically of a rather factual character, and something much different from the examples of tacit knowledge mentioned by Polanyi (e.g., the knowledge/abilities needed to ride a bicycle, recognize a face, and play an instrument). For instance, it makes little sense to claim that a product expert tacitly knows that a given component is the color red, weighs 150 g, and runs on 12-V batteries. In this context, it should be recognized that the purpose of a configurator is not to simulate some physical actions of a product expert (such as driving a car, cleaning a room), which in many cases would be extremely difficult or even impossible with our current technology.
Another context in which tacit knowledge may play a significant role is in relation to creative and aesthetic tasks, for example, architecture. Creating a configurator to simulate an architect's work is problematic because it still has not been possible for artificial intelligent techniques to simulate the creative, innovative, and aesthetic aspects of the mind. Thus, except in cases of relatively standardized building solutions or subparts, the use of configurators would most likely not be profitable. The projects described in the literature were also not projects with a focus on this type of knowledge, and so this type of discussion is not particularly relevant in the context of this paper. The basic focus in the context of creating a configurator in the configurator literature is defining the information that can produce specific data output based on a specific data input. In contrast, although tacit knowledge does not constitute the a great part of the knowledge needed in configurator projects, some tacit knowledge may be relevant in the context of certain constraints/rules for how components and attribute values may be or should be combined. However, it still remains to be shown that this is something that frequently occurs in configurator projects and that this represents a problem.
The second problem of explaining problems in configurator projects by inarticulable tacit knowledge is that the information needed in configurator projects would most often exist in various forms of documentation, such as old sales orders, specifications from component suppliers, and enterprise resource planning system data. If so, it is irrelevant if this information also exists in the form of tacit knowledge in the heads of product experts, because it also exists in an accessible, explicit form. For example, in the context of one of a kind products, product experts may be able to produce a quote price, based on experience and without calculations, while not being able to explain how they did this. What allows a product expert to produce prices in this manner may be related to tacit knowledge. However, such tacit knowledge may not be particularly relevant in a configuration project, if more accurate ways of calculating such prices can be constructed. More specifically, the prices of components should be rather simple to obtain from suppliers and by looking at products produced earlier, whereas the cost of operations can also be produced from analyzing earlier projects. Building the configurator on such information probably implies more accurate output than that from the human experts.
Another example is a situation where, based on some customer requirements, product experts are capable of defining a certain product configuration without making calculations. However, once again it is questionable as to whether this knowledge is interesting, because it seems that something more accurate and sharable would be more desirable. In the context of discussing the issue of cases where tacit knowledge may need to be understood, the prevailing view today on the development of expert systems should be noted. In the early 1980s, the development of expert systems was seen as a transfer process with the implicit assumption that the required knowledge already existed and merely had to be collected and implemented. However, today there is overall consensus that the process of building an expert system is better perceived as a modelling activity (Clancey, Reference Clancey1993; Studer et al., Reference Studer, Benjamins and Fensel1998; Speel et al., Reference Speel, Schreiber, Joolingen, Beijer, Kent and Williams2001). In other words, in the expert systems literature there is general consensus that the task is not to copy domain expert knowledge, but to create a model that simulates the domain expertise. Thus, the focus of making explicit representations of some tacit knowledge in many ways represents an obsolete viewpoint, in contrast to a focus on the creation of new knowledge to simulate (or improve) existing knowledge.
There may be several factors that can explain why something appears to be tacit knowledge but in reality is not. First, it appears that much of the information needed to create a configurator does not exist prior to the project. In this context, note that when producing one of a kind products, new information is being created during such a process because the focus is on unproduced product designs. Thus, such information would only be generated when this information becomes relevant, which is, obviously, not the same as it being tacit knowledge. Second, it is easy to confuse poor questioning with inarticulable knowledge. For instance, if asking a product expert “What are the valid combinations for a given product family?” such an expert may not be able to give a full response in many instances, although the expert is fully capable of specifying a product each time customer requirements are received. Thus, this may seem as if the product expert possesses tacit knowledge. However, this is not likely to be a case of tacit knowledge, but rather a case of poor knowledge engineering. Obviously, the knowledge engineer should adjust the questions to something more specific after not getting concise answers, for example, questions like “Can Component A be combined with Component B?” Third, it seems that one of the major challenges is to decide what information to include in the configurator and what information to exclude. However, such decisions should not be confused with tacit knowledge.
5.3. Problem 3: Dealing with tacit knowledge may not be problematic
Based upon the discussion so far, it does not seem that the knowledge in focus when specifying a configurator is much related to knowledge that allows people to perform certain actions without being able to account for these actions, that is, the recommended definition of tacit knowledge. However, it cannot be ruled out that in some cases some tacit knowledge needs to be understood. In contrast, even if tacit knowledge is defined only as being something inarticulable that is revealed by actions only, this may not necessarily be difficult to deal with in configuration projects. For instance, if a product expert cannot account for the entire solution space of the product family in focus, the product expert should at least be capable of telling which choices are made in specific situations, that is, what the product expert can infer from studying his/her own actions. Such relations between input and output would most often be adequate enough to create the rules of a configurator. However, the inferred rules may be incomplete unless a great deal of time is invested in this. Therefore, it may not be the simulation of the tacit knowledge studied that is the problem, but that it may be extremely time consuming to describe the entire solution space.
In contrast, although some knowledge is explicit, it may not be easy to deal with. For instance, in some cases, explicit definitions can contradict each other, such as when different product experts have varying perceptions of what is “the right way of doing things.” Such disagreements may well imply that there will be many corrections to information models that are problematic to solve. Furthermore, explicit definitions may also be problematic when dealing with very complex or specialized information, because the knowledge engineer may not understand this because of a lack of product expertise.
All in all, it does not seem that, even in a strictest definition, tacit knowledge necessarily represents a barrier to the definition of the knowledge base of a configurator or at least it is unclear why. Furthermore, it seems that the use of the tacit–explicit distinction may not be a particularly useful way of indicating if this is difficult; the use of this distinction may actually produce incorrect conclusions.
6. CASE STUDIES
To investigate the arguments made in the previous section, the knowledge engineers of five configurator development projects were interviewed. As mentioned, the interviewees were asked how often they had experienced situations where product experts seemed to possess some relevant knowledge or information that allowed them to perform certain actions, but which they could not readily articulate; and what were the kinds of knowledge/information that made the creation of definitions of what to implement into the configurator most difficult. The answers to the two central questions are shown in Table 2, where the answers retrieved for the second question can be grouped into four categories.
Table 2. Results of case studies
In cases A, B, and C, the interviewees were not certain that they had experienced situations wherein product experts had some knowledge that allowed the product experts to perform certain actions, but that they could not articulate. In all circumstances, this was only perceived to have occurred upon rare occasions. In the other two cases, the interviewed knowledge engineers were rather certain that this had not been the case. Thus, these studies strongly support the criticism made of the use of tacit knowledge as a major explanation for problems in configurator projects. Furthermore, all the interviewed knowledge engineers stated that they frequently had to rephrase questions in order to get the required answers or to be relatively certain that the product expert in focus did not possess the information.
Four different explanations were given on the question of what were the main problems involved in defining what to implement in the configurator. The first category of answers relates to “retrieval of unfocussed information from product experts,” such as issues with making the product experts understand what information is necessary or the knowledge engineer him/herself not being certain of what is needed. In situations where such issues were involved, all of the required information was not retrieved, but much irrelevant information often was.
The second category of answers relates to “retrieval of contradicting information from product experts” and was problematic in four of the cases. The reason for this type of problem is that much of the knowledge/information used for the creation of products is not unambiguous, but may depend upon individual preferences, individual experiences, and particular traditions, and so forth. Thus, the challenge in such a context is often to make product experts agree upon what knowledge to include in the configurator.
The third category of answers concerns that “the product experts did not possess the information needed,” which means that some relevant information did not exist or simply that the interviewed product expert did not possess this knowledge. The problem of nonexistent knowledge was particularly present in project D, where the configurator project was combined with a project of redesigning the products in focus. In contrast, according to this particular knowledge engineer, this was the only major knowledge-related problem in this project. In the other cases, the explanation for product experts not possessing required information was related both to the fact that such knowledge did not exist and that the product expert asked simply did not know the answers.
The fourth category of answers refers to “retrieval of incorrect information from product experts.” In the projects where this problem occurred, incorrect information was not intentionally given to the knowledge engineer (in his perception). It was because of being too eager to answer or not taking the project seriously enough while having too little knowledge about the product aspects in focus.
7. CONCLUSIONS
This paper presented a review of the use of the term tacit knowledge in the configuration literature. The review showed that the term is often used to describe something that is difficult to deal with. Unfortunately, tacit knowledge is not an unambiguous term, but is given different meanings in the literature; and in the configuration literature definitions of the meaning of tacit knowledge or concrete examples are most often not provided. Thus, it is often difficult to know exactly to what the term refers, which implies a danger of misunderstandings when building upon this literature. The paper defined three major problems of the use of the term tacit knowledge in the configurator literature:
1. tacit knowledge becomes an ambiguous concept that does not tell us much about the knowledge in focus and may therefore be confusing or misleading,
2. tacit knowledge may not be particularly relevant in configurator projects, and
3. tacit knowledge may not be problematic to deal with in configurator projects.
In relation to the first problem, it was argued that tacit knowledge can either be interpreted as including articulable knowledge or as only that knowledge that is by definition inarticulable. However, if applying the term to articulable knowledge, it makes little sense to claim that this is difficult to deal with. Furthermore, such use of the term is not in line with its philosophical roots and makes it an unambiguous concept, which has little communicative usefulness in configurator development research. Thus, this paper argues that in a configurator context it would make most sense only to apply the term tacit knowledge to knowledge that is by definition inarticulable. Therefore, the tacit knowledge itself is not transformed, but sometimes functionally equivalent descriptions of behaviors are made. Addressing the second problem, it was argued that tacit knowledge may not be particularly relevant in configuration projects, because the type of knowledge needed seems to be of rather a factual character. Thus, relevant knowledge seems to be something that could most often be found in explicit form or needs to be created relatively independently of the applied tacit knowledge. In relation to the third problem, it was argued that by using a systematic approach it may not be difficult to simulate tacit knowledge in explicit representations. It was also argued that dealing with explicit knowledge cannot by definition be claimed to be easy, because there may be different perceptions of what this knowledge is or it may be difficult to understand this knowledge.
To investigate the arguments of tacit knowledge not being particularly relevant in configurator projects, five cases were studied in the form of interviews with knowledge engineers who had worked on these projects. In three of these cases, the knowledge engineers interviewed answered that situations where product experts had some relevant knowledge, but which they could not articulate, may have occurred, but only on very rare occasions. The remaining two knowledge engineers were convinced that this had not occurred in their projects. The knowledge engineers instead pointed to the following problems:
1. problems of understanding what information is needed,
2. product experts giving contradicting information,
3. product experts not possessing the information needed, and
4. product experts giving incorrect information.
Although the five case studies do not qualify as a basis for generalizing claims about the lack of relevance of tacit knowledge in configuration projects, they give strong indications of this.
The main contributions of this paper were the following:
1. It was demonstrated that most configuration literature uses the term tacit knowledge to describe some sort of knowledge that is difficult to deal with, but it does not provide clear definitions or examples of this type of knowledge.
2. The problems with this usage of the term tacit knowledge were described.
3. A recommendation of how to apply the term in future configuration research to ensure clearness of communication was proposed.
4. Through argumentation and five case studies, it was shown that tacit knowledge does not seem to be particularly relevant in relation to the development of configurators and for which reason a one-sided focus on this explanation is misleading. The focus should instead be more on the four problematic types of knowledge or information discovered through the case studies of this paper.
An important challenge for future configuration research is to further investigate those factors that produce the problems in configurator projects and to clearly define these factors.
Anders Haug is an Associate Professor in the Department of Entrepreneurship and Relationship Management at the University of Southern Denmark, where he also received his PhD. His research focuses on knowledge engineering, information systems, and knowledge management from an industrial perspective. Dr. Haug has published numerous papers on these topics in international journals and at international conferences and has years of practical experience with projects in these areas.
