PLM support for design platforms in industrialized house-building

Abstract

Purpose

The purpose of this research is to support the customization ability for industrial house building companies striving to offer individualized products but with a strategy which includes a production facility. This is accomplished by analyzing the as-is state in terms of existing engineering assets and by proposing a to-be state using the design platform and product lifecycle management (PLM) support.

Design/methodology/approach

This study is based on design research methodology and collected data are in-depth interviews, document reviews and workshops and method development. The theoretical baseline is product platforms and the design platform.

Findings

The analysis showed that despite use of a platform, inherent assets are disorganized. Still, the identified object-based engineering assets were possible to include in a conceptual proposal for better management, both in the process and product view, using an asset relationship matrix and a PLM system.

Practical implications

The results should be applicable for industrial house building and off-site construction companies and offers an approach to identify and manage their assets and platforms which are crucial to stay competitive.

Originality/value

Previous research on design platforms has focused on engineer-to-order companies within the mechanical industry. The contribution of this paper lies in the application and support of the design platform for industrial house building and the introduction of PLM system support.

Citation

Lennartsson, M., André, S. and Elgh, F. (2023), "PLM support for design platforms in industrialized house-building", Construction Innovation, Vol. 23 No. 2, pp. 265-286. https://doi.org/10.1108/CI-09-2019-0092

Introduction

Companies are continuously faced with requirements regarding technological novelty, shorter time to market, higher levels of functionality and lower prices on their products. This especially applies to companies developing and manufacturing highly customized products. Customization is referred to as abilities and strategies that aim at the design and manufacture of tailored products for individual customers. Depending on where the customer is introduced in the order process, four different business models have been proposed: engineer-to-order (ETO), modify-to-order, configure-to-order and select variant (Hansen, 2003). For the latter two, product platforms have gained success as enabler for efficient customization. Generally, product platforms have been accepted to serve a wide range of products while maintaining business efficiency. A product platform approach can be defined as the development and implementation of technology, components or subsystems that are shared across multiple products (Meyer et al., 2018).

Construction is as an ETO-sector (Gosling and Naim, 2009), as each project carry unique features. Thus, the objective is to streamline the specific projects (Lennartsson, 2012). General contracts imply a client responsibility whereas design-build contracts imply a contractor responsibility. The latter case allows house-building companies to use, industrialized methods with predefinition and prefabrication of their building system, defined operations strategies for their supply chain and deliver client value (Jansson, 2013).

Lessing (2006) defines industrialized house-building (IHB) as a thoroughly developed house-building process with a well-suited organization for efficient management, preparation and control of the included activities, material flows, resources and results for which prefabricated components are used to create maximum customer value. Customer demands are met by the adaptation of product solutions and rapid implementation of novel technology combined with efficient production, where product design is carried out in collaboration with the clients (Bäckstrand and Lennartsson, 2018). A move toward IHB means a shift from project-based production to process-oriented production (Jonsson, 2017). A key element is information management, i.e. in repetitive production, the process is more vulnerable to erroneous information. Still, too much focus on production efficiency may compromise the capability to meet customer demands (Lennartsson, 2012). The building system is a critical asset (Johnsson, 2011) and its boundaries determine the solution range.

Thus, for market segments with high levels of customizations, product development and the design phase become crucial to control, i.e. balance commonality and distinctiveness (Jansson, 2013). Another challenge is technical solutions that are developed in specific projects often have integral product architectures that are difficult to re-use in continuous improvement processes (Jensen, 2014). Introduction of a platform strategy provide means to better manage these issues, but without proper technical support, these challenges remain (Lennartsson and Elgh, 2018).

Product platforms have proved to prolong the average product lifecycle and enable both higher aggregate sales and aggregate gross profit margins over the product lifecycle compared to products which are not derived from a platform (Meyer et al., 2018). Early descriptions focused on efficiently providing a product variety while keeping internal variation low and thereby reach a higher level of standardization in production (Meyer and Lehnerd, 1997). Also, platforms have served as means to efficiently and parallel reach customer segments by featuring commonality in product components and interfaces. Different approaches to conduct platform-based development exist, one being modularization, which is a critical enabler for mass customization and platform thinking. Stjepandić et al. (2015) outline several developments and tool implementations of modularity in the context of concurrent engineering, concluding that the trend is to combine and integrate different technologies such as advanced CAD systems, product configurators, agent-based systems and product lifecycle management (PLM) systems. Platforms and their associated variants pose challenges for conventional PLM systems on the market (Bruun et al., 2015). For this purpose, Bondar and Stjepandić (2018) present support and an approach to cope with challenges regarding the co-creation of shared interfaces and modules. Adding to the difficulties, small IHB companies offering customized products are forced to work project-based. For this purpose, Pokojski et al. (2019) proposes a computer system allowing such companies to capture, store and access project knowledge.

