Go to the table of contents.

Previous ...


2.1 Process oriented approach to product development control

One key difference between a manufacturing process and a product development process is that the manufacturing operation most often deals with a refinement flow of physical artifacts whereas a product development process is a process of information transformation. In manufacturing control methods the physical artifacts play a central role. This implies that if a manufacturing control approach is to be adapted to a product development process, we need to identify something that can play the same role for a product development process as the physical artifacts do for the manufacturing control approach. Since the subject of refinement in a product development activity is information about the product, the assumption is made that an adapted control approach will need and use information in a product model as a key enabler. Therefore, the problem can be sub-divided into two major focus areas.

The first focus area aims to identify the main information elements (including their relations, behavior, and lifecycles) in an adequate product model. An adequate product model must be defined in such way that it can fulfill the requirements of being the enabler for the application of an adapted control approach as described above. The second focus area aims to identify an appropriate manufacturing control approach that can be adapted to a product development system. In this adaptation the intention is to use this product model in order to define, describe, and evaluate a flow-based control approach for product development. The research work presented in this thesis is limited to concerning itself with the first focus area and with the selected sub-focus on improving the ability to represent high variety, modular, and platform-based products in all life cycle phases of the product.

2.2 Product development responsiveness

In this context responsiveness of product development is defined as the time an organization spend in discovering a new need or opportunity for a product until this need or opportunity is met by having the product available for the customer. To discuss product development responsiveness here the development of a product will be illustrated as a journey through an information landscape. For a completely new product this journey starts in a landscape with many opportunities, but also with many uncertainties, unknowns. As the journey continues information is generated and decisions taken. However, in these early phases of the journey there is most certainly still a lack of some pieces of information and also some contradictory pieces of information. This can be characterized as a state of incomplete & inconsistent information (illustrated to the left in Figure 1). As the development process progresses, more and more information is gathered and contradictions are eliminated through the evolving sequence of design decisions (the elimination of contradictions and reduction of uncertainty is illustrated by the solid blue lines in Figure 1). At the end of the product development process the information and the corresponding design must be complete and consistent (illustrated to the right in Figure 1) in order to ensure product quality and conformance with requirements and to afford successful operation of business processes that depend on this information for their operation (e.g. manufacturing). With the assumption that this kind of information refinement funnel adequately describes the characteristics of a product development process some interesting observations can be made. A frequently stated objective is to reduce the lead-time of the product development process. It is reasonable to believe that the quality delivered should not be compromised, i.e. the requirements for reaching a complete and consistent state are the same. It is further reasonable to believe that the starting points are similar in terms of uncertainties and incompleteness. The objective of shortening the development time is illustrated in Figure 1 by to the right. With the assumptions given above, the only way to achieve this is to increase the rate of convergence in the acquisition of information and elimination of inconsistencies and contradictions (illustrated by and the dashed blue line in Figure 1). With the experience that most traditionally used IT systems require quite complete and consistent data input the figure further illustrates that this support is mainly adequate in the later phases of product development. This contrasts with the ambition to shorten the product development process, which has been shown to require an increased rate of convergence that is mainly achievable in the early phases. Therefore, IT systems capable of dealing with incomplete and inconsistent information are more suitable for improving the product development process than traditional systems that require complete and consistent data input.

Figure 1: Illustration of information refinement in product development.

It should also be noted that not all activities during a product development process strive to converge the information funnel. In many activities in the innovation and design process new alternatives are generated before evaluation and choices are made. The generation of alternatives is a divergent process: the number of information elements increase and so does the possibility for inconsistency among these elements. Evaluations of different kinds are performed using defined clusters of the available information in order to enable a selection between several possible design decisions. Selection is a convergent process: the number of active information elements is reduced and most probably are also the number of remaining inconsistencies. This pattern of divergence followed by convergence is concurrently executed among the many parallel design and development teams and also on several levels of abstraction in the different sets of information that are used to describe the emerging design solutions. The pattern is furthermore iteratively executed in order to successively refine the evolving product design.

The ability of the supporting information systems to deal with incomplete & inconsistent information will determine how early they will be capable of providing support to the development process. Many current information systems require complete and correct data input and are therefore less useful when the available data is uncertain and incomplete. Even though these systems really do not have capability to support the early phases, they are still put to use through different workarounds and manipulations. However, it is doubtful as to whether this is a support to the development process or rather a complication that will require (wasteful) energy to overcome.

