Distribution and Integration of PDM Data across Systems in the New Product Development Process

Transcription

1 Distribution and Integration of PDM Data across Systems in the New Product Development Process Thomas Mechlinski 1 Abstract The new product development process (NPD) is one crucial factor for the success of enterprises. Long before the first instance of a new product can be produced and sold, the development process determines the functionality, design and price of a product to be placed on the markets. Today, the product development process is supported by IT systems. Product Data Management (PDM) tools are used to manage the relevant data and processes. Contemporary PDM systems support a lot of different, PDM-related data types and systems that create and use the data. Besides the PDM systems, there are other, more specialized systems which hold additional artifacts to be used in the NPD. This leads to the requirement to integrate those systems and to provide access to their data through the PDM system. This article focuses on the role of PDM data and PDM Systems in the NPD. The integration of data and processes in the NPD will be explained and case studies will be provided. Keywords PDM, PLM, ERP, NPD, Integration 1 Introduction Being successful with new products on the market! This should be one motto for all companies manufacturing consumer and investment goods. Of course the production of high-quality, best-in-price and efficient products is a noble aim but what are the relevant factors to reach this goal? The manufacturing process is one factor. A lot of effort has been spent in the past for optimizing manufacturing processes in mass production as well as in indi- 1 Prof. Dr.-Ing. Thomas Mechlinski ( ) Hochschule Osnabrück, Albrechtstraße 30, Osnabrück, Germany t.mechlinski@hs-osnabrueck.de J. Stjepandić et al. (eds.), Concurrent Engineering Approaches for Sustainable Product Development in a Multi-Disciplinary Environment, DOI: / _59, Ó Springer-Verlag London

2 694 T. Mechlinski vidual production. Information technology was implemented to improve e. g. machining, assembly and quality assurance. But optimal manufacturing processes are strongly dependent on appropriate product designs. A product could never be efficiently manufactured if the product definition is inaccurate, fragmentary or, at worst, wrong. Product design is the result of the product development process and new products are created in the New Product Development process (NPD). The NPD can be supported by contemporary information technology systems. The term Product Lifecycle was created for the idea of products being developed, produced, used and recycled. The process of maintaining information all over the product lifecycle is called Product Lifecycle Management (PLM). The following article describes one aspect of the PLM process: Product Data Management (PDM) and its integration in the new product development process. The focus is upon the distribution of PDM data across systems in the enterprises. Integration approaches are described. 2 The Role of the Design Process for Product Cost and Quality In [5], the influence of the consecutive steps during the product lifecycle on the price of the product is discussed (Figure 1). It can be assumed that the design of a product has major influences on the planning, purchasing and manufacturing of any single instance to be delivered to the customer later. This correlation is especially important for products to be delivered in large numbers. Cost-optimized material usage and manufacturing processes can reduce the product price and can be crucial for the success of a product on the market. The impact of a good product design in the context of optimum downstream processes is the higher, the less changes or corrections have to be made after starting the planning and production of the product instances. Changes of e. g. pressing tools due to necessary late changes of car body components are very expensive and can influence the costs for a single car significantly.

3 Distribution and Integration of PDM Data 695 Fig. 1 Cumulated induced costs and determined costs in the development process [5] Besides the cost of the products, other criteria could be important. The product quality is one of those criteria: products have to meet the requirements which are the basis for the product functionality. This is absolutely important in the security context, e. g. for means of transportation like aircrafts, trains and cars. The process of designing a product which meets such complex requirements includes lots of steps. They have to be planned, executed and documented in a manner that allows tracing the results unambiguously later on. Some remarks about the optimization of the product development process and its risk management are made in [9]. A product instance cannot be better than its design, so the design makes the difference. 3 Product Data Management as a Basis for Product Development It has already been stated that the product design process and its results are important for the success of a product on the market. To a large extent, the quality of a product design depends on the people involved in the product development process: aspects like education, knowledge, motivation and work environment are relevant for the success of the design department. The process of creating a new product design can be supported by more subtle yet equally important factors such as corporate culture but one essential factor is the right technical infrastructure in terms of IT devices and software. Today, the product development process is performed with tools like office programs, CAX