Recent research has focused on product platforms using a more abstract definition; these platforms aim to reuse more of the skills and knowledge (i.e. assets) created in a given company to reach higher efficiency during development and has questioned whether companies could afford not to apply a platform (Johannesson, 2014). Still, component-based product platforms tend to require focused platform development and late-stage customer involvement, which in turn requires knowledge about which future variants are to be derived from the platform.

The design platform approach (DPA) (André et al., 2017) was proposed to enable the efficiency promised by product platform approaches to companies with an ETO business approach which traditionally have not been able to use product platforms efficiently. The focus is on creation, management and maintenance of engineering assets that are used in the process of designing and producing products. Besides physical components and modules, a design platform model is founded on the re-use of engineering assets which can be of various types and that often are ill-structured and un-formalized.

Aim and scope

Previous research on the application of the DPA has focused on ETO-companies within the mechanical industry. However, the contribution of this paper lies in the application and support of the DPA for the IHB industry with the intention of providing these companies the means to become more efficient. The purpose of this paper is to support the customization ability for IHB companies striving to offer individualized products but with a strategy which includes a production facility. This is accomplished by analyzing the as-is state in the company in terms of existing engineering assets and by proposing a to-be state using the DPA and PLM support. The IHB setting also allows for proposing changes to the Design Platform model to fit this industry to a larger extent.

Methodology

This work has applied the design research methodology (DRM) by Blessing and Chakrabarti (2009), illustrated in Figure 1. The methodology follows four stages:

• Research clarification (RC) identifies a research gap and goals with literature studies and analysis as the main means.

• Descriptive study I (DSI) focuses on describing the as-is and to-be situations using empirical data which is gathered through suitable techniques.

• Prescriptive study (PS) introduces support in the studied situation with the aim to improve it.

• Descriptive study II (DSII) focuses on evaluation of the support introduced in the PS stage by comparing the new situation with the as-is description that was created in the DSI stage.

For this study, collected data describes the current state and identifies and characterizes engineering assets in the company. A conceptual proposal for how to improve the situation is suggested, positioning the article in DSI and PS.

Workflow process

The applied data collection methods consist of in-depth interviews, document reviews, workshops and method development. The workflow process for the study is illustrated in Figure 2. The work has been carried out in collaboration with the case company where their experience and knowledge were extracted and used in the design and specification of the engineering assets and the DPA.

In-depth interviews

The semi-structured interviews aimed at identifying intangible sources of knowledge, connected to inherent know-how and experience, which has the potential to become engineering asset objects aligned with the DPA. Five respondents in key positions with extensive experience from the case company were selected. The respondents were: the technical manager; structural manager; main CAD-programmer and the managers for building services (electricity and HVAC).

Document reviews

The interviews revealed that there are a wide plethora of documents residing in the company inventory. Types of reviewed documents include, drawings needed to produce standard configurations, but also design templates and standard operations (STO), describing various issues, e.g. technical solutions, bill of material (BOM) and way of working. To narrow down the scope, one building type was selected for further investigation. The attached STOs from the building type were extracted to describe the couplings between documents.

Workshops and method development

Parallel to the document reviews, the company mapped their production process to provide a foundation for the design platform. The process implicated collaboration between the company and the authors, where the theoretical model was combined with gathered data from the company. Thus, templates with engineering assets were generated by the authors which were filled with data by the company, allowing successive validation of the model.

Frame of reference

A multitude of frameworks, methods and mathematical tools have been described and proposed to make use of platform-based approaches (Simpson et al., 2006). These approaches are methods for efficient customization, which is to be seen as abilities and strategies that aim at the design and manufacture of tailored products for individual customers. This section focuses on product platforms in general terms but also with a focus on IHB.

Product platforms