Based on the characteristics of the information refinement in a product development process described some observations can be made and conclusions drawn. In order to know whether information is incomplete there is a need for some kind of model showing what is required for the information to be complete. Whether this should be known by a computer-based information system or not is another issue. Further, in order to identify an inconsistency at least three pieces of information are required. First, at least two statements that may or may not be consistent are needed. Second, a third piece of information is needed that there must be some form of criteria capable of evaluating the consistency between the two (or more) statements. This pattern of functionality is not very common in the currently available and used suite of computer-based information systems even though some parametric CAD systems provide this functionality to identify over- and under-constrained parameter sets. It is by far more common to enforce rules upon the user to only enter the one and only piece of (accurate?) information. This approach will severely limit the usability of such an information system to only be supportive in the later stages of a product development process (as illustrated in Figure 1).

The issues described so far in this section are relevant in terms of the responsiveness of a product development process introducing a new product to the market where it will be necessary to travel through most parts of the described information journey. A complementing issue is how the described scenario impacts a platform-based product development. In such a development there is an objective to re-use as much invested capital as possible. Most literature on re-use and commonality concern the re-use of physical parts in several products and product variants. In some cases the re-use of design solution concepts is considered as well. A re-use and commonality approach can however be applied to information that is created in earlier phases of product development as well. Substantial amounts of resources can have been spent in order to optimize, verify, and validate different design solutions. If these are defined and described in a very specific way the consequences might be that information is not available to determine the applicability of the design solutions in a slightly modified context. The effect of such a scenario will be to either define a new design solution or spend resources to modify and reevaluate the existing design solution for the modified scenario. The costs of the inability to re-use design solutions that are defined too specific and with too much detail (i.e. not robust and not adaptable) are twofold: first the actual amount of monetary and other resources required for re-working and re-validating the design solution; second, the time that this effort will require which will directly impact the responsiveness of the product development process.

In order to optimize product development responsiveness, the information sets created during initial product development should be created in such a way that there are several layers of flexible decision points built into the definitions and validations of the design solutions. In doing so, there will be provisions for minimizing the amount of work (and thereby time) required to respond to a slight modification in terms of product changes. Figure 1 can be used to illustrate this in the following way. The need for a new, slightly modified product can be viewed as a request placed on a product development effort entering the funnel from the right side – where a complete and consistent definition of the current product range is available. Now, the shorter the path to the left that is required in order to identify the information and product design change required to provide the new modified product, the more responsive the product development process will be – both in terms of required resources and in terms of timely responsiveness. In a business environment of severe competition it can be argued which of the two (resources or time) is the most important. However, the two are in most cases tightly coupled, rendering the question rather uninteresting.

Figure 2: Order-specification decoupling (adapted from Hansen et al., 2003).

Different kinds of responsiveness depending on industry and types of products are illustrated in Figure 2. Hansen et al. (2003) focused on IT automation of specification processes and introduced the term order-specification decoupling line. This decoupling line separates specifications that are made explicit (developed) prior to an order from specifications created during order processing and fulfillment. This illustrates and provides a complementary and additional perspective on the importance of understanding and addressing how far upstream in the processes of a company a new situation or request from the market or customer must propagate before it can be returned as a responsive action.

2.3 Business environment

2.3.1 Globalization and collaboration

Globalization in the automotive industry is an ongoing process that has been present for a long time. Yet, globalization still presents companies with a number of challenges. One effect of the globalization of automotive companies is a stronger focus to develop derivative products based on a common platform, thereby enabling a greater extent of re-use of different kinds of resources in the products and the processes of developing, manufacturing, selling, and servicing the products (e.g. optimization of spare parts). Development of platform-based products is not a new concept, but many challenges in actually achieving the suggested benefits and efficiency in the products still remain to be solved. Much progress has been made and many contributions from the research community have been presented and transformed into practical use in the automotive industry (Simpson et al., 2006).

2.3.2 Information technology

Another aspect of globalization is the improvements in communication and information technology. Communication improvements are both in terms of physical transportation of people and goods as well as in improvements in information-based communication that is driven by the rapid development in information technology. The emergence of the world-wide-web changed the perspectives on information and communication for all of us. Adoption of the new possibilities offered comes quite naturally to innovative and new industries. To old and well-established industries these new opportunities and paradigms pose a more dramatic request for change.