4 696 T. Mechlinski systems, communication software and so on. Besides these end-user-related tools, Engineering Data Management (EDM) tools and concepts have become more and more important. The idea of EDM is to implement an infrastructure which is able to safely store all pieces of data which are created during the engineering process. Besides the data, the processes which are done with the data should be supported by such systems. One type of EDM systems are Product Data Management (PDM) systems. The focus of PDM systems is the support of processes like: Product master data management BOM creation and modification Product configuration (variant management) Versioning Release processes Document management, especially (but not only) CAD data management Users can use PDM systems to retrieve, store and process their data. A good PDM system supports users during such operations. Nevertheless, users often recognize the work in PDM systems as time-consuming and needless for their own work. This is especially a problem in the departments which create the basic data, e. g. product representation models (CAD files). In contrast, downstream users who can use and work with data produced by the upstream departments are mostly happy when their work is supported by the existing data and processes. All commercial PDM systems claim to support their users and to improve the efficiency of the development process. But experience shows that this claim is not fulfilled in every real customer situation. Most often the quality and functionality of the software is not the problem but the concrete implementation in the customer context. Possible reasons for such suboptimal PDM installations are: The customer situation with all specific processes and data was not analyzed properly The concept doesn't reflect all requirements resulting from the analysis phase Processes to be taken out by users are too complicated or too time-consuming User processes are not supported as efficiently as possible by the software, especially if too many data have to be entered manually Several departments do not accept the PDM system and work in their own, legacy way bypassing the PDM system Users are not trained sufficiently Users are not motivated to consequently work with the PDM system A PDM system which really works and improves the product development process has to be planned and implemented thoroughly. The motto Think big start small is a good advice for the implementation. An overall plan for a complete PDM system supporting all departments and users can be a starting point. But it makes sense to begin with a small set of processes and with motivated users. Later, the functionality and the circle of users can be extended step by step. Depend-

5 Distribution and Integration of PDM Data 697 ing on the budget and on the company size, it can be reasonable to leave specific areas unsupported by the PDM system but to define the appropriate processes nevertheless. 4 Concurrent Engineering in the Product Development Process Concurrent Engineering is one key approach in modern product development scenarios. A traditional work organization with strictly sequent procedures (Figure 2) is not suitable for short time-to-market needs, which are typical for all consumer goods and most of the investment goods today. Two departments in every company are the major stakeholders in this field: product development on the one hand, production planning on the other. Fig. 2 One point of view on the engineering process with its sub processes and milestones The production planning department is eager to get input as early as possible, whereas the product developers often want to maintain secrecy about their exact product definition information till every screw is in the right place. This kind of thinking has the drawback that the production specialists are informed late about manufacturing-related aspects of the new product. This can imply high costs for manufacturing the components as well as for the design of the production process. The feedback of the production department in an early stage of the development helps to improve the product design with regard to a better manufacturing suitability. On the other hand, the vision of concurrent engineering is that all people involved in the product development process can access up-to-date data as soon as possible. The reliability of data is one aspect which has to be taken into account for such a scenario: single component parts can be ready for use much earlier than a complex system which is built with the component. Thus, the maturity of com-

6 698 T. Mechlinski ponents, systems and products has to be maintained, and the composition of a product at a certain point of time depends on the status of its components whether they are finally released or not. This implies that an infrastructure for storing, distributing and using product data is provided. Such infrastructure has to implement means for the management of access rights and workflows (processes). With the workflow facilities, release processes and change processes can be controlled safely. This allows making certain objects visible or not depending on their status and on the access rights of certain users who want to use the objects for the product design. PDM systems provide those facilities. Concurrent engineering can be implemented in PDM systems using proven concepts in product development contexts. Thus, the infrastructure problem can be solved but organizational questions have to be answered as well. Processes which are involved in the product development context have to be analyzed. Questions regarding the reliability of the objects in different states have to be answered. And it has to be ensured that the people and systems support the processes completely, without any bypass and manual work which may fail. Concurrent engineering has so many facets it heavily depends on the application of a PDM concept how it can be used in detail. 5 Distribution and Integration of PDM Data The organization of companies with PDM affinity consists of departments with more technical and departments with more commercial background. Today, the work in all departments heavily depends on IT systems. Sales departments have their CRM systems, logistics and finance departments work with ERP systems, and product development departments are supported by PDM systems. From the product development point of view, the PDM system is the basis for the other domains (Figure 3). The connecting link between these departments is the product. The sales department sells it, the logistics department buys the raw materials and components, and the product development creates new products. This implies that all these people must work with data which describe several aspects of the same product.