Robertson and Ulrich (1998) describes product platforms as “The collection of assets [i.e. components, processes, knowledge, people and relationships] that are shared by a set of products,” not only including artifacts in the concept. Through product platforms, companies achieve high levels of product variety, reduced time to market, improved operational efficiency and responsiveness to market needs (Meyer and Utterback, 1993; Muffatto, 1999). Improved customer value is targeted by adaptation of product solutions and swift introduction of new technologies combined with cost-efficiency and lead-time reduction. The use of a product platform, where external and internal efficiency is well balanced, has been acknowledged as a strategic enabler for mass customization and increased competitiveness. McGrath, (1995) includes technology describing the concept as “A collection of common elements, especially the underlying core technology, implemented across a range of products.” Simpson et al. (2006) and Meyer and Lehnerd (1997) stress competitiveness to be a key element.

Platforms are generally described to be of one of either two kinds: the module based (discrete) characterized by sets of components being clustered into interchangeable modules that together form the product; or the scalable platform that becomes adaptable due to letting some of the design variables vary (Simpson, 2004). Modularity is proposed as the main enabler for customization (Hvam, 2008). Bonev (2015) states that modular architectures is a major enabler for being able to reduce the internal variety of organizations through standardization while having high external variety toward the market. This is typically done by using a set of common components which are shared between product variants at the same time as varying distinctive components (variant components) to produce product variants which are differentiated by the market.

Product platforms in IHB

There has been an increasing focus on the platform concept in the construction sector (Thajudeen et al., 2018). Despite the presence of a platform strategy, customized solutions are prioritized over the platform (Bäckstrand and Lennartsson, 2018). Balancing these entities is a key to become successful in product design within house building (Johnsson, 2013). For an ETO-based practice, an integrated product architecture makes platforms and modularity more difficult to apply (Jensen, 2014). Still, by approaching the problem from a modify-to-order/configure-to-order perspective, platform theory can be applied incrementally. Further, Jansson (2013) studied the design phase and concludes that management of distinctiveness and commonality is crucial to master for ETO-companies. To achieve the potential of a platform strategy in IHB it is critical to know the platform scope, i.e. what are the prevailing assets and the network binding these assets together. As product design and production are introduced in real projects, the ability to develop generic solutions to be reused in upcoming projects is hindered.

Predefinitions in house-building platforms are stored in documents (Lennartsson and Elgh, 2018) and within CAD-software, where the aim is to develop BIM-models automatically. The use of CAD-tools in a project setting has less focus on process flow and platform standardization (Lundkvist et al., 2015). For IHB, the primary focus has been on production automation with machine files for robots with the purpose of milling, cutting and nailing components in prefabrication (Lessing et al., 2015). Consequently, more pressure on speed and accuracy is put on deliveries from the design department. According to Jansson et al. (2016), the manual work of quantification and communication of objects is poor, i.e. long lead times and information management in the value chains. Jansson et al. (2019) have conducted a study within IHB to breakdown the product structure within IHB with an approach including BOM to improve digital communication between information systems.

Design platform approach

The DPA (André et al., 2017) aims to enable platform-based development for ETO companies which have not efficiently used product platforms. The DPA supports a transdisciplinary environment (André and Elgh, 2018) and is built on different objects embodying knowledge on processes, synthesis resources, product constructs, assessments resources, solutions, projects and constraints. These objects can be, but are not limited to, physical parts because design reuse can be practiced on an array of different types of embodied knowledge. While previously developed solutions cannot be reused directly, there is often a way to apply generic guidelines, process descriptions, calculations, etc., to arrive at new solutions, guaranteeing the use of verified knowledge in the process. The core of the design platform model is generic product structures and generic process flows which are related to each other. The building blocks of the structures and flows are then related to the different kinds of engineering assets supporting their realization. These engineering assets encapsulate knowledge from different disciplines related to different stakeholders and lifecycle phases. This generates a coherent platform description consisting of engineering assets which are allowed to evolve over time.

Figure 3 shows a Unified Modeling Language class diagram describing how the construct types are related to each other and to a generic part structure, here referred to as the GenericProductItem-class. The GenericProductItem-class and ProcessResource-class act as the core of the model and are seen as containers to which constructs can be linked. The Relation class can be of different types and be instantiated into objects which connects two other objects and holds information about why and of which nature the connection is. A relation object contains rationale of why the relation exists and the type of relation.