The automotive industry has been around for over a century and has established many paradigms and an inertia that is challenged by the rapid developments in the world in general and by information technology development in particular. However, this picture is not uniform across all kinds of information technology. In some areas the automotive industry is pushing information technology as early adopters and challenging users of the technology. This is in sharp contrast to other areas where the automotive industry has well-established paradigms and a great deal of inertia in its legacy of using information technology. In some areas there is also a strong coupling between the information technology deployed and the governing paradigm for the business process it supports (or controls). This makes change and adaptation to more effective and efficient utilization of the new possibilities hard or even impossible. One such area with a great deal of inertia is core product representation, where most automotive companies have rather old legacy systems based on a parts paradigm supporting the business. These product description systems have also over time been integrated with interfaces to many central business systems and processes throughout the enterprise and even with external organizations.

A top-level executive in the automotive industry characterized his business as "a momentum business". The statement is interesting since it clearly recognizes the presence of a substantial inertia that needs to be accounted for and managed. When this inertia is in motion in a favorable direction its momentum can be an asset and strength to the company. If, however, the direction is less favorable, the necessary change of direction can present a real challenge.

2.3.3 Mechatronics and software

Another aspect of automotive products that has been subject to change for some time now is in the technological content of the different design solutions. Design solutions in a car tend to move towards increased use of mechatronics and software. This calls for a better ability to run multi-disciplinary development with an increased need for bridging and integration between the engineering disciplines involved. Mechatronics and software have today a central role in automotive products and constitute a large portion of the systems in the products. The rather rapid growth of these technologies continues to introduce new challenges in the automotive industry. Traditionally well-known design methodologies may be applicable to a large extent even to these new design areas and might also be applied to bridge and integrate the engineering disciplines. However, this may not be generally well recognized and understood. It is granted that differences exist, but there are also similarities that deserve recognition and attention. However, the similarities are easily overlooked. Too great a focus on the differences may lead to previously gained experiences and approaches to design and engineering within the automotive industry not being utilized. A failure to map previously gained experiences to new technologies and disciplines will cause the organization to reinvent the wheel. The company is thereby destined to also go through the necessary cycles of failures and learning again. With recognition of this need an important aspect to consider in an integrated product definition framework is that it must be independent of any particular engineering discipline and have the ability to integrate and bridge between the disciplines. The topic of mechatronics and software is also studied by for example Adamsson (2005) who focus on the cross-functional issues involved and Zimmerman (2005) who focus on information modeling aspects.

2.4 Industrial objectives and problems

2.4.1 Business goals and rationale

The automotive industry is characterized by overcapacity in terms of manufacturing capability, leading to a fierce competitive pressure. To be able to provide the customers with up-to-date and competitive products it is important to maximize market flexibility and dynamics – while at the same time minimizing the impact of changes in market behavior. In order to minimize the impact of changes in market behavior it is important to ensure some level of robustness in the business system and its operations. A system that is too rigid is not robust. Any change, no matter how small, will cause breakdown to some degree and this breakdown drives a necessity of rework and corresponding resource consumption in order to maintain business operations. In the context of the research work described in this thesis the focus is on how rigid or robust the company is in terms of its approach to product architectures and product definitions. In order to rapidly respond to market changes in terms of customer preferences and competitor actions it is important to ensure a high degree of flexibility in the business operations and product architectures. These high level business objectives and the means to achieve them are illustrated in Figure 3. The capital letters QLE in Figure 3 represent quality, lead-time, and effective/efficient. Changes in market behavior and customer preferences are hardly things that a company can seek to eliminate. Therefore, the only option is to adapt the business systems to be able to deal as effectively and efficiently with these changes as possible. At the same time it is important to ensure that an increased flexibility and ability to respond to changes in market behavior and customer preferences do not compromise the quality of the products and services delivered. Therefore, it is equally important to ensure that the products and services offered are stable in terms of the quality delivered even if the rate of change in these products and services is increasing.

A modular approach to the product program and architecture is regarded to be a means to achieve the two contradictory goals of market flexibility and product stability. A modular approach is furthermore considered to enable shorter lead-times through its potential to re-use modules among the different products.

Figure 3: Product development objectives.