7 Distribution and Integration of PDM Data 699 Fig. 3 Product data related systems in the product creation process It is obvious that it makes sense to share the product data which is relevant for all domains between the IT systems in the belonging departments. In the past, when system integration was technically difficult and expensive, it was often a simple sheet of paper which was used to share the necessary information. Product data like part master numbers, bill of materials or change requests were printed or written by hand, sent to the other departments and entered into their systems once again. Error-prone, slow, unreliable. Electronic data exchange by use of media like floppy disks or tapes was a progress, compared to the manual process. Larger amounts of data could be transferred this way but the exchange of the media took time, and it was an asynchronous process. The up-to-dateness of the data depended on the frequency of export/import processes and on the availability of the technical facilities and their operators. The vision is that product related data can be created easily in the domain which has the best or the first in time knowledge about the certain aspects. Directly after creation or modification of the data, it should be accessible by other domains. 5.1 The bill of materials as a common basis One example is the bill of materials (BOM, sometimes called parts list). It contains information about detail parts, assemblies, item quantities and much more: it

8 700 T. Mechlinski represents the product structure. BOMs are needed in a management-related domain (for example, in ERP systems) as well as in the product development domain (in a PDM system), in the production planning system and so on. According to [10], the following types of BOMs can be distinguished: Quantity BOM Structural BOM (multi-level BOM) Unit list Variant BOM The BOMs themselves can contain different information, depending on the domain. Manufacturing-related information (e. g. the assembly sequence) is not relevant for the management BOM, and logistics information (e. g. the glue that is needed to fix a windshield) is not relevant in the BOM in a PDM system. BOMs in a PDM system often include geometrical information, like transformation matrices for each part instance this information cannot be processed in ERP BOMs. The structure of the BOM itself with its systems, assemblies, subassemblies and detail parts could be different as well in the involved systems. But at the end, each BOM represents the same product. Thus, the question arises: who, which domain, creates and maintains the BOM? In an early phase of the product development process, such BOMs could be created by copying BOMs of existing products e. g. an existing car model. Another approach is template-based: a special class of products can be built up on one common template, which includes abstract, functionality-based components. For example, a car should have one steering wheel, one engine and (normally) four wheels with tires. The logistics-related BOM could be created in the ERP system. The BOM which is used for product development could be created in the PDM system in parallel and the manufacturing BOM could be treated similarly. All three BOMs can be maintained separately. But, of course, this scenario causes multiple work and inconsistencies. From time to time, the parallel BOMs have to be compared and adjusted. This leads to a lot of additional work and a product definition which is never up to date over all domains. 5.2 BOMs in product data integration Product data integration is the concept which can solve this problem. The idea is to use identical information in every system, synchronized with the other systems holding the corresponding data which comprises the product model. The semantic and structural differences between the product data in the different systems have to be taken into account so that the domain-related processes in each system are supported by the data from the other systems. In case of the BOM, the decomposition of the whole structure from detail parts, assemblies and systems can be differ-

9 Distribution and Integration of PDM Data 701 ent in different systems. But at the end, the same parts build the whole product, regardless of the specific view on the BOM. The idea of a universal structure representation (the BOM) for throughout use in the different domains is hard to execute: often the involved departments have great objections because of their special, hand-tuned data. This has to be taken into account. But it should be clear that even a domain-specific structure with its domain-specific processes is not as efficient as possible for all departments and all specialists in the domain. A BOM structure can be optimized for the logistics needs; but for the variant management, maybe the same kind of structure is not perfect. And those are typical users of a BOM in an ERP system. 5.3 Technical aspects of product data integration Contemporary data management systems support a variety of integration facilities. Integration is not a new concept even in the early years of the information technology, approaches for such exchange of data were made. Modern concepts like EAI 2, Web Services, SAAS 3 and Clouds allow high-performance integration scenarios on a stable technical basis. Standards and effective tools are provided to implement integration. Besides this technical basis, it is nevertheless important and indispensable to make a thorough and detailed requirement analysis for each integration aspect. It has been stated that the product data which is stored in the different systems involved in the product development process describe the same product. But the extent of data, its structure and meaning (information) is different. Some differences can be bridged with technical means. For example, in an ERP system, a release status can be stored as a simple attribute. In a PDM system, the information about such a release status could be a complex object with powerful processes attached. In order to transfer the release information between the two systems, the appropriate information has to be read out of one system, has to be processed and then to be inserted with the right technical method into the target system. In this example, the import process into the PDM system could be complex and time-consuming, maybe it would be necessary to automatically start several release processes which take some time. In [4], one technical approach for integration is described. For such kind of integration, technical interfaces have to be provided by the systems involved. In order to transport the appropriate information from one system into the other, a process which is called mapping could be implemented. With mapping, the difference in the representation of the information in the systems can be achieved. 2 Enterprise Application Integration 3 Software as a Service

