Systematic optimization of the Product Development Process with PLM-ML

Size: px

Start display at page:

Download "Systematic optimization of the Product Development Process with PLM-ML"

Jennifer Ray
6 years ago
Views:

1 48 Systematic optimization of the Product Development Process with PLM-ML Prof. Dr. Jörg W. Fischer, Martin Rebel, Bernhard Lammel, Jürgen Gruber Increasing productivity, driven by the pressure of costs and competition, is a core strategy element of all global acting companies. Manufacturing companies persecute this goal, beginning from continuous improvement of their manufacturing processes as far as optimizing global supply chains. The idea of optimization is progressively applied to the Product Development Process (PDP) and discussed under the term Product Lifecycle Management (PLM). Contrary to this, PLM projects basically focus on IT implementation. Hereby, the idea of optimization often becomes lost. One cause is to be seeked in the complexity of the PDP. The PDP can hardly be captured and optimized with existing modeling methods. Against this background PLM-ML was developed by the authors as an instrument to easily capture and optimize the PDP. This article explains PLM-ML and exemplifies how the PDP can be optimized utilizing PLM-ML. The idea of PDP optimization Manufacturing companies are facing the challenge of continuously increaseing their productivity in order to withstand the pressure of global competition in the future. Thereby, they are achieving great success through optimization of operation procedures, improvement of organizational structure as well as the use of new manufacturing and production technologies. Currently the idea of optimization is increasingly adapted to the PDP as the awareness of so far unutilized potentials within the PDP, particularly for its downstream processes, grows. These discussions are primarily bound under the buzzword Product Lifecycle Management (PLM). Since PLM is tightly coupled to implementation of IT technologies, PLM is prevalently conducted as an IT implementation project within IT departments. Thereby the intrinsic idea of optimization is oftentimes lost. Apparently one main cause for this is the distinct focus on information technologies. Agley a further problem, which typically gets lost in the fog of the IT projects and currently drawing insuffi- Figure 1: A new point of view to understand the Product Development Process (PDP)

Hence, in the Frame of the development of Do(PLM)Con methodology the PLM Modeling Language (PLM-ML) was designed as a tool to enable a discussion on optimization of the PDP.

2 49 cient attention, exists. The PDP is extra - ordinarily complex. Using existing model - ing methods, it is nearly impossible to depict the PDP. Modeling Tools for a transcend discussion on optimization are missing as of today. Hence, in the Frame of the development of Do(PLM)Con methodology the PLM Modeling Language (PLM-ML) was designed as a tool to enable a discussion on optimization of the PDP. A new approach to perceive the PDP Genesis of PLM-ML was expert discussions of PLM architects which aimed to define industry best practices for PLM. In context of these discussions conducted, analysis of industrial applications considerable weakness in existing modeling instrument, such as functional analysis, process chain representation or IT system landscape maps, were found. The result - ing depictions were quickly getting too complex. Beyond that essential PLM aspects could not be represented with existing methods at all. After some time of intensive discussions a new view based on a systemic model - ing element emerged, whose significance was not recognized sufficiently. To develop a product, engineers are imagining it and it's production beforehand. Therefore they use models. Each domain (e.g. Requirements Management, mechanical and mechatronic design, documentation, etc.) is using their own specific models. Those models provide ample detailed Figure 3: Aspects of (Partial-)Product Models aspects of the future product for the specific application area. Hence each of those models is a (Partial-)Product Model (shortly: Partial Model) of the future product. Based on those considerations, the modeling approach shown in Figure 1 was developed. It combines the process oriented view with the idea of the systemic modeling element Partial Model. Processes of the PDP are thereby differentiated in three categories. Management processes are controlling the PDP (Figure 1, top). Typically they are processed with the help of milestone schedules. The daily operating processes of the PDP are activated through a milestone of the management process or they end up by one of its milestones. They can be subdivided into long-term stable processes (meaning release and change processes, see Eigner 2012, p. 21) and daily engineering processes. Contrary to daily engineering processes, stable processes are explicitly defined and generally controlled by workflows in data management systems. All daily processes within PDP produce, utilize, change or extract information into or from Partial Models. As a result, Partial Models can be seen as the seed crystals of the processes within PDP (Figure 2). The benefit of the considerations in Figure 1 and Figure 2 is the accomplished simplification. Following this approach the PDP can be analyzed and depicted through its Partial Models. Since the number of Partial Models is much less than the number of processes within the PDP, their level of detail can far better be harmonized and additionally they can easier be localized which is an essential modeling advantage Figure 2: (Partial-)Product Model as seed crystals of the processes within PDP Several fundamental characteristics of Partial Models can be described as follows. A Partial Model is always an instance of a Partial Model type. Figure 3 exemplary shows instances of various Partial Model types for the product line Dumper Truck (Figure 3, top) and Digger (Figure 3, bottom). Partial Model instances of the same type often possess communality, meaning shared usage of components with, where required, various No. 1 I 2013 ProductDataJournal