An exploratory study to uncover the problems, rationales, and goals associated with changes during the lifecycle of a system (product) has been done by Fricke et al. (2000). They describe causes and reasons for changes as well as five strategies to cope with changes. It is concluded that in today’s dynamic business environments, changes are necessary to stay competitive. Their proposal is to make late changes cost-efficient by implementing changeability in the system architectures. Design principles to enable flexibility, agility, robustness, and adaptability in systems and their architectures are proposed by Fricke & Schultz (2006). The presented view includes why, when, and how changeability has to be incorporated into a system’s architecture.

2.4.2 Reusable design knowledge

Platform-based product development is applied as a means to make product development more efficient and responsive. The intent is to utilize common design solutions for several products. With such an approach there is an increased need to be able to re-use the knowledge about the designs. There is also a need to use this design knowledge both in early phases of product development and in the later phases when the products are serviced and maintained. Concepts like PLM, i.e. product lifecycle management, are thus recognized to be enablers that aim to facilitate a more effective and efficient approach to the capturing and management of design knowledge and information. However, although PLM in a broad sense is a key business enabler, the true business impact, future opportunities and present status are not well understood Turesson (2006). From a knowledge management standpoint several analyses claim that only a small fraction of the company knowledge is documented in a reusable, i.e. structured and searchable, way. Most knowledge resides in people's heads or is in the best case documented in unstructured form such as in free text documents. And still the small fraction of knowledge that actually is documented in controlled databases plays so important a role that businesses are completely dependant on these databases for their daily operation (e.g. for materials logistics and control).

One of the reasons why the small fraction of captured knowledge plays such an important role in the business is not because it is so valuable for the business actors but rather because the governing rules and routines established within the business have made these pieces of data important. Of course, this is not the only reason. In many cases the captured information is truly important and valuable – but perhaps only to a smaller sub-set of actors and in a specific phase of a business process. However, it can be argued that these data have then been extended to other phases and business processes to which they are not that important or relevant. It may be the case that this has happened more because of the fact that the data were well-known and well-established rather than because it was the most appropriate data to focus upon and manage.

2.4.3 Part based paradigm

The part based paradigm supported by the legacy IT systems in terms of product description, release management, and MRP (i.e. material resource planning) is the primary linkage mechanism between the company functions such as engineering, purchasing, finance, and manufacturing. A part based paradigm requires very specific information and is therefore subject to frequent changes. Even a small need for a deviation will require a formal change in this paradigm. This is of course relevant in the series production phase and for adequate control of manufacturing operations. It is, however, not particularly supportive in early phases of product development when many uncertainties must be dealt with. The level of detail requested by the supporting systems can not be provided. This leads to two negative effects. New additional processes, behaviors, and piecemeal support systems grow side by side of the core process and support system. Since important data and information are managed in the systems aside of the core process and support system or – in the worst case – not managed at all, the result is a lower level of support and tracking of the progressing development.

2.4.4 Transaction oriented versus state-based

Another important issue is that manufacturing operations and the supporting systems are transaction oriented. Engineering results are made available for manufacturing operations through what is called a release. In most cases such a release is done on a part by part level informing the manufacturing operations that a part is added, replaced by another part, or obsolete. Product development on the other hand is (or rather should be) more state oriented. The reason for the need of a more state oriented support in product development is that there is a need for verification and validation of different kinds and at different levels of detail as well as refinement throughout the development process – from early phases of concept definition and evaluation through the different stages of the development until final verification and validation can be achieved using products produced by the final manufacturing processes. Throughout the development process, however, there are numerous occasions when there is a need to "assemble" a certain configuration of the product or a sub-set of the product to either a virtual or a physical prototype. A virtual prototype can for instance be a set of models selected to represent a certain set of performances of the product as a whole or of a selected sub-set of the product. This particular assembly is a specific state of the product definition and maturity in the development process and all analysis and test activities performed that are based on that state should preferably be related to that state in order to ensure appropriate interpretations of the results achieved.

2.4.5 Conceptual design support

