Keywords

1 Introduction

Modularization as a strategy or as a strategic initiative has become more frequent in manufacturing companies within the last decades [1,2,3]. These strategies and initiatives are driven by the ever increasing customer requirements for more customized products at the same price, speed and quality as mass produced products [4]. The task of introducing the concept of modularization in manufacturing companies are far from simple and affects both people, process, products and manufacturing across the entire value chain [5,6,7]. Manufacturing companies started with the concepts of platforms and modularity in the product domain more than 25 years ago in order to effectively develop and introduce a large number of product variants in short time, while reducing variety-induced complexity and gaining economies-of-scale [8,9,10]. When product platforms are developed and applied in practice, reuse of manufacturing equipment and process increases, thereby increasing the adjustability of the manufacturing system [14], but only more recently have the concept of platform-based manufacturing been introduced [11, 12]. Many of the manufacturing companies that embark on this modularization journey have not been able to reach a complete modular setup and thereby not been able to realize the expected benefits [13]. Hansen P. K. et. al. [13] concludes that a significant lack of methods and approaches within the modularization phenomenon causes these companies to fail and Brunch J. et. al. [14] identified information management as a critical challenge when integrating product and manufacturing system development. Several approaches for modelling product and manufacturing systems have been proposed. One approach is the configurable component method by Claesson [15] which provides a generic modelling building block for objected-oriented models in both the product and manufacturing domains. Another method proposed uses vertically aligned class diagram to combine product variant master with UML Class diagrams [16]. Lastly, an approach for integrated modelling of products and processes, enabling a link between a portfolio of product and components to a portfolio of manufacturing equipment and process, thereby enabling automated matching of components and manufacturing equipment is proposed [17]. Therefore the purpose of this research is to identify a method of how it is possible to create a system in which it is possible to collect data, create information, and conduct analysis in order to support decision makers. The focus in this case will be on how the manufacturing company can identify, collect and utilize its internal data from various IT systems to create both standard analysis that could be reused across multiple focus areas but also one-of-a-kind analysis for specific focus areas. The remainder of this is structured as follows: Sect. 2 describes the ontology, data model and the process. Section 3 presents some examples of both standard and one-of-a-kind analysis. Finally Sect. 4 presents the discussion, while Sect. 5 conclusively summarizes the research contribution and future research direction.

1.1 Methodology

To address the research objectives stated above, this research was conducted using a mixed method of design science and action research methodologies. Design science research was used because of its focus on both rigor and relevance while designing innovative artefacts to be used application domains e.g. organizations, people or systems [18, 19]. Action research was used because of its primary focus to produce practical knowledge that is useful to people in the everyday conduct of their life [20]. So to ensure relevance through action research, one of the researchers was placed in a manufacturing company for a period of 24 month. Through this collaboration the researcher was able to participate in development projects and gaining access to the full, raw and unfiltered company data from both ERP and other IT systems. By using action research and participating in multiple development projects within the company, the researcher was able to establish an in-depth knowledge within each project [21].

1.2 Case Company

The case company chosen for this research is a large manufacturing company, that operate on a global scale with approx. 19.000 employees and an annual turnover of approx. 3.5 B€. It has a long history of designing and developing both products and manufacturing systems internally and therefore holds allot of the insights and knowhow in both domains within the company. Previously this company have conducted modularization initiatives, however these initiatives has been initialized by engineers and product domain experts and only on subsections of the portfolio. There for, there are indications that there is knowledge an overall acceptance and willingness in the design and development part of the organization to embrace the concept of modularization. In the new 5 year company strategy modularization, was put on the agenda from top management and the first company vide modularization initiative was launched. This was done by creating a new department with the overall responsibility of creating and managing modular architectures in both the product and the manufacturing domain. The department works as the main driver for modularization and engages stakeholders across the entire value chain.

2 Ontology, Tables and Data Model

As the overall purpose with this data model is to support engineers and domain experts in creating modular architectures, the process of designing the model have been done through an iterative process with discussion between the domain experts and the model designer. This is done to ensure the model is designed with the capabilities required by the domain experts. Through the discussion with domain experts it has been clear that a holistic view of the business was necessary and therefore information from the three overall domains, market, product, and manufacturing was required. The proposed approach to model the overall business setup by using data describing market, product and manufacturing builds on a company-specific ontology based on how data are modelled in respective IT systems within the company. In Table 1 is a list of the finial tables as created by the ETL process as described by [22] and Fig. 1 display how the tables are modeled together in a UML Class diagram.