To support the visualization of different asset domains, the Asset Relationship Matrix (ARM) is proposed. Figure 4 describes the ARM and how the matrix is composed of inter-domain Design Structure Matrices (DSM) for modeling relationships between objects of the same type and Multi-Domain Matrices (MDM) where objects are of different types. The relationships that are connecting the different objects are instantiated from the following types:

• Process relationships (P) state the sequence order of objects. It foremost refers to the order in which a set of activities or process steps should be executed.

• Resource relationships (R) states if a certain object is to be used as a resource for another object.

• Hierarchy relationships (H) are derived from the tree structure and are not an explicit relationship type in Figure 3, as it implicitly exists in the aggregation relationship of the GenericProductItem class.

The objects populating rows and columns in the matrix are either input, output or intermediate objects used in the process. Constraints do not have an intra-domain DSM and are regarded as input to the process because they embody both customer requirements and internal and external constraints that create the limits within which the finished solution should be valid. Similarly, no intra-domain DSMs exist for geometry and assessment resources because they are considered as supportive resources to other objects. No solution resources are directly interrelated and do not have an intra-domain DSM. Objects placed in rows are to be considered as template objects. Their specific instances are solutions and can be located in the last columns which are the output of the process. Thus, each row object will be connected to at least one solution. The synthesis resource domain consists of all the resources used for design synthesis. Within the domain, subprocesses are linked through Process relations. Resource relations are also used if a synthesis resource is needed for the fulfillment of another and Hierarchy relations are used if a synthesis resource is split into sub-resources. The GenericProductItem domain states the hierarchical relationships between generic product items and embodies the generic engineering bill of material (E-BOM) to which other resources are attached. The Process domain describes the Process relationships between process steps and milestones which have been formalized and generalized. Finally, the MDMs are used for mapping relationships between the different objects. The possibilities become many, but in general, there are three parts: inputs, outputs and intermediate supportive object relationships.

The ARM creates a coherent overview of the heterogeneous content included in the design platform model making it possible to manage engineering assets of different disciplines and the interrelations in single-view. This allows for various analyses of the matrix, e.g. conduct resource planning, investigate change propagation and proactivity in development to ensure that right things are considered in the right order. It also provides a rationale for each variant designed and produced which can be revisited for new projects and maintenance of engineering assets.

Result and analysis

As part of the research methodology, the descriptive phase includes mapping of the current situation of the company. Therefore, this section presents, based on the interview study, the state-of-practice in the case company. As part of the DPA an identification and categorization of company assets were performed followed by a company description and the document review and the analysis.

Case company state of practice

The company offers products such as schools, kindergartens, elderly homes and offices. Knowledge about the clients’ operations is decisive. The overall strategy is to complete up to 90% of production off-site in a factory. The building system is based on volumetric elements in design-build contracts, and the company covers all disciplines. The product portfolio attracts public clients with large budgets. These clients are not afraid of determining a specific frame of demands. The platform development in the company is recurring in the industry (Lessing, 2006). The parallel tracks, the technical platform, and the process platform are distinguished by developing new product solutions and developing the process. Given the characteristics of the construction industry there is no prototyping. Rather, development is carried out in actual projects and if evaluation prescribes, solutions are incorporated into the platform.

The product selected was a dormitory where apartments are positioned in file in two floors (Figure 5). Each apartment is defined by a single volume element. The project is simple but possesses the ability to demonstrate the design platform.

The company has developed a technical platform (TP) (Figure 6), which follows a modular product methodology. There is no product development protocol to follow, rather product families and house models, based on the building system and previous house models, are developed. Development is dictated by sales and architects. The rule of thumb is to keep the balance on 75/25 catalog house/customization, but distinction when a remodeled standard becomes a variant is missing. The TP is illustrated from top level 1 (house) down to level 5 (parts). The superior level is described by parts from the adjacent subordinate level. The platform depends on the house models and their decomposition. Technical demands are divided into 10–15 technical departments. Technical development includes the entire TP, maintained based on rules and demands in the construction sector.

While house model is primary focus, development also includes details and technical systems. Figure 7 describes the platform development in the company. The two parallel tracks, the technical platform, and the process platform are distinguished by developing new product solutions and developing the process to complete the contracts. The protocol for this structure is aligned with Lessing (2006). Development is initiated reactively, e.g. a problem is reported or demands on cost-cuts or regulations emerge and an investigation is started, followed by resource allocation and CAD drawings update. The development project is guided by impact and resource consumption. No other software, besides energy calculations, to model the products is used. The TP is vulnerable to volatile and changing demands, for instance, demands on energy.

