Dae Beom Kim : An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry

An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry
Dae Beom Kim* Kim Abstract: As the product life cycle shortens, companies focus more on the Time-to-Market strategy to release customer-oriented products in a timely manner. This study proposes the Enterprise-BOM(Bill of Materials) structure which supports the integrated management of product specifications and BOM data in regard to the development, production and sales of products in the automotive industry, and reviews the feasibility of field applications thereof. The proposed Enterprise-BOM may produce unified product data and enterprise-wide sharing of this data. Ultimately, the Enterprise-BOM enables the innovation of communication and information sharing among processes, and accelerates business. Keywords : Product Configuration Management, BOM, Enterprise-wide Data Integration, Enterprise BOM.

INTRODUCTION
In the management environment of the automotive industry, competition is stiffening and broadening; and merging, acquisition and association are actively underway at a global scale due to a saturated market, and surplus manufacturing capacity. The industry is undergoing rapid changes in product diversification to satisfy the customer needs. Under such an environment, the automotive industry is exerting its best efforts to develop a new technologies to speed up business, and secure competitiveness[1]. Information technology enables the innovation of various processes to minimize the time-to-market. As processes are digitalized, the method of developing a car is shifting from physical data to digital information. This has caused a revolutionary change in the communication means used in processes. Figure 1 shows the flow of such change from the viewpoint of process, communication and information as compared to the development of IT. To process innovation focused on digital information to be effective, epoch-making innovation, in terms of information sharing and communication, will be necessary. Product-related data are closely associated with various business functions e.g., product planning, sales, design, part development, production, logistics and cost, across the entire product life cycle. In particular, the data amount to a car is enormous and requires prompt information processing. The communication method based on the traditional hard copy, DB or file per process
* Associate Professor, Division of Electronics, System and Information Engineering, Kangnam University , Korea E-mail : dbkim@kangnam.ac.kr

cannot overcome troubles such as discontinuity in communication, redundancy and reprocessing of information. Just the simple association with the traditional DB, or file, or simple improvements, cannot support the seamless flow of globalized digital information. What is necessary is not simple improvement but innovation in communication and information sharing among processes, that is, communication innovation (CI). To this end, productrelated data first of all should be integrated from the enterprise-wide perspective.

Fig. 1. PI & CI for Business Speed-up Under the customer-oriented production environment, the specifications imperfectly determined at the development stage. Product specifications take diverse viewpoints into account. In the sales and planning department, customer requirements become product specifications; while in the design department, develops technical specifications. In the beginning, specifications vary, so it is not possible to design parts before finalizing the detailed specifications of each area. Even when the product specifications are finalized, design is not started

72

Pacific Science Review, vol.9, no.1, 2007, pp.72-82

until sufficient technical review is conducted. That is, the length of development period for a new product depends on how well such specification information is managed. Therefore, optimization of the product configuration management is a key strategy for securing competitiveness under the customer-oriented production environment. If 30 - 85% of the product information is wrong, it can cause design errors and additional problems[2]. Accordingly, an important challenging faced by companies nowadays is how to control the complexity and accuracy of product specifications. The product specifications are the product characteristics data being used to express the type of a product and manufacturing method thereof[3]. The procedural and business-oriented definition of the product configuration has been conducted and extended in the artificial intelligence area where a product design algorithm is developed[4-6]. The basic principle of the product configuration management is to identify the knowledge necessary to convert the customer requirements into product information which is accurate and complete in terms of commerciality, technology, production and cost effectiveness, and express such information in an official way[7]. It is to systematize the knowledge, procedure, method, etc. of converting the customer specifications to the production specifications. Most studies on configuration management, however, are focused on the subjects [8] regarding the development of software to support product configuration, and those regarding the development of information systems for product family design and optimization issues. For example, the generic BOM concept, creation of product family and Constraint Satisfactory Problem(CSP) algorithm through modularization have been proposed as solutions for product configuration management issues[9-10]. The Generative BOM Processing System which adopts the generic BOM concept was proposed as a method to manage BOM(bill of materials) effectively when the number of final items is large, to manage the various product variants created due to customer requirements[11]. The Generative BOM Processing System does not compose a BOM for each final product, but groups relevant parts together, presents relationships as a source BOM, saves relationships as rules, and creates a result BOM automatically when configuration information is given[12-15]. Most generic BOM systems were designed based on the relational database. As it is difficult for the table structure of a relational database to support the dynamic characteristics and flexibility of the generic BOM, a procedural BOM system based on the programming language structure has overcome such shortcomings[16]. Those studies are the result of the efforts to handle the enormous amount of data resulting from product diversity. When the relationship between