10 702 T. Mechlinski 5.4 PDM integration with neutral formats One approach to connect systems in a PDM integration scenario is the usage of a neutral data format. For product data integration purposes, there is the STEP 4 format family, which is standardized in the ISO standard STEP formats can be used for different aspects in the product data exchange, like geometry, product structure and requirement information. Fig. 4 Enterprise Service Bus (ESB) concept Together with modern XML technologies and tools, the PLM Services XML schema [8], which is derived from the ISO standard, can be used for PDM integration. PLM Services cover all relevant areas of PLM data exchange apart from the geometrical shapes of parts. In conjunction with the appropriate software systems which are able to interface the backend systems (ERP, PDM and other), a data backbone can be built on such neutral format. Such backbone can be seen as a platform for the integration of the involved systems [7]. Technologies like Enterprise Service Buses (ESB, Figure 4) can be used to provide the infrastructure for such integrations. Compared to older approaches which used point-to-point connections between the involved systems, ESB-based 4 Standard for the Exchange of Product model Data

11 Distribution and Integration of PDM Data 703 solutions can easily be extended with additional systems. Another advantage is optimum scalability with modern infrastructure concepts like application servers. 5.5 Product Data Integration for SMEs Small and medium-sized enterprises (SMEs) often do have the requirement for product data management and, moreover, for product data integration. One starting point for such enterprises is usually the CAD design CAD models, drawings and other product representations have to be maintained. This leads to a document related mode of operation with some limitations, regarding the usability of the product data for processes in other domains than product development. The understanding of product data as a basis for subsequent or related processes is less widespread. And the motivation of the people in the involved departments is low, since high-quality product data usually means more effort for them. Since mostly SMEs are not able to invest in a full-featured, highly customizable PDM system, integration with other systems that might exist in the companies is difficult. If an ERP-like system exists, it is often a special, home-grown solution and does not allow integration scenarios. Or it is a small, sectorial standard software solution with limited data interfaces. Those are not good prerequisites for product data integration. In practice, product data integration in SMEs is possible provided that turnkey solutions are used. PDM-ERP integration is available as a module in some of such systems that can be bought on the market. Especially smaller, cheaper solutions are not flexible and work with rigid processes and data models. Thus, the support of application-specific data and processes may be possible. But this can be expensive, since specialists are to be involved. 6 Conclusion: the virtual Product is born in a virtual PDM System Virtual products are the basis for the product development in many branches and companies. The virtual product allows inter alia concurrent engineering, rapid changes in functional design and the support of all relevant domains involved in the product development process as well as in other domains like planning and sales. In order to let all involved groups participate in the virtual product model, an appropriate infrastructure has to be provided. This includes PDM systems, but also other systems that create data and use data in the process. Such infrastructures can be implemented by employing integration approaches. One key for the implementation of an effective product development infrastructure is a good understanding

12 704 T. Mechlinski of the data and processes that are to be supported. Technical solutions can be found today a lot of sophisticated IT approaches for the requirements of such infrastructure are ready for use. And people who can create the systems are available as well. Product Lifecycle Management (PLM) is the keyword which subsumes the pervasion of the described approaches and concepts. PLM concepts are one key for success with products on today's markets. 7 References 1. Abramovici, M., Bellalouna, F.: Management der Entwicklung mechatronischer Produkte innerhalb eines heterogenen Engineering-Umfelds. Produktdatenjournal(1), (2009) 2. Anderl, R., Rezaei, M., Schützer, K., Moura, A.: A Federative Factory Data Management Approach for the Integration of Product and Process Models. ProductDataJournal(2), (2009) 3. Awiszus, B., Bolick, S., Brylla, U., Pinner, S., Schulz, M.: Produktdatenmanagement in der Entwicklung und Produktion von Fahrzeugen. Produktdatenjournal(2), (2009) 4. Eigner, M., Keßler, A.: A Concept for a Generic Connector as Middleware Between Data Sources and the Engineering Network Framework. Technische Universität Kaiserslautern, VPE White Paper 2011(4) (2011) 5. Eigner, M., Stelzer, R.: Produktdatenmanagement-Systeme: Ein Leitfaden für Product Development und Life Cycle Management. Springer (2009) 6. Jelich, F., Josuttis, N.: SOA im Produktdatenmanagement. Produktdatenjournal(2), (2010) 7. N. N.: White Paper: PDM Integration Strategies. ProSTEP ivip White Papers. ProSTEP ivip Association, Darmstadt (2007) 8. OMG Object Management Group: Product Lifecycle Management Services. V2.0, Final Adopted Specification. dtc/ (2007) 9. Unger, D., Eppinger, S.: Improving product development process design: a method for managing information flows, risks, and iterations. Journal of Engineering Design, (2011) 10. Wiendahl, H.-P.: Betriebsorganisation für Ingenieure. Mit 2 Tabellen, 6th edn. Hanser, München ;, Wien (2008)