Abstract
Increasing productivity, driven by cost and competitive pressures, is core to any strategy of globally operating companies. Manufacturing companies pursue this goal, from the continuous improvement of production processes to the optimization of global supply chains. The idea of optimization is increasingly being applied to the product development process (PDP) and discussed under the catchword Product Lifecycle Management (PLM). In contrast, PLM projects focus mainly on IT implementation. The idea of optimization is often lost in the process. One reason for this is the complexity of the PDP. This is difficult to capture and optimize with existing modeling methods. Against this background, the PLM-ML was developed by the authors as an instrument with which the PEP can be easily captured and optimized. The article explains the PLM-ML and uses an example to show how the PDP can be optimized with it..
The optimization idea in the introduction of PLM
In order to be able to survive the pressure of global competition in the future, manufacturing companies are faced with the challenge of continuously increasing their productivity. In doing so, they achieve great success, for example, through the optimization of work processes, the improvement of organizational structures and the use of new production and manufacturing technologies. The idea of optimization is currently being increasingly applied to the product development process (PEP), as there is a growing awareness that there is still a lot of -hitherto unused- potential in the PEP, especially for its downstream processes.
These discussions are primarily held under the heading of Product Lifecycle Management (PLM) led. Since PLM is closely intertwined with the introduction of information technology, the common view has developed that PLM is an IT implementation project in IT departments. Often, the actual optimization idea is lost in the process. One obvious reason for this is the strong focus on information technology. However, there is another problem that is usually lost in the "fog" of IT projects and that has received too little attention to date. The PDP is extraordinarily complex. With the existing modeling methods, it is hardly possible to describe it adequately. For an optimization discussion that goes beyond this, the appropriate modeling tools have been lacking up to now.
Against this background, the PLM Modeling Language (PLM-ML) was developed as part of the development of the Do(PLM)Con methodology as a tool that makes the PEP accessible for an optimization discussion.
A new approach to looking at the PEP
The PLM-ML originated in technical discussions of PLM architects to define "Industry Best Practice" for PLM. Analyses of industrial use cases conducted as part of these discussions revealed considerable weaknesses in existing modeling tools such as functional analyses, process chain representations or IT system maps. The resulting representations became too complex too quickly in the application. In addition, essential PLM aspects could not be mapped at all with these.
Figure 1: A new approach to looking at the product development process (PEP).
After some time of intense discussions, a new view crystallized based on a systemic modeling element whose significance had previously been overlooked. To develop and produce a product, engineers think ahead of the product and its manufacture. To do this, they use models. Each application discipline (e.g. requirements management, mechanical and mechatronic design, documentation, etc.) usually uses its own models. These models represent partial aspects of the future product sufficiently precisely for the respective application discipline. Each of these models is thus a (partial) product model (partial model for short) of the later product.
Based on this consideration, the modeling approach shown in Figure 1 was developed. This combines the process-oriented view with the idea of the systemic modeling element "submodel". The processes of the PDP are divided into three different classes. Management processes control the PDP (Fig. 1, top). They are methodically handled, as a rule, by means of milestone plans. The daily work processes in the PDP are triggered by the management process or find their end at its milestones. They can be subdivided into long-term stable processes (e.g., release and change processes, see Eigner 2012, p. 21) and daily engineering processes. In contrast to the daily engineering processes, stable processes are explicitly defined and usually controlled via workflows in data management systems. All daily engineering processes in the PDP generate, use, modify or extract information in or from submodels. Consequently, submodels are the crystallization seeds of the PEP's processes (see Figure 2).
Figure 2: (Partial) product models as crystallization nuclei of the PEP processes
The benefit of the view presented in Figure 1 and Figure 2 lies in the simplification achieved. Following this approach, the PDP can be captured via its submodels. Since the number of submodels is much smaller compared to the processes in the PDP, they are better standardized in their level of detail and can also be localized more easily, this results in a decisive modeling advantage.
Some essential properties of submodels can be described as follows. A part model is always an instance of a part model type. Figure 3 shows examples of instances of different submodel types for the product line "dump truck" (Figure 3, top) and "excavator" (Figure 3, bottom). Submodel instances of the same type often exhibit commonality. This means the common use of components with possibly different characteristics in the context of the respective product line (Fig. 3, common component "chassis").
Different partial model types (example case Fig. 3, below the model types of the excavator product line from left to right) often contain redundant information and similar model elements since they are representations of the same real entity. A usage location in the usage model (e.g. tires) has a counterpart in the BOM model (the tires that can be purchased for this usage with different treads and defined rubber compounds) and a counterpart in the virtual prototype. However, the validity framework and meaning in the model types is different, e.g. a CAD model is not constructed for every rubber compound. In order to merge different model types of the same product, it is therefore necessary to align the meaning of the elements of the model types, which entails an adjustment of the semantics and thus a change in the way of working in at least one of the two model types.
Figure 3: Aspects of (partial) product models
PLM-ML as a tool for modeling and optimizing the PDP
In order to be able to transfer the benefits of the previously developed theoretical view into practice, the PLM-ML was designed within the framework of the Do(PLM)Con methodology (Fischer et al. 2011). The PLM-ML is a semiformal graphical modeling language that can be used to analyze and optimize company-specific manifestations of the PDP. The PLM-ML uses the partial model as the central modeling element. It is inspired by value stream design and adopts, for example, the idea of orientation towards added value as well as the idea of a catchy, less rigidly defined symbolism. The consistent separation between the current state and the future state to be developed is also adopted. The PLM-ML provides various diagram types which are divided into the following groups:
- Partial Model Landscape
- Partial Model to Process
- Partial Model Detail
- Partial Model Interaction
The diagrams in the "Partial Model Landscape" group can be used to display maps of the partial models of the PDP and to analyze their interconnectedness over time. On these maps, areas with optimization potential can be easily localized. Such areas are subsequently detailed with the diagrams of the other groups in order to focus the analysis work on essential focal points. The "Partial Model to Process" group combines the partial model concept with the process view. The "Partial Model/Process Chain" diagram contained in this group is based, for example, on the event-driven process chains (cf. Keller, G.; Nüttgens, M.; Scheer 1992, p. 13), but replaces the information object used there with the modeling element "partial model". The groups "Partial Model Detail" and "Partial Model Interaction" focus on the partial models themselves. They can be used to analyze static structure (semantic), temporal behavior (progression), and the integration of different partial models.
Analysis and optimization of the PDP of a medium-sized machine construction company
In the following, the application of PLM-ML is shown using the example of a typical mechanical engineering company. The case is anonymized and simplified. The company manufactures machines with well over 1000 parts per machine in single or small series. It offers its customers an open variant configuration, i.e. the customer can order individual variants that are designed and produced for him. In the course of a discussion of weaknesses, two central problems were raised as significant. The company does not succeed in keeping the parts lists and design data synchronized. As a result, the wrong parts are often provided during prototype construction and production startup, which causes high follow-up costs. Another problem is long lead times for orders with a high proportion of new developments. The competition can often deliver faster, which means that important orders are lost.
In order to analyze the causes, the company-specific PDP was analyzed using the lifecycle map of the PLM-ML (Figures 4 and 5). This provides an overview of the interacting submodels in the chronological course of the PDP. Rectangles represent submodels. The arrows/lines between the submodels as well as the assigned symbols have a specific meaning with regard to the interconnectedness of the submodels. The time axis documents significant milestones or events of the PDP. Clouds represent areas that are not considered to simplify the analysis.
Figure 4: Lifecycle map "Current State"
The diagram in Fig. 4 shows the found "Current State" of the PEP. When an order is received, a product engineer compiles the necessary assemblies for the order based on his experience. He obtains essential information for this pre-product parts list from the CAD assemblies stored without structure in the Team Data Management (TDM) system (Fig. 4, CAD cluster). From there, he semi-automatically feeds the parts information contained in the assemblies into several Excel files and uses it to detail the pre-product BOM he maintains (Fig. 4, Pre-Product BOM). He discusses the necessary customer-specific adjustments with the assembly designers in meetings and by telephone and also documents these in the pre-product BOM. He then clarifies the material correspondence for adapted parts with the ERP specialists by telephone (Fig. 4, Material master). Before the design phase is completed, he initiates the creation of the master bill of materials (Fig. 4, Master bill of materials) on the basis of the pre-product bill of materials he has maintained.
In the PEP analysis, areas A & B (circled in Figure 4) were identified as major contributors to the problems. Area A concerns mechanical design. Although CAD data is managed and released in the TDM system, no distinction is made between development and product components. Developments usually only take place within the framework of orders. Existing components of old products are taken over and adapted for the respective product. It is not possible to use the same modules between different product lines, so that improvements to one component flow into all products over the life cycle.
Since the company has enormous difficulties in compiling and passing on current data for components due to the existing information management, cooperation with technology partners is only possible with great effort and is therefore mostly avoided. Area B concerns the interaction between the product engineer and purchasing. The material master and the pre-product bill of materials are neither linked in terms of information technology nor semantically. As a result, purchasing does not know which materials are relevant for the development of new products. Therefore, the product engineer is usually not informed about changes in the material master. Furthermore, unsuitable components are often ordered which then have to be corrected and reordered. This leads to extended delivery times and unnecessary additional costs. The situation is aggravated by the purchasing department's attempt to reduce costs with the help of purchasing strategies. This causes further changes in the material master and subsequently incalculable effects on the orders in development.
Figure 5 shows the improved and already successfully implemented "Future State". The unstructured CAD cluster has been replaced by a CAD product structure that is defined for each order (Fig. 5, CAD structure). It also replaces the pre-product bill of materials. Furthermore, an explicit standard parts model was introduced that is synchronized with the material master. In order to lay the foundation for a research and development process that is decoupled from order development, a CAD cluster for research & development components (Fig. 5, R&D CAD model) is created and linked to the CAD product structure by so-called "Cross Model Based On Clone". Modules transferred from the R&D model to the CAD product structure are thus copied, but retain a link to their origin. Thus, on the one hand, they are decoupled, but on the other hand, they can access their origin in terms of information technology. This technically ensures that innovations in the R&D model can simply flow into the CAD product model.
Organizationally, this is implemented via "owners" of the modules who are responsible for a respective module across orders. This concept gives the company the flexibility to plan modules earlier, independent of the specific customer order, and also to use them better together in different products.
The core of the new concept is the implementation of an automated process between CAD structure, master bill of materials and material master. The CAD structure is defined as the leading model. A newly created CAD model automatically generates a counterpart in the material master. This solves the problem of BOMs and design data that could not be synchronized up to now and makes it possible to automatically derive a master BOM from the product structure at any time. In order to implement this approach, the information management and the previous way of working had to be changed.
Figure 5: Lifecycle map "Future State"
The models were semantically modified in such a way that the elements in the CAD product structure have unambiguous equivalents in the other submodels (Fig. 5, Detail 1, Model Type Alignment). In the process, the originally functional structural semantics of the CAD product structure was transformed into logistically oriented semantics. In order to ensure unambiguousness at all times, relevant assignment cases between the models were worked out and a specific solution defined in each case. An example of an assignment case is profile bars. These are installed in different lengths. In the CAD product structure, the lengths actually used are modeled. Only purchasable standard lengths are listed in the material master. In order to enable a clear assignment between the models, it was necessary to create the option of defining the partial lengths for profile bars to be planned from the CAD product structure.
Only with the solutions for the assignment cases did it become possible to reverse the supply direction and control both the material master and the structured BOM from the CAD product structure. The reverse case, where changes are initiated from the material master, is basically ruled out. By changing the structural semantics of the CAD product structure to a logistical orientation, it is also possible to derive a logistically oriented 3D model (not shown in the diagram), which can be used in this form as a basis for assembly and repairs by service staff on site at the customer.
Further optimization
The future state in Fig. 5 currently serves as the basis for further optimization. It has thus become the actual state from which a new target state is derived. Potential lies, among other things, in a more precise clarification of the interaction between the R&D model and the CAD product structure (Fig. 5, detail 2). Currently, the models are technically held together by one person and the modules are copied with reference to their origin. Here an improvement can be made if it is possible to use the same modules and to adapt them context-specifically in each case. In addition, there is still considerable savings potential in the even more consistent use of these modules across products and product lines. For implementation, however, a more precise analysis of the product spectrum is necessary in advance in order to define which information in the respective modules must be adapted contextually, i.e. for the respective product, and which can be kept generic.
Conclusion and outlook
The example described shows that the optimization of production differs fundamentally from the optimization of the PDP. In production, optimization focuses essentially on saving personnel capacities. In PEP, optimization focuses on intelligent, context- and time-related networking of information. Optimization is achieved by pairing information flows improved by information technology with an organizational clarification of responsibilities for the information created in the PDP along its life cycle.
The use of the PLM-ML makes it possible to make the PEP accessible to an optimization discussion. Its diagrams are independent of any IT systems that may be used later, so that the discussion can be conducted in a vendor-neutral and system-independent manner. In the context of the Do(PLM)Con consulting approach, the PLM-ML can play out another advantage. Since it can be used to map not only the purely functional view but also the semantics and temporal development of the relevant PDP information, it can be used to plan the introduction of suitable IT systems much more precisely and systematically than is currently possible (see Fischer, Brinkmeier 2012).
References
Fischer, Jörg W. et al: Implementing Domain-Integrating PLM Solutions. Do(PLM)Con - an approach to the design and implementation of domain-integrating PLM solutions. In: Industrie Management, Berlin, 27(2011)5, pp. 17-21.
Fischer, J.W., Brinkmeier, B.: Do(PLM)Con - Proposal of a taxonomy for the development of PLM-Architectures. In: ProductDataJournal, (2012)1, pp. 24-28.
Eigner, M.: PLM versus PPS: Future Solutions for Integrated Product and Process Management, In: eDM Report; electronic Data Management, Hoppenstedt Publishing, Darmstadt, (2012) 1, pp. 20-23.
Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage "Ereignisgesteuerter Prozeßketten (EPK)", in: Scheer, A.-W. (Ed.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbruecken 1992. (http://www.iwi.uni-sb.de/iwi-hefte/heft089.pdf).