Validation and prototyping are done in real projects, given the amount of money invested in the products and also as the technical manager stress “we are a construction contractor.” Similar solutions used in multiple projects, are subject to be incorporated into the TP. Assessment of solutions is based on the building system definition.

The company has decided a general process, describing marketing, sales, project management, tendering and purchasing, including continuous improvements and TP development. The disciplines have assigned responsibilities and own sub-processes formulated. The production process has value flows and work stations are well-described. Focus in production is waste elimination and lean production. In deliberation between the product and the production, the production is prioritized over the ability to configure products.

The use of design templates and standard operations (STO) lay the foundation of know-how, but there are also test reports and energy simulations adding to the experience. However, the technical manager states, “the TP is not really defined or fully documented.” Metadata is not attached to the documents offering no possibilities of better alignments or revision management, and the TP is merely a repository. A substantial part of the contents reside in the heads of the staff. The document review revealed that the number of documents has increased uncontrollably, resulting in a structure exceeding 1.5 million documents. The fragmentation and indistinct interfaces between the levels of the TP yield an increase of variants and documents. The description is also valid in production where knowledge is buried in the heads of the staff and the reward goes to the problem solvers, aligning with Löwstedt (2017). Cross-disciplinary development is scarce and deliveries are not planned according to the TP structure, rather when long lead times demand early purchasing.

Identification of company assets

The interviews aimed at identifying intangible sources of knowledge, connected to inherent know-how and experience, which has the potential to become asset objects aligned with DPA. In Table 1 these asset potentials are presented from the perspective of three prevailing domains in industrialized house building.

In addition to the listed potential assets, know-how on generic project management and turnkey contracts can be added. As for sales and production, the potential assets are rather fixed. It is crucial to excelling in market knowledge to stay competitive. Consequently, to be successful in the segment that the case company adheres to, governmental procurement and the capacity of the product portfolio are decisive. Product families and house models, based on the building system and previous house models, are developed to meet the needs of the market. Most of the potentials can be referred to the design phase, which aligns with the description of IHB being an ETO sector. The listed potential assets are all crucial to master to not destroy the efficiency of the fixed asset, the factory. Still, some flexibility must be allowed for the sales department to not lose contracts on minor adaptations.

Document review and mapping of the guideline standard operations system

For construction projects, construction documents (CD) (drawings, lists and descriptions) are produced, which share information between project participants. There is a uniform categorization of the documents and how they are interrelated. Specifically, the documents include materials, performance, quantities and information needed to complete the project. The CDs are part of the main contract and will be subject to dispute.

The document review aimed at the STOs and how the solutions are linked. The review followed four steps: gather CDs for the house model; extract the referenced STOs; follow the trails from the CDs to the STO database; describing the network of couplings in the database between STOs using a Design Structure Matrix (DSM) (Malmqvist, 2002) approach. As the STOs are incorporated into projects and then becomes CDs they are as mentioned above drawings, lists and descriptions. The STO content ranges from different standards to guidelines in both design and production but also requirements.

Nine series exist in the guideline system. The headings (Table 2) are sorted according to disciplines in the overall construction process. Thus, the logic is based on the guilds that are working as subcontractors and suppliers rather than product architecture, modules or parts. In traditional construction projects, a main contractor is responsible for coordinating work and to procure sub-contractors and suppliers. However, moving toward factory-based production, this division is illogical.

Among the published CDs (162) for the selected project there were references to 30 exclusive STOs. Similar elements refer to the same STOs, e.g. inner walls where references appear repeatedly, mostly to HVAC solutions. There are references to other CDs within the project. When applying the DSM approach in the investigation of the database of STOs, a network structure emerges. Different STOs refer to other STOs; at the extreme, there are six levels in the hierarchy, but more commonly 2–3 levels. Overall, 82 STOs are referenced. Thus, from the initial 30 STOs in the CDs, an additional 52 were added through connections between STOs. There are references to the same document on different levels, i.e. the same STO can be situated on multiple levels in the hierarchy. There are circular references where one document points to another document which then points back. Among the 30 STOs in the CDs, the series 1002–1006 were covered, which means that foundation, electricity and room completion were excluded, i.e. not referenced by the project documentation. In the DSM analysis, series 1000, 1001 and 1007 (1008 remained excluded) were referenced. After the DSM was completed, most objects belong to series 1002, 19 references in the CDs and a total of 53.