parent and child items is complex under a customeroriented product development environment, it is difficult to draw out an appropriate conversion rule. In addition, it is necessary to reduce the redundancy of similar data, but express the exact structure information of the complex final product. As the BOM depends on the expressed information architecture, it is not possible to create the BOM suitable for a given configuration when the combinations of a configuration are subject to frequent changes or unpredictability[11]. Furthermore, various methods to manage the product information effectively are under study thanks to the development of information technology. Many studies of integrated data management generated in product development, functional improvements of CAD solution, visualization of STEP data, and management of technical documents are ongoing. Even if the PDM system is defined as the system which systematically manages the various information and business processes generated across the product life cycle, which enables sharing and re-creation of product information[17], its function is not sufficient to manage the customer and product specifications and integrate the product specifications with product structure. The necessity for the extended BOM to integrate product-related core data is mentioned here from the enterprise-wide perspective in the automotive industry, and 19 essential functions which the extended-BOM should support are proposed[18]. The conventional studies emphasis on the product configuration management focused on the physical configuration status of products or the result of configuration representation. That is, their targets are the product configuration issues under the environment where the combinations of product variants can be clearly defined in advance. Therefore, the integration of product configuration and BOM data management is necessary to drastically reduce the development period when product specifications are change in the development of customer-oriented products. We research the enterprise-BOM structure - to realize communication innovation (CI) - which integrates the product configuration information with BOM information at an enterprise-wide level. It unifies ways to express products focusing on functional units in development, production and sales of products in the automotive industry, and the enterprise-wide integration of product data. Chapter 2 discusses product configuration management and BOM; chapter 3 proposes the enterprise-BOM system based on the car model, grade, option and color specifications, etc.; chapter 4 deals with simulations per major issue in applying the enterprise-BOM; and the conclusion notes expected benefits and future challenges, etc.

73

Dae Beom Kim : An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry

PRODUCT CONFIGURATION AND BOM MANAGEMENT IN THE AUTOMOTIVE INDUSTRY

Product Configuration Management
Product specifications in the automotive industry are classified into customer specification, design specification, production specification, service specification, etc. The customer specification refers to the clearly defined customer needs. The design specification is a design feasibility review certificate regarding the customer specification. The design specification includes parts lists, plans, assembly drawings, 3D CAD models, lists of tools, bill of materials, weight, production recommendations, quality standards, and user manuals. As a result, a design BOM is created. The production specification is the specification where the parts to be actually produced are selected or modified to be suitable for the production environment via reference to the design specification. As a result, a production BOM is created. For example, the method of processing a piston is chosen from 3 methods -casting, soldering and forging - considering the production load or demand & supply of materials. The service specification is the record of the operation, maintenance and changes of an engine throughout the engine life cycle. There are other specifications per purpose such as a cost specification for cost management, weight specifications for weight management, a knockdown specification for supply of parts to overseas assembly factory, etc. The issues in the product configuration management are discussed from the perspective of specification information management and specification change management as follows. First, from the perspective of specification information management, the vague customer needs which a marketing staff keeps in mind are recorded as memos. As the specification information includes only general outlines, significant technical review is required to convert the customer specification to a design specification. To draw out an accurate design specification, it is essential to review the experiences and knowledge of designers regarding customer needs and specification, relevant data, and the design specifications of the past technical partners. Second, from the perspective of specification change management, a great amount of resources and expenses are required since a design staff cannot identify immediately the changes in drawings and BOM following the change in customer specification and design. If the product configuration is determined only by the combinations of pre-defined parts, it would not be difficult to identify the change in the drawings and BOM resulting the change in the specification. As new drawings are generated due to the