During the conceptual design phase an initial design solution is devised that incorporates all working principles or physical solutions to all the essential features of the problem. The proposed solutions have also been subjected to evaluation to determine that they are acceptable and feasible. The most important design decisions are taken during the conceptual design phase, thereby placing high demands on the designers in this phase. According to Potter et al. (2003) there is unfortunately limited direct support for this synthesis activity (i.e. generation of potential solutions) that is at the heart of conceptual design. This makes the conceptual design phase an area with an opportunity to provide for substantial improvements. Ultimately, the synthesis of solutions is dependent on the creativity, skill and experience of the designer or members of the design team. In addition, given the time and activities necessary to accumulate this experience, it becomes clear why a high value is placed on design expertise - and why it often is in short supply.

A consequence of these factors, and the increased power and availability of computers, has been the growth of research into the possibility of automating the engineering design process. Among the putative benefits of such an automated design tool are the consistent production of quality designs, the ability to retain expertise currently lost when a designer leaves the organization, and the easy duplication and distribution of expertise to remote locations where it is lacking. Since, for many domains, conceptual design is the most difficult phase, the greatest benefit would be gained from a successful automation of this stage. Unfortunately, for most domains, no readily available algorithms exist for performing conceptual design; this means that rarely can it be automated using conventional computer programs. (Potter et al, 2003)

The approach proposed by the research presented in this thesis does however not strive towards an automation of the design process. The purpose is rather to provide an information framework and tools and methods to manage information within the framework in such a way that it supports the engineering designers and design teams in their various tasks. The focus is to provide improvements in terms of support in order to get sufficiently good design solutions rather than trying to automate design tasks and strive for optimal design solutions. Another focus is to try to improve the linkage between the systems level of a complex design and the important "few" details that have a large impact on the system characteristics that are regarded to be of major importance to the success of the system.

Conceptualizing is a creative, cerebral activity (Hitchins, 2003). It is also vitally important: from the concept will spring the design, the development, the product, the business, the industry…. Get the concept wrong, and the ramifications could live on for a long time. A conceptual solution to a problem describes a way of solving the problem. You know you have a conceptual solution only when you can describe at least one other way of solving the problem. The process of conceptualizing a system solution involves: maintaining a high level of abstraction; making as few assumptions as possible; challenging any and all presumptions; identifying obstacles to the solution; identifying alternative ways to overcome obstacles; creating alternative solution maps; modeling alternative solution concepts dynamically; exploring: counterintuitive behavior, reactions from other systems, resource demands, and likely costs; and selecting the "best" conceptual solution, where best may mean any or all of: the simplest, cheapest, best quality, lowest risk, most appealing, most exciting, most needed, and so on.

In defining a concept it is easy to make assumptions that may or may not be valid. Making such assumptions will artificially constrain the solution space. A solution concept describes a way or means by which a solution may be achieved. A system design puts flesh on the bones of the solution concept, creating a description of the concept sufficient to enable its being realized. For a system design (Hitchins, 2003) to be scientifically justifiable, it must be: synthetic, holistic, and organismic; and represented in such a way that its potential ability to solve the problem can be proved or disproved. The first statement suggests that a system design should be seen in the context of other, sibling systems, operating within one or more containing systems; and that the design should reveal sub-systems interacting with each other to create the emergent properties, capabilities, and behaviors necessary to solve the problem. The second statement suggests that a design should be capable of dynamic simulation in a representative, interactive environment.

2.4.6 Mass customization manufacturing

In today’s economy, continuous competition and the dynamic global market have pushed manufacturers to a transition from mass manufacturing techniques toward flexible and rapid response methods, to enable them to deliver products rapidly while keeping costs down. This can mean taking on an approach called mass customization manufacturing (MCM). The goal of MCM is to build customized products even if the lot size is one, and to achieve a customization/costs balance (Pine, 1993). With more fragmented and lower volume markets as well as customer driven products, the product lifecycle is significantly shortened. Traditional mass manufacturing cannot keep up with this pace. Successful manufacturing companies will depend on rapid innovation, rapid production performance, and the ability to quickly respond to changes. This requires highly flexible and re-configurable factories that need to be designed, simulated, and analyzed. To guarantee profits, these companies must support the efficient production of small batch, highly varied, and highly customized products, while keeping costs to the level of mass produced items. The earlier a manufacturer achieves this capability, the stronger the advantage in the marketplace (Qiao et al., 2002). New methodologies and modeling approaches need to be developed to meet the challenges of the mass customization manufacturing paradigm. The relatively rigid product lines and their design methods that are used today are a bottleneck in moving forward to mass customization manufacturing.

Continue ...

Go to table of contents.