These results show that the STO system has a weak connection to the platform concept that the company uses. The document identifiers are based on the guild system and not the product architecture. Another finding is that framing is more described compared to other disciplines which consequently leave the others with a low level of standardization.

In the subsequent phase, the 82 STOs were used as the foundation of a template to identify what assets the company possessed. The attributes were decided according to the DPA. Thus, the headers used were; STO ID, Part, TP receiver, TP document owner, Asset type, Production phase, Room. The attribute “Room” is specific to the construction sector, as it creates a structure of its own and does not easily map to a part structure. Rooms can be seen as a function or the effect of attaching parts to each other in a specific way. Therefore, even though it is considered an object, it is treated as an attribute for each asset. The company then used the template to map and specify the attributes for the assets that they identified. The complete template then worked as the base for creating objects in the PLM system.

Applying the design platform approach by means of a PLM system

To support the DPA, a conceptual proposal (Table 3) and a structured way of managing the identified assets are here presented, based upon a PLM system. The design platform model is object-oriented which makes it suitable to capture engineering assets and to prepare them to be added to a PLM system. As the core of the design platform model consists of a generic process and product view, these are in focus and will be linked to the identified engineering assets. Furthermore, common PLM system functionality was applied which is further described in Table 3.

Product and process modeling in the PLM system

Some process related potential engineering assets were identified (Table 1), but the interviews showed that there were no formalized process. A list and sequence of activities in need of information could be identified which were interpreted as process steps. These steps cover all customer project steps starting with initial customer contact and ending with the finished house. Modeling these as process nodes in the PLM system enables efficient project management and allows monitoring the project progression. Generic engineering assets (e.g. STO objects) can be linked to each step ensuring the correct documentation at the right time. The generic product items can also be linked to the process steps making it more evident where in the process, specific parts are designed and produced. This makes it clear for the production staff as they turn to the PLM system for the documentation describing their production step and related parts. The process is shown in Figure 8.

The first two steps correspond to the sales and design stage whilst difference lines type indicate the preceding production steps in the factory and on-site. The boxes containing several steps, indicate that the steps can be performed in parallel. In addition, general approval flows should be set up for documentation created both inside but also outside projects which builds up the generic platform, to ensure the quality of the generic documentation which is created. Figure 9 illustrates the implementation of the process in the PLM system from an administrator view. Each node is connected to a user role which is notified as the previous node is finished.

Product structure modeling as it is usually practiced in PLM systems in the mechanical industry is not as common in IHB. Following the DPA, generic product items are to be identified and modeled as structures. For the specific case, there is a set of standard houses with generic features that are suitably captured as generic structures. The standard houses, which will each have a generic structure modeled, consist of five types of school buildings, four types of living houses, two types of office buildings and 19 types of sheds. Each generic product item of the generic structure can hold generic engineering assets which can be used for the realization of the part.

Through document reviews and interviews, a first high-level generic item structure could be identified. Figure 10 shows a selection of generic product items that were identified for one of the standard house types as they are visualized in the PLM system. These were structured with focus on function to resemble an E-BOM, meaning that the structure does not take the production process into consideration, rather the house is broken down in logical blocks with the module on top.

Asset relationship matrix and product lifecycle management

As the design platform model prescribes (Figure 3), relations can be created between any object types. However, the PLM system used as a demonstrator only provides few possibilities to link objects together. An overview of the relations is missing in the software and is not a common feature in any PLM system. To support the ARM, a computer support tool with an integration to the PLM system was developed. The application reads the PLM system database which makes it possible to access and work on the same data and thus the same information model. The row objects in the ARM are selected from a database interface where the user selects and classifies depending on type of engineering assets. Figure 11 visualizes the application interface with an ARM example. The ARM is simplified regarding the number of objects which are visualized to make the figure readable. The ARM is automatically constructed, grouping objects of the same type and coloring them for easy identification based on user selection. Hierarchical relations can be directly read from the database while resource and process relations are created manually by the user. The prototype application uses XML to store the matrix. The generic product item structure can be seen at the same time as the process steps. The MDM intersection then act as a production view on the generic product items and thus manifest the generic manufacturing bill of material (M-BOM). The process view is a simplified version and shows the major blocks (Figure 8). The PLM system, combined with the ARM, support the modeling and design phase because design engineers receive an approach which can be used to formalize their engineering assets such as items, processes, tools and know-how in a coherent view. It allows separating the generic design platform model from specific variants delivered to customers. Execution is supported because the PLM system and the ARM application acts as a map of the design platform model, guiding the engineers to knowledge which shortens lead time and increases quality. It opens up to work more focused on standardizing certain parts while keeping other parts open to adaptation. The ARM supports the quotation phase as the tool guides the engineers to what resources that are applicable and making more accurate price estimates.