change in specification, however, it is almost impossible for a design staff to find such change promptly and reflect it drawings and BOM; and much time is required because the technical information regarding the past changes in specification is not managed systematically. As the design specification based on the customer specification becomes a design BOM, it is highly possible that wrong data may be generated due to inaccurate configuration management.

Product Structure of a Car

The automotive industry consists of a variety of complex processes, e.g., the design area for bodies, moving parts, engines, chassis, electronic parts, and production areas as well as numerous partners. The product structure of a car has the shape of an hour glass as it has a wide vertical spectrum of specifications for final products, and parts (Figure 2). The final product, a user vehicle is composed of assemblies such as engine, mission, bumper, airconditioner, etc. Assemblies are classified based on specifications. For example, an engine is divided into E1, E2, E3, etc. depending on its type. Furthermore, the engine E1 is composed of part P1 and P2; and the P1 and P2 are common parts shared by the engine E1, E2 and E3; while P3 is applied only to E3, as shown in the figure 2 below.

Fig. 2. Product Configuration & Structure of a Car The parts list for such product structures of a car is prepared per assembly, and is generated in an itemized or integrated way depending on the preference of a design staff. When a design specification is not finalized, a parts list is determined temporarily based on the experiences and knowledge of a design staff. Even the engine of the same type can have different specifications (e.g., in engine power), significant manual work is required when preparing a design BOM based on the standard part lists. Therefore, when it is necessary to get a relevant design BOM information from other division, the accurate information can be acquired only through the confirmation of a design staff. Such divisions as sales, production planning, production, material and quality have their own business processes itself because the

74

Pacific Science Review, vol.9, no.1, 2007, pp.72-82

design BOM is not reliable, so the information on production, quality and unit price is managed separately as there is no organic interface among them. The fundamental cause of such problems is product configuration management and BOM information management in suitability to the production environment. For example, a design BOM is used not for the management of BOM at an enterprise-wide level but only as a result of design work; and other departments do not utilize the design BOM but just re-process it for their own business purpose. This causes a problem - mismatch in information interface. Accordingly, not only the design division but also entire divisions of an enterprise lack the accurate product information, and this has adverse impact on the management activities such as decision making and cost management which require detailed information management. In general, BOM information is managed separately, e.g., as a design BOM, production BOM and other BOMs defined for the specific purposes of departments. This causes many obstacles in the communication among processes. As shown in the figure 3, in the BOM of the 2nd generation type, the unique DBs or files of each process do not contain the unified product expression, so there is a certain limit to overcoming the information discontinuity and reprocessing block. As a solution shifting to the 3rd generation enterprise-BOM which can support a unified management of the product data across the entire processes of a product life cycle from the enterprise-wide perspective is inevitable.

specification and BOM information related to development, production and sales of a car will be presented. The data scheme of car model based on car models, function units, grade and color specification will be reviewed, and the data structure which connects the order information for a user vehicle to actual parts will be discussed. To the relationships of information, tables allow easy expression and management.

Data Scheme of Car Model