3 50 occurrence in context of the specific product line (Figure 3, shared component underbody ). Different Partial Model types (Example Figure 3, bottom, Model types of product line Digger from left to right) often contain redundant information and similar model elements since they are a reproduction of the same entity. A usage in a usage model (e.g. tire) has an equivalence in the bill of material model (the for this usage supp - liable tire with varying profile and specific rubber composite) and an equivalence in the virtual prototype. The validity and significance in those model types is however diverging (e.g. a CAD model is not designed for each type of rubber compound). To consolidate diverging model types of the same product a comparison of the significance of the model type s elements is necessary. This leads to an adaption of semantic and, therefore, to a change in mode of operation in at least one of the two model types. PLM-ML as an instrument for modeling and optimizing the PDP To enable the usage of the previously outlined theoretical view in practice, the PLM-ML was developed within the scope of Do(PLM)Con methodology (Fischer u.a. 2011). PLM-ML is a semiformal graphical modeling language which enables analyzing and optimization of company individual PDP realizations. It uses the Partial Model as the central modeling element. PLM-ML is inspired by value stream design and especially adopts the idea of alignment of the PDP to specific Customer Values as well as the idea of an easily understandable, less formal graphic notation technique. Also, the separation between current state and a future state to be reached is adopted. Therefore, the PLM-ML provides several types of diagrams, which can be categorized in the following groups: n Partial Model Landscape n Partial Model to Process n Partial Model Detail n Partial Model Interaction With diagrams of the group Partial Model Landscape maps of the relevant Partial Models of the PDP can be depicted including their cross linking over a time axis. Areas with high potential for optimization can be easily located on those landscape maps. Such areas are then further detailed with the help of the diagrams of the other groups. This approach enables reducing the analyzing efforts by keeping the focus on the essential key aspects. The group Partial Model to Process combines the Partial Model concept with the process view. The incorporated Partial Model/Process Chain diagram is based on the eventdriven process chain (EPC) (see Keller, G.; Nüttgens, M.; Scheer 1992, p. 13), but substitutes the information object used in EPC with the modeling element Partial Model. The groups Partial Model Detail and Partial Model Interaction focus on the Partial Models itself. They enable for analyzing static structure (semantics), time behavior (progression) as well as integration of different Partial Models. Optimizing the PDP of a medium sized machine tool manufacturer Following the usage of PLM-ML is shown on the example of a typical tool manufacturer. The case is anonymized and simplified. The company builds machines with far more than 1000 parts per machine in single or limited-lot production. They offer an open variant configuration to their customers, meaning the customer can order individual variants which are then design and produced for the particular order. In the context of a discussion of weak points with the company design and manufacturing teams, two essential problems were recognized as essential pains. The company does not have any alignment process to keep the CAD and the BOM-Data synchronized. Thus often the wrong parts or components are supplied and provided in prototype and order production, leading to massive wastage of time and enormous additional Figure 4: Life Time & Information Flow diagram Current State

51 costs. A further problem is caused by the much too long cycle times while processing orders with high amount of customer specific development.