Discussion

This paper has brought forward a case with a IHB industry company. From the gathered data, potential engineering assets have been identified which creates a baseline for DPA application. A PLM system setup has been introduced aiming to support the management of these assets. Literature proposed tools to support collaborative modular development (Bondar and Stjepandić, 2018) and project-based development (Pokojski et al., 2019) focusing on the mechanical industry. Still, IHB demonstrates other kinds of challenges, one being the factory in combination with high level of customization, traditionally provided by on-site contractors (Jansson, 2013; Jensen et al., 2013). Another challenge being the inability to proactively develop and test new products as houses are produced in customer projects due to size and cost. The existing engineering assets cannot directly be categorized according to the different types as proposed in the DPA. Specifically, this is valid for STOs containing multiple topics such as requirements and solutions or combinations.

The proposal is to separate the STOs and create classes that support their use and maintenance. By introducing DPA, the company can capture, structure, maintain and take advantage of both the prevailing know-how and the continuously generated know-how from projects. By the PLM system support where a generic view is combined with an instance view, work is platform-based and make the engineering assets available by linking them to the applicable process step and generic product items. In turn, this will lead to a more streamlined use of engineering assets with the ability to make the platform boundaries distinct. This is key to know in the decision process of platform capacity and project acceptance.

Previous research concerning the DPA has presented details regarding the identification, modeling, and structuring of engineering assets and the process of creating and supporting the complete DPA by computer applications. This paper contributes to the notion that some engineering assets are already existing and formalized (STOs). It is crucial that these assets are identified and analyzed, when setting up the complete design platform model. A decision then has to be made if the assets can be kept and incorporated as-is or if they have to be changed to fit the overall approach. Another contribution is the suggestion of the production process to be part of the design platform model, allowing for design and production to have a shared information model with their specific views connected. Design can actively populate the generic items with specification which becomes directly accessible from the production steps that is mapped to the generic items.

Figure 12 shows the principle how the generic process together with a generic product structure is instantiated into specific projects where the structure finally becomes a specific variant that can be produced. The generic product item structure holds the generic E-BOM, external requirements such as legal requirements, internal requirements such as production limitations, parametric CAD-models, carry-over parts and calculation models. The variant structure is further enriched with the specific E-BOM, external requirements set by the customer, specific 3D and 2D drawings and calculation reports. In this way a complete model and rationale is captured for each customer project and linked to a generic model increasing the reuse of information. The DPA provides means to work platform-based and become more resource efficient. The PLM system and ARM tool increase the possibility to use the DPA in a structured way providing information traceability and collaboration. By using the PLM system as primary information source for employees active in the process of selling, specifying, producing and delivering a house, the possibility of not losing information increases. Currently, much data is moved manually and transformed between information systems and receivers. Using generic item and process structures means that most work is completed in the specification phase and only few alterations are needed. This is preparing the company information model for the introduction of a configuration system to automatically manage with parts of the specification improving lead times and profitability.

The possibilities how to implement DPA in a company are numerous. Different types of products and business models provide different opportunities for DPA application, which also applies to the ARM. The ARM can be constructed as a management tool, including the primary business processes, primary customer requirements and so on. It can also be applied on a detailed level in a specific team within a company, connecting all specific engineering assets used daily. For a specific product, the number of rows in the ARM can be kept static, as a template. The solution columns can be populated as the project proceeds. In this way, a clear distinction is made between what is generic and what is variant and how these relate to each other. The generic product and separated process view make it possible to either work process or product based.

The prototype PLM system together with the ARM were presented to the company receiving good marks in terms of receiving a technical support tool and a common view of the information. The company plans to proceed and investigate the possibility to implement a full PLM solution and to integrate CAD and enterprise resource planning (ERP). Specifically, the company considered the approach of working with generic product structures and process flows useful, as it enables reuse and increases the possibility to further standardize their product offer and how it is specified for each client. The identification and connection between engineering assets was a new way to analyze the company and was believed to improve the overall platform-based approach.