A data scheme of a car model refers to the framework of expressing a car through the use of data, and it is the core of BOM management, focused on how to express a car composed of tens of thousands of parts and manage it using data. Theoretically, the number of configurations of user vehicles delivered to general customers can be in the thousands or tens of thousands. Connecting the raw materials to a final product directly upon expressing the user vehicles configuration information requires great effort, and the consumption of vast physical data storage as well. Under the customer-oriented market environment, various options should be available for user vehicles. The objective of a car model data scheme is to widen the options for customers through combining tens of thousands of parts while managing data effectively. The framework of a car model data scheme is proposed to enable flexible management of order information, as shown in figure 4. The features of the proposed car model data scheme remove unnecessary management elements caused by information inconsistency, and allow market-oriented (not production-oriented) vehicle configuration. A series means the highest configuration management unit. Indiscreet addition of series can scatter management power, and impede the sharing of parts. Vehicles of multiple types constitute a series, and they are distinguished by vehicle type, For instance, there can be a series of passenger and commercial vehicle. An expression of a vehicle configuration is a car model, of a specific vehicle type. A car model is a lower level than a configuration which a customer purchases, and excludes options or color choice. As for the model, the actual configuration purchased is called an order specification or simply a user vehicle. A function unit collectively refers to the entire function modules such as the engine, transmission, bumper or options. Out of the function units, those providing the basic function of a vehicle (e.g., engine, transmission, body and axle) are called base units. Even if a base unit includes multiple function units, a car model is defined by selecting only one function unit for every base unit. Accordingly, once a car model is determined, the

Fig. 3. Development Direction of an Automotive BOM

ENTERPRISE-BOM STRUCTURE
In defining the functions of parts at the design stage, reprocessing specifications defined in the planning is undesirable in terms of communication and usability of information. Planning, design and development should flow seamlessly, and the information from the upstream must be used as that from the downstream. The production information management systems in every process should be unified. Here, the enterprise-BOM structure where a variety of

75

Dae Beom Kim : An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry

function unit group belonging to a base unit is uniquely identified. The function units - other than options whose characteristics do not significantly appeal to customers are called dependant units. Once a model is determined, the functions group belonging to a dependant unit can be identified. Thus, a car model can be uniquely defined by the base units and function unit group belonging to a dependant unit. An option refers to the function unit a customer selects to add to a car model. A customer selects indirectly through a grade to prevent a meaningless increase in the number of vehicle configurations. As there are numerous options, option packages are configured by grouping for sales and production purposes. Likewise, a customer can select a color specification determined via the relationship between a car model and color specification. The order specifications of a vehicle which a customer actually buys are determined by selecting the car model, grade and color specification; and a grade is uniquely determined by the combination of the function units included in an option.

units are used, it can be extended to parts.

Fig. 5. Logical Structure of Enterprise-BOM

Car Model and Grade

(1) Relationship among Car Models, Base Units, Grade and Options A car model is a combination of base units. Table 1 shows an example Car Model 1 equipped with Body B1, Engine E1, Mission M1 and Axle A1. Table 1. Car Model vs. Base Unit

Fig. 4. Data Scheme of Car Model The logical structure of an enterprise-BOM focused on function units is shown in the figure 5 below. To express the final products that customers want, the BOM is largely divided into specifications, function units and parts. The top part of the hour glass is a specification area where the relationship among final products, function units and color specifications is managed; the middle is the area where the function units (classified to express the combinations of parts in a simple way) are managed. The bottom part of the hour glass is the area where part configurations are managed, and here the color information is also managed per colors of function units. The top zone of a function unit is linked to specifications, and the bottom to parts to connect customer order specifications and function units, enabling identification of parts used. That is, as the customers order information includes car model, option package, color specification and additional options, if the diverse relationships between specifications and function A grade is introduced to a user vehicle configuration to express market-oriented information, and a grade is expressed as a combination of options. A grade is the class given a vehicle by sales or product planning, considering target customer, independent from design aspect, and easily understood customers and agents. In sales, an order is placed on the basis of the user vehicle configuration including a grade; and for production, it is extended to the parts (or options) at function unit levels via the configuration information of BOM. Examples of a grade include STD(Standard), DX (Deluxe), GT(Grand Tourism), etc. An option specification is of two types - a full option method which supports the entire combination of all options, and a grade method which has predefined option combinations. Since allowing the full combination of options available for sales is almost impossible in terms of production, a grade method is adopted to facilitate sales via market forecast. In addition, car models and options (or grades) are managed separately for the