Table 1. List of tables created by the ETL process

2.1 Product Domain

In the product domain, the table ‘Material Master’ is used as a connection point for many of the other tables as each material is unique. Each material belongs to a specific material class in ‘Material Class’ table, and depending on which material class a material is assigned to a list of specific characteristics are assigned to each material in the ‘Material Characteristics’ table. Each material can then have multiple BOM´s depending on how many manufacturing sites are producing the given material, meaning one unique material can have multiple BOM´s containing different components. Each material can be produced in multiple manufacturing sites at different times and in different volumes which is in the ‘Production Output’ table. When materials are being produced scrap can occur in the production at different times which is in the ‘Scrap’ table. Each material will also have a cost which can be broken down into cost components (e.g. Material cost, Labor cost, Variable cost) and which is varying over time, manufacturing site and/or vendor. Each material can also be linked to multiple vendors if dual sourced. This is in the vendor table and when materials are purchased, date, amount, cost, vendor are registered in the ‘purchasing’ table.

2.2 Market Domain

In the market domain each material belongs to a material group which is the lowest level in the ‘Sales Hierarchy’ table. This is used for financial reporting based on sales as the sales hierarchy resembles the structure of the sales organization. For each material group it is registered how many products are returned with warranty issues and these are registered in the ‘Warranty’ table. Finally all sales volume, date and location is registered in the ‘Sales Volume’ table.

2.3 Manufacturing Domain

In the manufacturing domain the ‘Equipment Master’ table is used as connection point for all the tables as each equipment has a unique equipment-number. Here each equipment can have a list of characteristics similar to the ‘Material Master’ table. Each equipment will also be registered with an acquisition value and a date of acquisition which is registered in the ‘Equipment Value’ table. Next, each equipment belongs to a specific functional location depending on it´s physical location in the manufacturing site which is registered in the ‘Functional Location’ table. And each manufacturing site, which is registered in the ‘Manufacturing Footprint’ table, is divided in functional locations. Finally each equipment is linked to the ‘Production Resources and Tools’ table so that itis possible to see which equipment is used when manufacturing the materials in the ‘Material Master’ table.

Fig. 1.
figure 1

UML class diagram describing the data model and the relationship between the different data tables

3 Examples

Through discussion with the different domain experts it became evident that the types of analysis needed could be divided into two types. There was the type of analysis that could be used across multiple domains which was mostly used in the preliminary investigations, and there was the deep technical analysis that was highly specialized only to be used one time within one domain. The following will give examples of both types of analysis and what could be concluded based on data the model.

3.1 Multipurpose Domain Analysis

As an initial analysis domain experts would often start by conducting a cost/performance analysis, looking at how a group of product performs on a set of performance parameters compared to its cost. Another analysis could be to create a heat map displaying the sales volume or the manufacturing cost for a specific group of product over a time period distributed over performance parameters. However in the cost/performance analysis, if the group of products found to be within scope was too big, the domain experts would typically select one or two specific product for each performance step and conduct the analysis on these as collecting data for all the products would be too time consuming. Meaning that the analysis would not be fully representative for the entire portfolio but only for those chosen by the domain experts. These types of analysis was previous done by the individual domain experts, meaning they would have to perform the entire ETL process from the company ERP system and typically make the analysis in Excel. This setup is far from ideal as it is both time consuming and the risk of making mistakes is high. Because this new data model is created in a cloud solution where the infrastructure is made so that all the data are weekly updated it was possible to use an ‘of-the-shelf’ BI tool to create a power script that combined the required data and made it possible for the domain experts to use ‘drag-and-drop’ to create these types of analysis always using the newest data. By using this BI tool the domain experts would not only save time by not having to collect data and combine it to perform the analysis, they would also get all the data available in the system and not risk missing out on data or combining it in a wrong way that could lead to a wrong decision being made. In Fig. 2 the process that domain experts now uses to create a heatmap is displayed.

Fig. 2.
figure 2

The process domain experts uses to create heatmaps with the new data model

In a given example where the domain could be an electric motor and the domain expert would like to know what has been produced over the previous 12 month distributed on the performance parameters ‘kilo watt’ and ‘motor efficiency’. The domain expert would simply choose from drop down menus as described in the top boxes in the flow diagram displayed in Fig. 2 and the system would collect data from the tables as described in the lower boxes in Fig. 3.