For the IHB sector, the applicability of product platforms has been investigated previously and the difficulties of this venture are presented in Jansson (2013) and Jensen (2014) and include the balance between distinctiveness and commonality, as well as integrated product architecture. The results from this paper indicate a path forward to better manage those issues. The prevailing protectionism and slow development pace in construction have been discussed extensively, where industrialization and digitization have been promoted as enablers. The results shows that the guild system is still prevailing also for a contractor with an outspoken industrialized focus and orientation. Still, the DPA and the results presented show that there are ways to break up these structures and move toward a more platform-based practice to improve management and control in IHB.

Conclusion

This paper has investigated a company in the IHB industry and its potential for applying the DPA. A PLM system solution has been proposed to support the company in the application and enabling higher efficiency. By standardizing house types in the PLM system and connect them to their realizing assets the sales department will be supported in staying inside the platform. The ARM tool is proposed as a solution to model the connections between design platform objects. The same information model is, thus, used by engineers and production workers which supports the design, production and delivery of the product at the same time as ensuring reuse and quality. Future work includes investigation of other IHB cases and further formalization and detailed mapping of each type of house in terms of parts and documentation to develop the PLM system prototype. Expected challenges include the integration of a PLM system with CAD software and ERP system.

Figures

Figure 1.

Main stages, basic means and deliverables of DRM (Blessing and Chakrabarti, 2009)

Figure 2.

Workflow process

Figure 3.

Generic class relationships of the design platform model

Figure 4.

Generic asset relationship view of the design platform model

Figure 5.

Exterior design and floor plan mock-up of the studied product

Figure 6.

Technical platform (TP) and the five levels, house, module, elements, components and commodities

Figure 7.

Platform development (Green flows) aligned to the on-going projects (Grey boxes) (company internal illustration inspired by [Lessing, 2006])

Figure 8.

Overarching process from specification to delivery on site

Figure 9.

Process definition in the PLM system

Figure 10.

Generic product item definition in the PLM system

Figure 11.

Screenshot of an instance of the ARM application with three constraints, five synthesis resources, six process steps, nine generic product items, two geometry resources, two assessment resources and seven solution resources

Figure 12.

Principles of design platform instantiation

Table 1.

Potential engineering assets in the case company

Sales	Design	Production
The offered range of products and built-in knowledge	Allowed technical solutions, customization/ Adaptability	The production process, build-up and know-how
Government procurement knowledge	Regulations updates, energy efficiency and sustainability	Disturbance log – experience feedback
Market knowledge and demands	CAD software	Factory limitations
	Guideline-system (STO)	Protocols and checklists

Table 2.

Series of STOs and the number of references, construction documents (CD) and total count from the DSM analysis

Series	Heading	CD	Tot
1000	Generic	0	1
1001	Foundation	0	6
1002	Framing	19	53
1003	Framing completion	2	8
1004	Layer	6	7
1005	Water and drain	2	3
1006	HVAC	1	3
1007	Electricity	0	2
1008	Room Completion	0	0

Table 3.

PLM system features introduced using the PLM system

Name	Description	State of practice
Revision management	Managing files and objects stored in the PLM file database	Documents are stored in an MS file structure without support for revision management
User and access management	Enables different professions within the company to have different kinds of access to the data depending on their role	The receivers of specific data are not identified and different levels of access cannot be used
Part management	Allows for modeling and managing product parts and structures such as components and assemblies	Parts are only handled in the CAD software without an assembly structure. Parts are not file based in the company CAD system obstructing reuse between projects
Process management	Enables keeping track of approval status and process progression connected to the data	Some processes are formalized, but no ones are supported by IT tools
Attribute management	Allows for enriched descriptions and different views on objects and linked data	No attribute data exist on current documents except for the data encapsulated in the documents and the categorization according to the guild system. Suitable attributes can support both part structures and room descriptions
Link objects	Makes it possible to link related objects to each other and attach attributes to the link	Existing links are hidden in the documents and cannot be managed separately from document content making it hard to get an overview of how the engineering assets are related
Object orientation	Separation of different classes of engineering assets depending on content and designated use	Only MS office and CAD file formats are used which does not communicate content or use