4 51 costs. A further problem is caused by the much too long cycle times while processing orders with high amount of customer specific development. The main competitors are often able to deliver faster and therefore important orders are frequently lost. The company spends a lot of time trying to improve this situation. However, they were trapped in the typical pitfall of isolated optimization without understanding the whole PDP. To improve this the Life Time & Information Flow diagram of PLM-ML was used to analyze the complete company individual PDP on a high abstraction level (Figure 4 and 5). This diagram type provides a time-related general view of interacting Partial Models in course of the PDP. Rectangles are representing the relevant Partial Models. Arrows and lines are depicting the crosslinking between Partial Models. The dedicated symbols at the arrows are furthermore used to characterize the crosslinks. The time axes document essential milestones or events of the PDP. Clouds are used to define out of scope areas for simplification of the diagram. duct-bom. The fundamental information for the Pre-Product-BOM he attains from CAD-Assemblies stored unstructured within the Team Data Management (TDM) system (Figure 4, CAD Cluster). From the TDM-System he extracts the part information which is enclosed in the CAD-Assemblies semi-automatically into Excel files and puts the necessary information in the Pre Product BOM (Figure 4, Pre Product BOM). Necessary customer specific adaptations are then discussed with product engineers responsible for specific CAD-Assembly during meetings and on the telephone. The results of these meetings are also documented by the product engineer within the Pre Product BOM. Subsequently, the equivalence between CAD and BOM for adapted parts (Figure 4, material master) is clarified with different ERP specialists by telephone. Before completion of the design phase, the product engineer initiates the creation of the Master Product BOM (Figure 4, Master Product BOM) based on the Pre Product BOM. Areas A & B (Figure 4, circuited) were identified as substantial origins of the problems during analysis of the PDP. Area A affects mechanical design. CAD data is managed and released within the TDM system, but there is no differentiation between research and product components. Development at this company takes place only in scope of orders. To do The diagram depicted in Figure 4 shows the analyzed Current State of the PDP. Upon a receipt of an order, a product engineer arranges the necessary assemblies for this specific order based on his experience. For this he creates a Pre-Prothis available components of existing products are copied and then adapted for the specific new product. The use of identical modules between different product lines, so that enhancements of a component during its lifecycle can be shared by all products, is not possible. Since the company suffers enormous difficulties, arranging and passing on current working data and collaboration with suppliers is only possible with tremendous efforts and so is mostly avoided. Area B is related to interaction between product engineers and purchasing. Material master and Pre-Product-BOM lists are neither linked by it technology nor semantically associated. Hence, purchasing has no knowledge about the materials being relevant for development of new products. Therefore the product engineer is usually not informed about changes of the material master. Furthermore, inapplicable components are often ordered, then having to be amended and newly ordered. Extended delivery times and gratuitous additional costs are the consequences. An attempt to reduce costs through purchasing strategies aggravates this situation. This only leads to further changes of the material master and in consequence incalculable effects on orders in development. Figure 5 illus - trates the enhanced and already successfully implemented Future State. The unstructured CAD cluster was substituted by CAD product structure being calibrated Figure 5: Life Time & Information Flow Diagram Future State No. 1 I 2013 ProductDataJournal

