The mastery and optimization of the product lifecycle is increasingly being understood by companies as a core competence that represents a strategic competitive factor. This requires the harmonization and integration of different application areas or domains along the product development process in an information technology holistic concept. However, many cross-domain IT projects for the introduction of PLM solutions are currently approached as if classic IT products such as PDM, CAx components or ERP systems were being introduced. Typically, customers consult business strategy and process consulting companies for the design of IT system development concepts, whose main advantage is vendor independence. For the actual implementation, technical IT application consulting is purchased from the IT manufacturers of the specific application area. The integrative project part is often explained away by IT concept buzzwords such as "loose coupling" or service-oriented architecture (SOA).
In the consulting approach described above, there is a gap that is often difficult to see in current IT projects, that makes successful implementation of the project goals more difficult and, in the worst case, causes them to fail. Integration, regardless of much-discussed concepts such as loose coupling or SOA, always means that system elements and their relationships from IT systems in one domain must also be found, at least in part, in IT systems in other domains. This increases the demands on the conception of product models for the implementation of such systems and consequently requires methodical approaches, embedded in new approaches of PLM Solution Consulting. The article explains some of the current difficulties and shows how they can be solved by using the Do(PLM)Con method.
This article appeared in 2011 in the following source
FISCHER, Jörg W.; Lammel, Bernhard; Hosenfeld, Dirk; Glauche, Marc; Brinkmeier, Bernd:
Implementation of domain-integrating PLM solutions.
Do(PLM)Con - an approach to the design and implementation of domain-integrating PLM solutions.
In: Industry Management,
Berlin, 27(2011)5, pp. 17-21.
(ISSN 1434-1980)
Current IT solution development in product development
Computer use and IT systems enable digital data to be generated and managed. The systems currently used in product development can essentially be divided into the following two IT system types according to their purpose.
- Authoring systems,
are systems that are responsible for generating the relevant data. They can be used to represent data sets, they offer functionality to enrich these data with information and to model relationship networks between them. Typical examples of such systems are CAx and DMU systems. Typical client applications such as the PLM rich or thin client are also included. - Data Management Systems,
are systems that provide the functionality to manage and secure the data generated by the authoring systems.
The data management systems used form the basis of an information technology concept for product development. Figure 1 shows the main domains involved in the product development process. In addition, the IT system classes typically used for the data management systems and their application horizon in the course of the product development process are listed. In the realization of a domain-integrating PLM concept, these are the IT system classes that are considered in discussions about merging processes and data. In particular, such discussions focus on the integration between PDM, ERP and configuration systems.
The task of PDM systems is the administration, provision and process management in the creation of geometric product data. ERP systems provide the necessary functions for managing all resources, data and information required for manufacturing, sales and customer support. The IT system class "configuration systems" became necessary due to the increasing customized mass production. Its essential task is the automatic configuration of defined product instances. It is used in production to determine parts required for a defined product instance (the variant ordered by the customer) and to check their construction work in the specified configuration [1].
Digital factory systems support the holistic planning, realization, control and continuous improvement of all essential factory processes and resources in connection with the product. As one aspect, this includes corresponding authoring systems for the methods of the Digital Factory. On the other hand, various users have meanwhile developed IT data management systems for the digital factory under the name Manufacturing Process Management, which provide and manage the data accumulating in the context of their application over the life cycle (see VDI 4499 Sheet 1:2008-02).
Data management systems for the domains of electrical development and software development are used to manage electronic mechanical elements, their components and the corresponding software statuses. Currently, such systems are often implemented as individual software or developed on the basis of PDM systems.
The methodical technical problems of a domain-integrating PLM
PLM solutions form the functional, administrative and information technology backbone of the product development process. The idea of PLM essentially arose at the end of the 1990s from an extension of PDM systems. The goal is to manage the relevant data and information about a product throughout its entire life cycle.
Before implementing such an integrated product model, the question arises as to which integration areas it should cover. Figure 2 shows the main integration dimensions of PLM. The representation essentially follows Eigner, Bitzer and Burr [3]. Integration via the "lifecycle" axis spans the product lifecycle of a product from the product concept to product support, so that product development and production planning can work in parallel as part of concurrent engineering. With the blurring of the classic trade-like separation of the various domains (electrical, mechanical, IT), there is also a need to integrate product models along the axis domain, i.e. the various application areas/trades. In order to be able to supply the customized products demanded by the global market at reasonable cost, the development of modular building blocks that can be used in different product lines is becoming an important competitive factor. Consequently, integration must also be carried out via the "Product Lines" axis. If the goal is to implement an integrated product model, it is necessary to define its implementation space within the framework of these dimensions (Fig. 2, A).
An example of a current IT landscape that can be found in many industrial companies (e.g., in the automotive industry) is outlined in Figure 3 (Detail A). Individual IT system solutions have evolved around an evolved product development process that is generally not very harmonized. With the trend towards standardization of software, standard solutions such as PDM and ERP systems were then implemented. Currently, the goal is to reduce the number of individual systems and to integrate their data and functional content into existing standard solutions. With the need for cross-domain PLM, the task in the future is to define a suitable IT system architecture that can implement this approach and to implement it technically in an evolutionary process, taking into account the existing system architecture.
An ideal image often propagated in this context (see Fig. 3, detail B) is to loosely couple existing systems (e.g., PDM, ERP, configuration systems) via a so-called service bus. The idea pursued by this approach is to have each of the participating systems offer standardized "services" that can be understood and used by the other participating systems.
When implementing such an approach, there is often the hope that all that is required is the implementation of suitable services in order to solve the integration problem as if by itself and that complicated clarification of technical and political problems between the domains involved is no longer necessary. However, such an ideal picture is not realistic. Services and SOA designate an IT architecture paradigm which aims at an IT-technical copllication of systems. Such approaches do not provide a solution for business problems.
If we go one step deeper in the analysis of the situation, we can see that it is not as simple as shown in Fig. 3 (detail B). IT systems in the product development process provide methods that realize product development use cases. Examples of such use cases include the creation of CAD documents, BOM entries, and the audit-proof management of such documents over the course of product development. The product data created and modified as part of the use cases is mapped in the data management systems of the respective domains in the form of networked product models. To accomplish this, IT systems provide metamodels with which these product models can be mapped.
The integration of different domains pursues the essential goal of realizing use cases that were not feasible before. One example of such a use case is the provision of a digital product prototype that can be configured on the basis of options selected by the customer.
To realize such use cases, data must be merged across domain boundaries. It must be taken into account that in order to enable the integrative use cases at all, new, previously undocumented information content must be added during the merging process. This means that the underlying product models must not only be merged, but their merging must be supplemented by information content. This information content has its own life cycle and must therefore be persistently stored in a system.
Figure 4 shows the "real picture" resulting from this fact. In the various data management systems (PDM, ERP, configuration systems), the product models of the respective application area are mapped. Through the approach to integrate the application areas, in the example shown, partial (models) of the system classes ERP and configuration system are integrated into the product model of the PDM system (Fig. 4, detail A). To realize such a first step of integration, the carrier system of the integration (the PDM system in Figure 3 B) must map model elements of the other systems involved. In a next step, the new information contents are then generated and persistent relationship networks between the elements of the different domains are thereby established. Only this procedure creates the necessary basis for mapping the respective cross-domain use case.
The use cases are executed by the user with the help of functions in IT applications. The applications (e.g. CAD, see Fig. 4, detail C) access the product models mapped in the data management system, make their data available to the user and provide functionalities to work with the model.
Figure 5 shows the relationship. A use case can be fulfilled with the help of one or more technical functions. These functions are technically realized in an application. Whether this is a CAx system, a typical PLM rich client or a browser-based thin client is irrelevant. Applications read the data they need from the product models that are mapped in the respective data management system. In doing so, the applications use the functional scopes offered by the data management system (e.g. a structure preconfigured by the data management system). In order to read the data and execute the desired functions for the user without errors, each application requires a specific semantic consistency of the data. If this is not present, the function cannot be used or can only be used partially. This means that each application restricts the modeling flexibility in the product model due to its requirement for semantic consistency.
Integration of submodels from other domains ultimately means that new content is added to the data model of the data management system that is to carry the integrated data model. Furthermore, integration means that new functions are performed on the same data model. This increases the risk of collisions between the various requirements of the domain-specific applications for semantic consistency of the product data model. Ultimately, this means that, depending on how the integration is set up, it is no longer possible to guarantee that the functions offered will be maintained. When designing a domain-integrated PLM, it is therefore necessary to take into account the relevant use cases, the technical functions they implement, and their requirements for the semantic consistency of the models built up in the process.
This contrasts with the approach commonly taken to date, which focuses only on purely methodological/technical requirements when setting up integrated product models. In this context, it is often demanded that the application integration and the data management systems used be unconditionally adapted to the methodological problems raised in each case. If such an approach forms the basis of an integration project, it is now frequently apparent that the projects are problematic in their implementation and, in the worst case, fail. The main reason for this is that the IT systems used cannot always be adapted to the methodological/technical requirements, and if they can, then only to an extent dictated by the system philosophy.
This means that the idea that IT systems must conform to the methodological concepts of the application areas is no longer tenable. Ultimately, the IT system class, its philosophy and underlying technology have a significant influence on the integrated product model that emerges. As a result, it is becoming increasingly common for the application areas to have to come to terms with the specifications of the IT systems in order to exploit the advantages of an integrated system landscape in the company.
The problem of domain-integrating PLM projects
Nevertheless, many IT projects for the implementation of domain-integrating PLM solutions are still approached as if domain-specific solutions were being introduced.
Often, an IT project approach is followed that distinguishes between a purely strategic/methodological view in which requirements are discussed and described and an IT-technical view in which the requirements are implemented technically (Figure 6, left).
For the methodical project scopes, customers primarily use their own personnel with the help of IT consulting companies, who often have no specific connection to a particular data management system. The main advantage of this approach is the neutrality it realizes. The concrete technical implementation of the solution is then purchased as a consulting service, e.g., from the IT system company that sells the data management system used. This approach is usually based on the expectation that the software company in question will then implement the technical part - if necessary with the help of extensive customization programming.
This approach is still influenced by the time when companies had to have individual software developed because standard software was not available.
When implementing cross-domain product models, however, there is a gap in the approach described because the problem of semantic consistency in the model is not sufficiently taken into account when building the models (Fig. 6, center). This gap makes successful implementation in IT projects difficult and, in the worst case, causes them to fail. The introduction of a cross-domain PLM approach requires a technically/methodologically holistic concept for an integrated model world. Such a concept must be structured methodically and technically in such a way that the necessary use cases can be realized without excluding other necessary use cases through their realization.
Do(PLM)Con, a methodical approach to PLM Solution Consulting
Such an approach is similar in nature to existing systematic approaches such as methodical design or the systematic approach to work structuring.
Such an approach was developed as part of an industrial research project by Siemens PLM and the Beuth University of Applied Sciences Berlin. It is based on the analysis of best industrial practice towards a generic method, the outlines of which are presented below.
The "Domain integrating PLM Consulting Method [Do(PLM)Con]" systematizes the design and implementation of integrated product models. Do(PLM)Con can be used to define a design framework for cross-domain product models. Such a design framework specifies how the product model must be structured in principle in an IT system under given framework conditions (e.g., use cases, influencing factors) in order to meet the specified requirements, but leaves room for individual, company-specific design[4].
In order to define such a design framework, Do(PLM)Con provides a toolbox consisting of various methods, best practice libraries and systematic procedures that help to define and document a technically feasible integrated product model in the various implementation phases. In addition, Do(PLM)Con defines a basic procedure model that includes the following systematic implementation phases.
- Integrated Structure Pre-Framing,
- Structure Influence Factor Analyzing,
- Structure Prototyping,
- Definition of Structure Framework and
- Continues Build and Test of Integrated Structure.
In the first step, "Integrated Structure Pre-Framing", the goal is to define basic solution approaches for the submodels of the integrated product model to be implemented. These are analyzed and documented in the Do(PLM)Con methodology in so-called Realization Packages. A Realization Package defines a possible technical implementation alternative. It contains the use cases to be implemented, the functions with which these should/could be implemented, and the applications that provide these functions (Fig. 7, detail A). By selecting an integration approach in the space of possible integration approaches [4] for the respective Realization Package, the application type, the structuring, the IT system class and the data management system used are also defined (Fig. 7, detail B).
On the basis of this framework definition, the content of the product model to be implemented, the data to be integrated from third-party systems, the necessary interfaces and the responsibility for the resulting data content can be derived (Fig. 7, detail C). The definition of a Realization Package thus establishes a framework of premises for a possible implementation alternative. For each implementation alternative, an analysis is then performed to show the potential but also the implementation risk of the respective Realization Package. A Realization Package is a framework defined at a high level of abstraction that can be discussed and decided upon in the respective decision-making bodies in a comprehensible and transparent manner. The phase ends with the decision-making body determining which Realization Packages for a domain-integrating PLM are considered suitable for further implementation and will be pursued in the subsequent phases.
The premises defined in the Realization Package are followed by factors that influence the respective integrated model in the technical implementation and limit its modeling flexibility. Influencing factors can result, among other things, from methodological order specifications and wishes of the application areas, from the use cases, from the selected integration approach, from the IT system class, and from the architecture and functional power of the selected IT system. These influencing factors are explicated, analyzed and systematically evaluated in the subsequent phase, the "Structure Influence Factor Analyzing". In the process, their importance for the customer/user of the integrated product model is evaluated, as is the effort required to comply with/realize them. Based on the identified influencing factors, Do(PLM)Con provides structuring proposals that are available at the end of the "Structure Influence Factor Analyzing" phase.
Based on the results achieved, prototype structures are built up in the "Structure Prototyping" phase and tested in a way that can be compared with reality. Prototyping is carried out analogously to prototyping as practiced in the automotive industry, for example. Prototypes that can be compared to reality are subjected to extraordinary stresses under "realistic" productive conditions. Thereby the behavior, the applicability, the performance as well as the actual effects of the influencing factors can be analyzed. On the basis of this prototype, it is possible to prospectively discuss influences, efforts and risks during the implementation and thus to sufficiently secure the selected solution. Based on the experience gained, the "Definition of Structure Framework" can subsequently be carried out. In this, a design framework is established that acts as a guiding model for the implementation [4]. The design framework is presented to the project participants and enables a transparent, final discussion in which possible adjustments and compromises across the domains can be agreed and communicated. At the end of this phase, the design framework is approved by management on both the customer and supplier side and the actual implementation, which then takes place in the final phase of the "Continues Build and Test of Integrated Structure", can begin.
Conclusion and outlook
Do(PLM)Con provides a basis that helps to make the fundamentally right decisions in cross-domain PLM projects so that the integrated product models meet the requirements without the need for costly subsequent system adjustments. With the help of Do(PLM)Con, simple and flexible designs of prototypes of integrated product models can be derived. By using prototyping as the underlying design methodology, a concrete design proposal for the structure can be made available in the form of a prototype as an experimental environment, basis for discussion and object of knowledge at an early stage of integration in order to avoid costly rework and to accelerate integration projects that usually drag on for a long time. Do(PLM)Con thus has a lasting effect on reducing the effort required to implement an integrated product model. Likewise, the effort required to maintain and update the structure during application can be significantly reduced.
Literature
- Sinz, Carsten (2003): Verification of Rule-Based Configuration Systems.
Tübingen: Uni-Diss,.http://w210.ub.uni-tuebingen.de/dbt/volltexte/2004/1055/, 10.07.2009. - Kern, E.-M. Distributed Product Development. Framework concept and approach to organizational design. Published by Hamburg-Harburg University of Technology, 2005.
- Eigner, Martin; Bitzer, Michael, Burr Holger: Product Life Cycle with Interruptions. Need for coordination between design and production. In: ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb, Vol. 102 (2007) 9, pp. 582-586.
- Jörg W. Fischer; Marc Glauche: Sketching a Design Framework for Product Structures. Integration of the Application Areas CAx and BOM Considering the Aspects Methodology, Organization and IT Technology. In: ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb, Jahrg. 106 (2011) 3, pp. 127-132.