76

Pacific Science Review, vol.9, no.1, 2007, pp.72-82

convenience of management because the number of options is far greater than the number of base units by several ten or hundred times. (2) Ways of expressing a grade As a grade is the combination of options, correlation should be defined so that an option group (function unit) can be uniquely determined from a grade. To express this, a usage condition table is used to show the application or restriction relationship between a row and column elements. The table 2 below shows an example of applying specific options to a given grade. The usage condition table is prepared by a product planning department, and can be referred to by sales department. Table 2. Grade vs. Option

table 4 below. To the Grade1, only (V, A) and (V, B) are applied from the interior and exterior color combinations. Table 4. Grade vs. Color

Option Setting
An option is the function unit which a customer selects additionally after selecting a model. An option is divided into two types. First, a dealer option is the one a dealer installs after a user vehicle is delivered to a dealer - for example, a roof carrier, an air spoiler, etc. A car maker need not manage this dealer option unless it is designed by a car maker. Second, a maker option is the installed in the factory - for example, a seat, ABS, etc. In this paper, an option refers to a maker option unless specified otherwise. Two kinds of restriction relationship are established to connect options to a car model. First, a restriction is placed on the base units of an option when an option has technical and design issue and physical interference with each base unit. For example, a sun roof can be installed on a 2-door or 4-door body, but not on an open body. Second, there is a restriction between options, for example, a key-less entry system cannot be installed without an electronic door lock. The restriction between options and base units sets the usage conditions as in the table 5 below. An option is not linked directly to a car model because doing so increases the efforts required for management. For instance, given 3 types of body, engine and transmission, the number of car model combinations is 27, and changing a base unit may cause the change of the entire car models linked to a specific option, thereby generating a vast amount of changing work. The Option1 in the table 5 below shows the car model where such base units as Body B1, Engine E1, E2, E3 and Mission M1, M2 are applied. If B2 is added (or O is marked on the table), it will result in changing the entire car models corresponding to Option1. Table 5. Option vs. Base Unit

The restriction relationship between a grade and a base unit is expressed by a usage condition table as in the table 3. In table 3 below, Grade 1 can accept only B1 for a body, and any choice from E1, E2 or E3 for an engine, and only A1 for an axle. The restriction relationship between a grade and base units is expressed by Grade vs. Base Unit - not by Grade vs. Car Model - because of the reasons as follows. First, the options determined by a grade are originally designed to match the base units (e.g., body, engine), so change management is easy. Second, if the restriction is expressed by the relationship to a car model, change management is difficult because change should be made to all car models corresponding to the base units changed as a car model is a combination of all base units whose number is great. For example, if there are 3 different types in each base unit of body, engine and transmission, 27 car models may be derived from the entire combination. If the relationship of the body B1 is changed, in the Grade vs. Car Model relationship, a maximum 9 changes (of 3 engine types and 3 transmissions) should be made; while in the Grade vs. Base Unit relationship, only one change is required. Table 3. Grade vs. Base Unit

There are 3 technical restrictions among options as follows: The Grade vs. Color restriction relationship is shown in

77

Dae Beom Kim : An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry

1) Combination relationship Selection of a certain option involves a simultaneous selection of another item. For example, when a key-less entry system is selected, an electronic door lock must be selected as well. 2) Exclusive relationship Selection of a certain option excludes selection of another specific item. For example, when a manual door lock is selected, a key-less entry system cannot be selected. 3) Parallel setting When a customer selects a grade, he/she must select specific options. For example, either a manual door lock or an electronic door lock should be selected as a door lock option.

color, part A can have 5 types, as many as the number of colors. So, it is difficult to manage different configuration information for the part with the same function only due to the difference in color. 4) Management effort If several different part numbers are given a single part of the same function because of different color, redundant attribute information should be managed, thereby increasing the amount of data and efforts required to manage them.

Color Specification Setting