5 52 for each order (Figure 5, CAD structure). It also replaces the Pre Product BOM. Furthermore, an explicit partial model for standard part being synchronized with the material master was introduced. As a basis for a research and development (R&D) process that is decoupled from order development, a CAD cluster for R&D components (Figure 5, R&D CAD model) was installed and connected to the CAD product structure through so called Cross Model Based On Clone. Thus modules being adopted from R&D model into the CAD product structure are copied, but remain linked to their origin. So they are decoupled for their origin and could be developed independently but are still able to access their origin. This enables the share of innovation of the R&D model to all derived CAD product models. Organizationally this is conducted by a Module Owner, responsible for a specific module across multiple orders. This concept gives the company the flexibility to develop modules earlier and independent of customer orders and to use them in several products. The quintessence of the new concept is the implementation of an automated process between CAD Product Structure, Master Product BOM and ERP Material. The CAD Product Structure is defined as the leading model. Each newly created CAD model automatically generates a counterpart in the ERP Material and if necessary in the Master Product BOM. Non-synchronous BOM and CAD data is eliminated for this reason and possibility to automatically generate a Master Product BOM from the CAD Product Structure at any time exists. Realization of this approach demanded for an adjustment in information manage ment and hitherto mode of opera - tion. The Models were semantically modified in such an extent that elements of the CAD Product Structure have distinct equivalences in each other s Partial models (Figure 4, detail 1, Model Type Alignment). The original functional and structural semantics of CAD Product Structure were thereby converted into logically oriented semantics. To ensure unambiguousness at any time, relevant allocation case between models were carved out and specific solutions were defined in each case. As an allocation cases bars shall be mentioned as an example. Those bars are obstructed in different lengths. Only actually obstructed lengths are modeled in the CAD Product Structure. In the ERP Material only purchasable standard lengths are recorded. Allowing a distinct assignment between the parts in the Master-Product-BOM and the models of the parts within the CAD- Product-Structure was done through introducing the possibility to define the obstructed lengths and additionally the resulting standard lengths of bars already within the CAD-Models in the CAD- Product-Structure. Only with the solutions for those allocation cases it was possible to invert the direction of supply from BOM to CAD driven and also to control the ERP Material as well as the Master Product BOM by the CAD Product Structure. Contrary, it is generally defined impossible that changes are initiated by the ERP Master. Beyond that, deriving a logistically oriented 3D model (not shown by diagram) which can serve as a basis for installation and repair by service employees being on-site with the customer is made possible by the rearrangement of structure semantics of the CAD Product Structure to a logical orientation. Further optimization Future State shown in Figure 5 is currently serves as a basis for further optimization. Therefore, it is now the Current State that shall be transformed into a new Future State. Potentials still rest in a more precise clarification of coactions between R&D models and CAD Product Structure (Figure 5, detail 2). Currently models are functionally held together by one person and modules are copied with reference to their origin. An improvement can be conducted if utilizing the same modules and context-sensitively adjusting them succeeds. Above all, considerable possible savings are identified in even more consequent usage of modules through products and product lines. Implementation requires a more precise analysis of the product spectrum to define which information has to be adjusted contextsensitively in particular products and which can be kept generic. Conclusion and Outlook Evidently the example shows that optimization of production is different from optimizing the PDP in principle. Production optimization generally focuses on cut down of capacities of human resources, while optimization of PDP focuses on intelligent, context- and time-sensitive crosslinking of information. Optimization is thereby successful when combining optimization of information flow between relevant partial models with clarification and reorganization of responsibilities of the created information during their lifecycle in the PDP. PLM-ML enables a discussion on optimization of the PDP. Diagrams of PLM-ML are independent of future applicable IT systems, so that a discussion can be conducted neutral to vendors and systems. In scope of the Do(PLM)Con consulting approach, PLM-ML can show off yet another advantage. Since PLM-ML enables representation not only for a functional view but also semantics and progression of relevant information of the PDP, it is possible to plan implementation of appropriate PDP IT systems more precisely and more systematically than ever before (see Fischer, Brinkmeier 2012). n References: Fischer, Jörg W. u.a.: Implementierung domänenintegrierender PLM-Lösungen. Do(PLM)Con ein Ansatz zur Konzeption und Realisierung domänenintegrierender PLM-Lösungen. In: Industrie Management, Berlin, 27(2011)5, S Fischer, J.W., Brinkmeier, B.: Do(PLM)Con Proposal of a taxonomy for the development of PLM-Architectures. In: ProductDataJournal, (2012)1, S Eigner, M.: PLM versus PPS: Zukünftige Lösungen für ein durchgängiges Produkt- und Prozessmanagement, In: edm Report; electronic Data Management, Hoppenstedt Publishing, Darmstadt, (2012) 1, S Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage Ereignis - gesteuerter Prozeßketten (EPK), in: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbrücken ( Contact Prof. Dr. Jörg W. Fischer. Hochschule Karlsruhe Technik und Wirtschaft Fakultät für Maschinenbau und Mechatronik Phone: joerg.fischer@hs-karlsruhe.de Martin Rebel, M. Eng. Siemens Industry Software GmbH & Co. KG Phone: martin.rebel@siemens.com

Computer-aided Methods for Operations Planning

26th International Symposium on Automation and Robotics in Construction (ISARC 2009) Computer-aided Methods for Operations Planning Prof. Dr.-Ing. Peter D.P. Böttcher Department of Construction Management,