Fig. 3.
figure 3

Example of the process for an electric motor

These heatmaps could then be used to see if there are areas in the portfolio that are being produced in very low number and therefore should be excluded or covered by another architecture. If the sales volume or the revenue was chosen on the z-axis it would be possible to see if there are areas in the market which is not covered or if there are areas with is obsolete due to low revenue. Furthermore, if the profit was chosen on the z- axes it would be seen if there are areas in the portfolio which are not generating profit or even causing profit loses (Fig. 4).

Fig. 4.
figure 4

Heat map displaying the production volume of motors in a given time period distributed on performance parameters ‘kilo watt’ and ‘motor efficiency’

3.2 One-of-Analysis

The one-of-analysis are made based on specific requests from domain experts. These often came as a highly technical questions and then needed to be broken down in order to identify which data to use, how to combine them, and what analysis to perform. In the following example the questions from the domain expert was: for a group of products that contain several product families, the component ‘shaft’ defines a key interface, how many unique interfaces is there across these product families? From a discussion with the domain expert it was learned that for a shaft it is the shaft type (Spline or normal) and the outer diameter that defines the interface to the remaining system. Based on these information it was possible to create a process that could answer the question. In Fig. 5 is the process that was made and from which tables data was used in order to answer the question.

Fig. 5.
figure 5

The process created to identify the number of unique interfaces from shaft to remaining system.

The first step in the process was to identify all the materials in scope. This was done through the material classes and the material groups from the ‘sales hierarchy’ table. Once all the materials was found, the second step in the process was to open up all the BOM´s down to the lowest level of each BOM (in this case hundreds of BOM´s was opened). The third step of the process was to join a specific characteristic from the material characteristics table on the components in the BOM. This characteristic is a description/categorization that is made on all materials when they are created in the ERP system based on a certain ruleset. The fourth step in the process was to use this descriptive characteristic to search out the finished shaft in the BOM. Now all the unique shafts that was used across these product families was identified. The last step was to join the two characteristics, type and outer diameter to the list of unique shafts and then it was possible to group them first by type and by outer diameter. Here it became evident that there was a high number of different outer diameter sizes, causing a high level of unnecessary complexity in the remaining architecture. Once the variance in the shaft type and outer diameter was found the domain expert would have to identify which of these that where to be used going forward and decide whether the existing product that was not using the new shaft standard should be redesigned in order to reduce complexity.

4 Discussion

The applicability of the method presented in this research is highly independent on the company context in which it is applied. The data model and the ontology on the other hand is highly dependent on both the company and the context in which it is applied. That is because this both depend on how the existing data and IT systems are structed in its current form within the company and for what purpose the model is designed. Although this paper presents only one case company, it serves as an illustration of how this method could potentially be used in other industrial settings. Nevertheless, having only researched one case a few limitations can be identified. Because of the complexity in today´s IT infrastructure within companies and the high level of skill required to create a model like the one presented in this research the collaboration between the data scientist and the domain experts require attention in order to translate highly technical questions into something quantifiable within the data set. Another limitation would be the resources that will need to go into creating and maintaining the infrastructure required to use this method. In this case this was found to be extremely time consuming and required a broad range of stakeholders as the model contains data from various parts of the organization thereby involving a high number of data owners. However, when the infrastructure and the data model are created and in operation the benefit for the company are extremely high. This is because this data repository and data model become one point of access and one point of truth that works across departments so that when engineers and domain experts are to perform an analysis there is one please where they can turn to and acquire the data they need in a fast and reliable way.

5 Conclusion

In this research, a new approach was presented where the collection of data from multiple systems enabled the creation of a data model that assisted engineers and domain experts in the modularization process. Implementing and maintaining a data model like the one presented in this research can have major implications on a company as it would aid the use of data analysis when taking decisions. Through the case it was shown that creating a model like presented in this research had the ability to assist in both ‘business’ decisions but also in answering highly ‘technical’ questions. Future research extending on what is presented in this paper could focus on several topics. Firstly, having a data model like the one presented available should enable more advanced analysis, so one research direction could be to identify what types of analysis could be created and how could these help business become more profitable. Secondly, what effect, if any would the easily availability of valid data have on NPD and other critical business process