(1) Color of interior/exterior and a function unit A color specification is usually divided into exterior, interior color and parts color; and the color specification parts is determined by the harmony with the exterior or interior as shown in the figure 6 below.

Fig. 7. Configuration by Color Attribute vs. Configuration by Part (3) Color management for colored parts As the color of a user vehicle is determined by the exterior and interior color, the combinations of the two colors are presented in the table 6 below. Since the number of exterior colors is more than that of the interior, it is desirable to express exterior color by assigning easily identifiable color codes. Table 6. Color Combination

Fig. 6. Color Structure of a Car. (2) Composition of colored parts The color of parts can be identified two ways by assigning a unique number to each color of parts, and by managing color information as attribute information of a part. Out of the two ways, managing color information is recommended because unique number for part color has disadvantages: 1) Number of colors If a color code is given to a part number, it may go beyond the expression limit of a code. Actually, the color of a specific functional part may divide into over 900 types. 2) Computation of required amounts This requires vast calculations to identify part numbers and compute the required quantity per colored parts. 3) Complexity in configuration management Assuming the configuration information contains both the colorless and colored parts as in the figure 7, if the part configuration data is kept separately per different

Colored parts should be consistent with only one color from the interior or exterior color. In general, the interior parts are consistent with interior colors; and the exterior parts with exterior colors. (See the table 7.) Table 7. Interior/Exterior Color vs. Function Unit Color

78

Pacific Science Review, vol.9, no.1, 2007, pp.72-82

Link between Product Specification and Parts

(1) Expression of order specifications The order specification selected by a customer is expressed via the combinations of base unit, options and color specifications, which are divided into 3 methods as follows: 1) Full Option method This is expressed by the combination of Base unit + Individual Option (Option1,2,3,.) + Color Specification. Its merit includes suitability for flexible satisfaction of customer needs and small quantity match production, and its drawback is that much effort is required. 2) Grade method This is expressed by the combination of Base unit + Grade + Color Specification. Its merit includes effort saving and small scale production. Its drawback is lack of flexibility. 3) Grade+Individual Option method This is expressed by the combination of Base unit + Grade + Color Specification + Individual Option. Its merit includes its suitability for flexible satisfaction of customer needs and small quantity match production. Its drawback is the effort required compared to the grade method. The full option method responds to customer diversification as a customer can select all function units, but it requires great administrative effort due to the vast amounts of data. The grade method lacks flexibility in meeting the customer needs as the options are expressed by the grades, or option packages available for sales, but it is efficient in terms of management. This study recommends the Grade + Individual Option method, considering the flexibility in meeting customer needs and administrative effort. By this method, a customer selects additional options besides the grade or the packaged option set, and this contributes to the diversification of products for demanding customers without causing significant production problems. Another important issue is that the order specification codes used by the sales division should be consistent with the codes used by the production divisions to unify code management at an enterprise-wide level. (2) Link between order specification and parts The data structure necessary to separately manage user

vehicles, base units, grades, options, and color specifications and connect the order specifications to a final part has been discussed. The connection from the customer order information to the final part units can be expressed as a link structure as shown in figure 8 below. First, from the customer order code: Car Model + Grade + Color Specification + Individual Options, check each item if they are available for production, referring to the information defined in a table. Then, determine the base unit using the car model information, and then determine the function unit necessary for the option considering the grade vs. option relation and individual options. Then, determine the color of function units considering the color specification and harmony between interior and exterior colors. The last step is to select the parts based on the parts parent-child relationship and the color configuration information of each function unit.

Fig. 8. Product Specification and Part Linkage Structure

SIMULATION OF ENTERPRISE-BOM APPLICATION

A simulation was conducted on the basis of the business process of S company to confirm the site applicability of the Enterprise-BOM, focusing on the unification of product expressions, enterprise-wide integration of product data, and integration with subsystems.

Unification of Product Expressions

Throughout the development of a car, the planning

79

Dae Beom Kim : An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry

concept at the product planning stage becomes the commerciability objective. This is expressed as a product specification based on which the product function is defined. Based on the function, design and development of parts proceed. Upon unifying the ways of expressing products, the function units for the final product or a finished car are expressed on the proposed enterpriseBOM. A standard is defined for the function units of each car series distinguished by price, use, etc. of a car being developed, and the final car is expressed according to the registered standard function units when a car is developed in the future. That is, when a new car is developed, in the product planning stage, the commerciability objectives regarding environmental preservation, safety, power performance, fuel economy, control stability, NVH performance, etc. are determined, they are standardized and connected to function units, and the specifications are finalized. In the design and development stage, the design specifications of mainly function units are defined and designed. In an assembly stage, such function unit data can be applied to processes as is. Through such procedure, it is possible to diversify products, save cost, ensure high quality and quickly respond to market requirements in the planning stage; and shorten the product development period via sharing of function units and modular design in the design and development stage. In addition, the efficiency of a factory can be improved through modulization of assembly and transportation units in the assembly process, and it is possible to meet the demand of various types with small amounts of inventory due to the easy demand forecast of function units. Figure 9 below shows a final car expressed in function units in a product development process, and parts are managed as substructure of the function units.

supported; units should be divided to meet various customer needs; the requirements for production plan, transportation units and cost/weight control units should be taken into account; and the number of function units should be minimized considering the effort required.

Enterprise-wide Integration of Product Data

Product data are modified, changed and added continuously. Therefore, in order to support the sharing of such dynamic data across entire processes, product data should be integrated at an enterprise-wide level so that the data input or change by an authorized person can be available to all relevant personnel immediately without additional processing. Figure 10 shows product related data created and used in car development stages via the proposed Enterprise-BOM. If the product specifications, function units and parts are expressed in a standard way by a responsible department, other departments can use them without re-processing. That is, the specification information per function unit standardized in a planning stage can be used to configure parts for each function unit at a design and development stage, and such configurations created by a design department can be used in the assembly stage without reprocessing.

Fig. 10. Creation and Use of Product Data per Development Stage

Integration of Subsystems
When integrating and managing product data from a enterprise-wide perspective, integrating the entire data in a single physical way may be unrealistic and impossible, and might be inefficient. Therefore, the product information used in common by the entire divisions or the enterprise-wide process should be managed separately from the unique information of each process. Enterprise-wide common information is managed via the enterprise-BOM, and the information unique to each process is processed by the subsystem per the objective of individual processes. Even if the system is created for a specific purpose, it is dependent on an enterprise-BOM, but portions related to the common enterprise information are communicated appropriately. Figure 11

Fig. 9. Unification of Product Expressions Upon identifying product expression by function units, it should be suitable for the use of individual process. Such requirements are as follows: the classification of product specifications defined in the planning stage should be expressible; part sharing and modular design should be

80

Pacific Science Review, vol.9, no.1, 2007, pp.72-82

shows the linkage of the subsystems of major processes which are closely associated with and should interact with the enterprise-BOM. In the linkage between a target cost management DB to manage the budget vs. the actual and enterprise-BOM, for example, the managed car (whose cost is controlled) is selected, and the objectives of its function units and parts are registered to an enterprise-BOM. Then, the information on the managed function units and parts is retrieved from the enterpriseBOM to an objective management DB. If final performance data is available, it is registered to the enterprise-BOM so that it can be shared by the entire processes. In addition, design change information is received from the enterprise-BOM to manage the objective vs. actual data from time to time.

change; and the production division can support flexible production through production smoothing and JIT logistics even in an environment which requires diversified specifications and frequent changes. As a result, the enterprise-BOM can dramatically improve inter-process communication and information sharing, and contribute to the speed-up of business. The subjects of future study are related to: 1) the proper number of function units corresponding to base units and options under the basic principle that individual function units should function independently from each other; 2) which function units should be allocated to each base unit, dependent units and options; 3) how to manage sales regions as parts vary by the geographical sales areas; and 4) implementation strategies considering the practical issues such as the vast data accumulated over several decades, time, cost, employment of professionals, etc.

REFERENCES
[1] Edmunds Publications Corp., Edmunds NEW CAR PRICES (AMERICAN & IMPORT), Edmunds Publications Corporation, 1996. [2] Fohn, S. M., J. S. Liau, A. R. Greef, R. E. Young, and P. J. OGrady, Configuring computer systems through constraint-based modeling and interactive constraint satisfaction, Computer in Industry, 27, 3 21, 1995. [3] Ping Yi Chao and Tsung Te Chen, Analysis of assembly through product configuration, Computers in Industry, 44, 189-203, 2001. [4] Brown, D. C., Defining configuring, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4), 301-305, 1998. [5] Darr, T., M. Klein, and D.L. McGuinness, Special issue: Configuration design, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4), 293294, 1998. [6] Siddique, Z. and D.W. Rosen, On combinatorial design spaces for the configuration design of product families, Artificial Intelligence for Engineering, Design and Manufacturing, 15, 91108, 2001. [7] Jrgensen, K.A. and T. Raunsbk, Design of product configuration management systems, Proceedings of the Second International Conference on Engineering Design and Automation, Maui, Hawaii, 1998. [8] Yeh, S.C., Automatic configuration design, Masters Thesis, Department of Mechanical Engineering, National Sun Yet-Sen University, 1997. [9] Jiao, J., M. M. Tseng, Q. Ma, and Y. Zou, Generic bill-of-materials and operations for high-variety product management, Concurrent Engineering: Research and Applications, 8(4), 2000.

Fig. 11. Integration of Subsystems

CONCLUSION
This study raised the necessity for the enterprise-BOM a new BOM structure to realize communication innovation, proposed the framework efficient, and discussed the major internal data structure of BOMs. Upon designing the structure of an enterprise-BOM, car model data is defined to support flexible response to the diversified customer needs and enterprise-wide integration of core product data. Upon expressing car using data, the attributes of a car are divided into base unit, grade, individual options and color specification, and their interrelationship is defined in a table format to improve the flexibility of expression and reduce administrative efforts. The expected benefits of the enterprise-BOM are as follows: through the enterprise-wide integration of product data, the planning and sales division can react to diverse and ever-changing customer needs and demands swiftly and effectively to contribute to sales; a development division can enhance the reusability and level of sharing to enable speedy and flexible development in an environment which requires diversified products and specifications and continuous

81

Dae Beom Kim : An Enterprise-BOM for the Integration of Product Configuration and BOM Data in the Automotive Industry

[10] Kusiak, A. and C.C. Huang, Development of modular products, IEEE Transactions on Components, Packaging and Manufacturing Technology-Part A, 19(4), 523538, 1996. [11] Van Veen, E.A., and J.C. Wortmann, New developments in generative BOM processing systems, Production Planning and Control, 3(3), 327-355, 1992. [12] Hegge, H.M.H. and J.C. Wortmann, Generic billof-material: a new product model, International Journal of Production Economics, 23, 117-128, 1991. [13] Mather, H., Bills of Materials, The Dow JonesIrwin/APICS, 1987. [14] McKay, A., F. Erens, and M.S. Bloor, Relating Product Definition and Product Variety, Research in

Engineering Design, 63-80, 1996. [15] Smichil-Levi, D., P. Karminsky, and E. SmichilLevi, Designing and Managing the Supply Chain, McGraw-Hill, 2000. [16] Olsen, K.A. and Stre., Describing products as executable programs: Variant specification in customer-oriented environment, International Journal of Production Economics, 56-57, 495 502, 1998. [17] Halpern, M. and K. Brant, The Differences among PDM, CPC and PLM Matter, Gartner Group. 2002. [18] Kim, D. B., Functionalities for BOM(Bill of Material) System Supporting Integration of Product Core Data in the Automotive Industry, Pacific Science Review, 1, 55-62, 1999.

82