PCAT: A Software System for Cross-Product Commonality Analysis in Engineer-to-Order Manufacturing

1. Introduction

Engineer-to-Order (ETO) companies face persistent challenges in managing costs and complexity arising from product variety. While variety is often driven by customer-specific requirements, it is also reinforced by limited reuse governance and fragmented part libraries. When reuse is not actively governed across projects, redundant variants and near-duplicate components tend to accumulate over time, increasing inventory, handling, and engineering effort. In practice, this can be observed in duplicate components that reduce commonality and drive inventory and handling overhead (Trattner et al., 2019), redundant variants that exacerbate product proliferation and raise production and inventory costs (Menezes et al., 2021), and inconsistent procurement setups that add coordination effort through supplier and sourcing diversity (Myrodia et al., 2021).

Research has long shown that higher part commonality can improve operating efficiency and reduce cost (Collier, 1981; Hillier, 2002). Product-architecture choices, particularly the degree of modularity-also influence supplier selection and sourcing configuration, with downstream effects on responsiveness and cost (Chiu and Okudan, 2014; Saeed et al., 2019). Yet, despite decades of conceptual and analytical work, these ideas remain difficult to operationalize in day-to-day engineering and procurement work. In many ETO contexts, analysis of component reuse across products is still performed manually and reactively (Iakymenko et al., 2020).

These issues are typically detected in production, service, or maintenance-for example when an obsolete part is identified during a repair, a supplier issues an end-of-life notice, or an engineer discovers that nominally “equivalent” components differ in interfaces or procurement setup (Romero Rojo et al., 2010). This reactive mode of detection increases cost and exposes companies to life-cycle risks, especially for long-lived products and systems (Collier and Lambert, 2020).

Although enterprise systems such as ERP and PLM contain detailed, structured Bills of Materials (BOMs) and procurement data (Chen et al., 2012; MacCarthy and Pasley, 2021), standard reporting can at times support identifying obsolescence candidates or duplicate part numbers. However, these systems often lack dedicated, portfolio-wide functionality for systematic cross-product commonality analysis without substantial data preparation or bespoke reporting (MacCarthy and Pasley, 2021). As a result, companies rely on ad-hoc database queries, spreadsheet analyses, or vendor-specific customizations (Shih, 2014; Kristjansdottir et al., 2017), which may yield partial insights but do not provide repeatable portfolio-level views that support engineering and procurement decisions at scale.

The academic literature on product families and modularity provides extensive frameworks for managing variety. Studies on product-family and platform development emphasize commonality as a lever for balancing efficiency with customization (Jiao et al., 2007), indices and metrics quantify component sharing (Thevenot and Simpson, 2007); and architectural models evaluate modularity and its effects on sourcing and production (Fixson, 2005). However, embedded, day-to-day decision tools integrated into PLM/engineering workflows remain limited (Mertens et al., 2023). The gap lies not in understanding the value of commonality, but in operationalizing it using available enterprise data in complex engineering environments. To address this gap, we use the literature to conceptualize Product Commonality Analysis Tools (PCATs) and investigate their value through a case study.

From a research standpoint, the paper makes two contributions. First, it defines the concept of PCATs, which is not yet formally defined in research or practice. Second, it demonstrates through the case study how PCATs can support more data-informed discussions in engineering and procurement by making portfolio-level reuse and consistency information accessible from exported enterprise data.

2. Literature Study

Concepts of Product Commonality

The concept of product commonality has long been central to managing variety in manufacturing. Early studies introduced formal indices to measure component reuse across products and showed that higher commonality can reduce inventory, safety stock, and overall system cost (Jeet and Kutanoglu, 2018). Subsequent research indicates that commonality and standardization influence more than cost: they affect perceived differentiation (Wong et al., 2019), can shorten development time when implemented via platforms (Zhang et al., 2025), and may improve supply resilience by reducing dependence on specialized suppliers (Gebhardt et al., 2022).

A large body of work develops metrics for evaluating commonality-from aggregate indices of shared parts to comparative surveys of index dimensions and valuation/optimization approaches that integrate cost, performance, and lifecycle objectives (Zhang et al., 2019; Hapuwatte et al., 2022). At the same time, several studies highlight trade-offs between commonality and differentiation: while standardization reduces costs, it can limit flexibility in meeting diverse customer requirements (Jonnalagedda and Saranga, 2017). Overall, the literature establishes the theoretical importance of commonality, but much of it remains centered on indices and design frameworks rather than practical, day-to-day tools.

Product Families and Modularity

Another research stream emphasizes modularization and product-family design as practical means to manage commonality. Architectural choices determine the degree of modularity, which affects how easily components can be shared across variants (Lee et al., 2025). Modular design enables reuse of components and subsystems across products, reducing engineering effort and procurement complexity (Roy and Abdul-Nour, 2024). Platform studies show that using common subsystems and interfaces can yield production and inventory efficiencies while reducing lead time and improving responsiveness (Galizia et al., 2020).

Recent reviews underline the persistent variety–commonality trade-off and note that fragmented, uncoordinated methods inhibit adoption, making the balance difficult to operationalize (Gauss et al., 2021). Frameworks linking modularity, commonality, and platform strategies address this tension (Bortolini et al., 2023; Hossain et al., 2023) but they largely remain conceptual and do not automatically translate into operational tools for day-to-day engineering decisions. Complementary work observes that while commonality indices are useful for ex post assessment and benchmarking, they do not by themselves guide in-process design decisions; integrated approaches are needed to translate requirements into actionable commonality specifications during ongoing projects (Simpson et al., 2012; AlGeddawy and ElMaraghy, 2013). In the ETO context, (Sohrt et al., 2025) argue that existing architecture methods do not adequately capture the cross-functional and cross-value-chain nature of decision making, while (Grønvald et al., 2025) highlight the need for data-driven approaches that connect modularization theory with practical industrial evaluation. This motivates practical, interactive tooling that makes commonality and modularity insights usable in industrial settings.

Industrial Practice and Tool Support

In practice, routine portfolio-level commonality analytics used by engineering, PMO/business process development, and procurement stakeholders remain uncommon, with reviews noting abundant methods but sparse evidence of sustained industrial deployment (Gauss et al., 2021). Enterprise systems (ERP/PLM) store detailed product structures and procurement data, but they are often implemented and used primarily for operational, transactional purposes and tend to produce per-system, per-item, or per-product views (Haapasalo et al., 2019). Portfolio-level cross-product analytics that link technical and commercial structures are therefore not typically available out of the box, particularly when data must be consolidated across systems and product variants (Hannila et al., 2020).

Consequently, firms often rely on business intelligence (BI) and analytics layers (e.g., data warehouses, reporting and online analytical processing (OLAP) tools) to conduct fact-based cross-product analyses such as product-level profitability or portfolio management (Chen et al., 2012; Hannila et al., 2020). In engineering practice, workarounds are common: engineers or procurement managers export BOMs to spreadsheets and perform manual overlap checks (Iakymenko et al., 2020; Kurniadi and Ryu, 2021), or they commission customized reports from system providers, which can be costly and inflexible when requirements change (Al-Assaf et al., 2024). In ETO contexts, where orders may include unique configurations, this limited tool support reinforces reactive handling of commonality issues that surface during production, service, or maintenance rather than at design time (Iakymenko et al., 2020).

A recurring challenge is data fragmentation across PLM/ERP and adjacent systems, which complicates consolidation for cross-product commonality analysis (Terzi et al., 2010). In addition, many methods require non-trivial database or analytics skills, limiting accessibility for engineers who need quick, actionable insights (Hannila et al., 2019). As a result, potential benefits-reducing unnecessary variation, optimizing sourcing, and managing obsolescence-are only partially realized; systematic reviews highlight fragmentation, weak methodological integration, and challenges in transferring commonality and modularity methods into routine industrial practice (Gauss et al., 2021; Mertens et al., 2023).

Synthesis of Literature Streams and Operationalization Gaps

Table 1 synthesizes five literature streams-commonality indices and valuation, trade-off studies, product architecture/modularity/platforms, industrial practice and enterprise-system tool support, and lifecycle risk/obsolescence-triggered rework-by mapping typical outputs to a concrete operationalization gap observed in day-to-day engineering. The final column links these gaps to PCAT views and functions (e.g., Compare & Filter; Commonality Matrix) that make abstract insights actionable in portfolio-level work.

Literature Discussion and Implications for PCATs

Taken together, the literature offers a strong theoretical foundation for understanding product commonality, supported by decades of work on indices, metrics, and modularization frameworks. However, three gaps remain:

• Limited operationalization. Much of the work is conceptual (indices/frameworks), and recent studies call for IT-enabled decision-support tooling that engineers can apply directly in practice (e.g., model-based or analytics-enabled decision support) (Greve et al., 2022).
• Lack of integration with enterprise data. Although ERP/PLM systems hold BOMs and procurement attributes, studies report siloed data and manual reporting; firms often turn to application-level analytics outside ERP/PLM rather than built-in cross-product functionality (Koskinen et al., 2020; Ji and Abdoli, 2023).
• Reactive rather than proactive usage. In practice, commonality is frequently addressed only after problems arise, not as part of systematic design and procurement processes (Iakymenko et al., 2020; Sierra-Fontalvo et al., 2023).

This gap suggests the need for PCATs that can combine structured data from existing enterprise systems with simple, repeatable visualizations focused on two operations that engineering, PMO/business process development, and procurement stakeholders routinely need: (i) Compare & Filter (multi-product sharedness with attribute slicing and BOM-level/version control) and (ii) Commonality Matrix (presence/quantity consistency across products). In doing so, PCATs can support more proactive, data-informed engineering and procurement discussions.

Figure 1 depicts three persistent gaps that hinder translation of commonality theory into practice: (i) operationalization-indices/frameworks vs. everyday tools; (ii) data integration-fragmented ERP/PLM data vs. portfolio analytics; and (iii) proactivity-reactive issue discovery vs. proactive reuse management. PCATs are positioned as a lightweight bridge addressing each gap with targeted views and routines.

Definition. Drawing on these gaps, we define a Product Commonality Analysis Tool (PCAT) as:

“A PCAT is a task-focused software system that operates on exported enterprise data (e.g., BOMs and item-master records) to provide interactive, repeatable portfolio-level views of component reuse across multiple products and to support engineering and procurement decision-making.”

Terminology note. In this paper, an item refers to a BOM line item/part number. Exact duplicates refer to identical part numbers (optionally including revision) appearing across multiple products; near-duplicates refer to functionally similar components represented by different part numbers. Sharedness denotes how widely an item is reused across a selected product set (e.g., “Used in X of Y products”).

Core functions of a PCAT

The core functions of a PCAT include:

• Portfolio selection and data scoping – selecting a product set, choosing BOM depth, and controlling version sets to define a consistent analytical basis.
• Cross-product reuse quantification – computing and displaying sharedness metrics such as “Used in X of Y products,” usage percentages, and sharedness bands.
• Commonality Matrix visualization – presenting item presence and quantity consistency across products in a matrix view and highlighting inconsistencies.
• Attribute-based slicing and filtering – filtering/segmenting by procurement attributes (e.g., Make-Buy, procurement type, class, lifecycle flags where available).
• Drill-through to BOM line detail – linking aggregate views to underlying BOM occurrences to support verification and follow-up actions.
• Export and reporting – exporting tables (CSV/XLSX) and generating printable reports for engineering and procurement reviews.

3. Methodology

Study Design and Rationale

The value of this tool is investigated through an action-research study with a medium-sized European laser manufacturer, co-developing a lightweight Product Commonality Analysis Tool (PCAT) and evaluating it in day-to-day engineering and procurement work. We adopt an action-research (AR) approach suited to collaborative, in-situ interventions with practitioners. AR structures the study into iterative cycles of diagnosis, planning, action, and evaluation/reflection (Ollila and Yström, 2020; Kantola et al., 2022) with participating engineering and related stakeholders (including PMO/business process development and procurement). The AR study includes two main cycles:

• AR cycle 1: Development of PCAT – focusing on understanding current challenges, translating them into requirements, and developing a workable prototype.
• AR cycle 2: Implementation and test of PCAT – focusing on deploying the prototype in the company, comparing it to existing practices, and evaluating its usefulness in realistic scenarios.

Practitioners involved across the cycles included R&D/Engineering engineers, PMO and procurement participants, who contributed by describing current practices (diagnosis), co-defining tasks/requirements (planning), validating prototype behaviour through walkthroughs and scenario-based think-aloud usability sessions (action), and providing feedback on outputs and usability (evaluation/reflection).

Empirical Setting

The firm was selected as an ETO manufacturer of complex laser systems with long product lifecycles and high variety, where duplicate/near-duplicate items and heterogeneous procurement setups were repeatedly flagged by PMO and procurement participants as pain points. The company sought portfolio-level visibility across multiple released products to support reviews and to reduce manual spreadsheet work. Table 2 summarizes the empirical setting and disclosure constraints.

Action-Research Cycles and Stages

The study followed an action-research (AR) process with two cycles: (1) development of the PCAT prototype and (2) implementation and test in the company. Both cycles followed the canonical AR stages of diagnosis, planning, action, and evaluation/reflection. Table 3 summarizes Cycle 1 and Table 4 summarizes Cycle 2, including participant activities, evidence captured, and outputs used in later stages.

Whereas Table 3 summarizes prototype development (Cycle 1), Table 4 summarizes implementation and evaluation (Cycle 2), combining scenario-based user sessions with a functional comparison to Excel and standard ERP/PLM reporting and collecting verifiable artefacts (bookmarked views, exports, and PDFs).

Data Collection

Data collection. Data were collected across the two AR cycles using interviews/workshops, work-practice artefacts, enterprise exports, and evaluation session outputs.

AR cycle 1 (development). We conducted exploratory semi-structured interviews and informal workshops with practitioners involved in cross-product analysis in the case company (R&D/Engineering, PMO/business process development and a procurement engineer). Cycle 1 involved exploratory sessions with three R&D/Engineering participants, one PMO/business process development participant and one procurement engineer (counts reported at role level for confidentiality). Sessions focused on (i) current cross-product analysis practices, (ii) recurring pain points (duplicates, inconsistent procurement setups, and manual BOM comparison effort), and (iii) requirements for a lightweight, export-based analysis tool. Notes were taken during all sessions; where permitted by the company, sessions were audio-recorded to support accurate reconstruction of requirements and task descriptions. In addition, we collected work-practice artefacts including the spreadsheets, BOM printouts, and ad-hoc query outputs used in current practice. During iterative prototype walkthroughs, practitioners executed the emerging task catalogue (T1–T9) and provided feedback on terminology, layout, and missing functionality.

AR cycle 2 (implementation and test). We conducted five scenario-based usability sessions (≈30 minutes each) using a guided walkthrough and a task-based think-aloud protocol. Each session consisted of approximately 10 minutes of tool introduction and orientation, followed by approximately 20 minutes of task execution and verbalized reasoning while completing tasks T1–T7 (and T9 for export/print). Observation notes were taken during each session, and session artefacts were collected as evidence of task completion and usability issues (bookmarked views, CSV/XLSX exports, and PDF printouts).

Data sources collected. Data were collected in the following forms:

• Enterprise data: multi-level BOM exports (first level and full structure), item-master attributes (Class, Make-Buy, Procurement Type), and version flags (Newest / Newest-approved).
• Work-practice materials: representative spreadsheets and ERP/PLM printouts used for cross-product checks.
• Session artefacts: bookmarked PCAT views, CSV/XLSX exports, and PDF printouts produced during evaluation sessions.

Enterprise exports provided the basis for computing sharedness metrics and building the two PCAT views; legacy spreadsheets/printouts established the baseline workflows for comparison; and session artefacts documented how users executed tasks T1–T7 and which outputs (tables, PDFs) were produced for follow-up action.

The R&D/Engineering participants included two Senior Optical Engineers and one Engineering Manager (Products & ATE). The PMO/Business Process Development participant was a Senior R&D Process Engineering Manager, and the fifth participant was a Procurement Engineer. To preserve confidentiality, participants are reported as P1–P5 by role group.

Table 5 summarizes the participant roles and session characteristics.

Data Analysis

We analyzed the study materials in three steps. We organized the evaluation around four evaluation foci (EF1–EF4), which Table 6 maps to the corresponding data sources, analysis operations, and outputs. First, we derived and refined the task catalogue (T1–T9) from work artefacts (Excel sheets, ERP/PLM printouts, and ad-hoc query outputs) through iterative coding and practitioner review (Ollila and Yström, 2020; Kantola et al., 2022). Second, we performed deductive comparative functionality coding by assessing how each task (T1–T9) is supported in PCAT versus Excel versus standard ERP/PLM reporting, using a Yes/Partly/No scheme with short justification notes. Third, we applied thematic content analysis to session artefacts and observation notes, combining deductive categories aligned with EF1–EF4 (Table 6) and inductive sub-themes derived from observed examples.

4. AR Cycle 1: Development of PCAT

Diagnosis

In the diagnosis stage, we documented how cross-product analysis was performed in practice and where it broke down; the main workflow steps, actors, and artefacts identified are summarized in Table 3 (Action-research cycle 1: Development of PCAT). Engineering, PMO/business process development and procurement participants described a workflow dominated by ad-hoc Excel exports and manual comparisons of printed BOMs. Duplicate parts and inconsistent procurement setups were hard to detect systematically, and existing ERP/PLM reports were largely per-product and not designed for portfolio-level comparison. According to all interviewees, the firm lacked a simple, repeatable way to obtain portfolio-level commonality analytics from existing enterprise data, resulting in reactive, experience-driven decisions.

Planning

The resulting requirements were captured as (i) a task catalogue (T1–T9) operationalized in the prototype (Table 7) and (ii) a consolidated requirements and scope summary in the Cycle 1 planning record (Table 3). We agreed that the tool should be read-only, operate on exported data, and avoid modifying the ERP/PLM systems.

Power BI was selected to enable rapid iteration. Core requirements included (i) portfolio selection and data scoping (BOM depth and version set), (ii) a sortable sharedness list with metrics such as “Used in X of Y”, (iii) a Commonality Matrix that highlights presence and quantity consistency across products, (iv) drill-through to BOM line detail, (v) slicing by procurement attributes (Procurement Type, Make-Buy, Class), and (vi) export/print for follow-up work.

Action

Based on the planning stage, a PCAT was developed. It was created as a lightweight software system for cross-product analysis, implemented in this study as a read-only Power BI application connected to ERP/PLM exports. The application refreshes from ERP/PLM exports (multi-level BOMs and item-master attributes), and allows engineers, PMO/business process development and procurement participants to compare a selected set of released products in two complementary views: Compare & Filter and Commonality Matrix.

A typical analysis starts by (i) selecting the products to compare, (ii) choosing the BOM depth (first-level items or full BOM structure), (iii) selecting the version set (Newest or Newest-approved), and (iv) optionally slicing the results by procurement-related attributes (Procurement Type, Make-Buy, and Class). Results can be sorted, exported (CSV/XLSX), or printed to PDF for follow-up work and review meetings.

Figure 2, Figure 3 and Figure 4 illustrate the two views and an example item-level drill-through.

In the Compare & Filter view (Figure 2), items are ranked by how often they occur across the selected products and can be narrowed down using procurement-related slicers. The Commonality Matrix (Figure 3) complements this by showing, per item, whether it is present across products and whether quantities are consistent. Drill-through (Figure 4) links aggregated metrics to the underlying product occurrences to support verification and follow-up actions.

Evaluation and Reflection

To evaluate the developed PCAT in Cycle 1, we conducted a structured walkthrough of the prototype with five practitioners; the same five practitioners later participated in Cycle 2 (Table 5). Participants executed the task catalogue (T1–T9) using realistic product selections and commented on terminology, layout, and interpretability of the visual encodings (especially the matrix legend). The walkthrough produced concrete improvement actions (e.g., clearer sharedness labels such as “Used in X of Y”, explicit BOM-level and version toggles, and standard filter presets for recurring review scenarios). The resulting refinements and the short user manual were then used as inputs to cycle 2, where the tool was tested through scenario-based usability sessions.

Table 7 summarizes the task catalogue implemented in PCAT, the concrete user operations used to execute each task in Power BI, and the resulting outputs; it also serves as the backbone for the evaluation scenarios. In the user tests, we focused on tasks T1–T7 (and T9 for export/print), because together they cover the end-to-end workflow from selecting a product set to producing a documented comparison result (exported tables and PDF printouts).

Table 8 summarizes the operational definitions used in the prototype and the corresponding data fields and outputs.

5. AR Cycle 2: Implementation and Test of PCAT

Diagnosis

We define pain scenarios as concrete, recurring situations in which current portfolio/BOM handling causes avoidable effort, errors, or delays. We elicited these scenarios in short meetings with practitioners by asking them to describe recent cross-product checks that were difficult or time-consuming, and we translated them into the tasks used in the sessions (T1–T7).

In cycle 2, the diagnosis stage focused on defining realistic evaluation scenarios using the deployed prototype. We elicited concrete pain scenarios from practitioners (e.g., comparing closely related released products, detecting missing components, and reviewing heterogeneous sourcing setups for reused parts) and collected representative BOM exports and the baseline materials (spreadsheets and ERP/PLM printouts) currently used for cross-product checks. This step confirmed the relevance of the task catalogue (T1–T9) and selected T1–T7 plus T9 for detailed testing. The evaluated product sets and datasets were selected to reflect the scenarios raised by participants and to include closely related released variants with comparable BOM structures and available procurement attributes in the exports.

Planning

In the planning stage, we translated the pain scenarios into a structured session protocol and defined what evidence to collect. Scenario scripts mapped the practitioners’ questions to specific tasks (T1–T7), and acceptance criteria were agreed at a high level (task completion without manual joins, clarity of outputs for review meetings, and effort relative to the Excel/ERP baseline). Appendix A1 and A2 summarize the detailed acceptance criteria and session guide. We planned to capture session artefacts (bookmarked PCAT views, exports, and PDF printouts) alongside observation notes.

Action

Cycle 2 action consisted of deploying the refreshed Power BI prototype and running five scenario-based usability sessions using a think-aloud protocol. Each session lasted approximately 30 minutes and followed the same structure: a 10-minute guided walkthrough of the interface and terminology, followed by ~20 minutes of task-based interaction (product selection, filtering, search, quantity mismatch detection, use of the summary chart, and export/print).

The moderator guide and task set are provided in Appendixes A1 and A2. In brief, the walkthrough introduced the tool purpose, key definitions (product, component, BOM level, Make-Buy, Class, and version sets), and the meaning of the visual encodings in the sharedness list and matrix. Participants were instructed to think aloud and to verbalize expectations before interacting. The task set progressed from basic orientation and filtering to targeted search, quantity mismatch detection, interpretation of the summary chart, and finally a decision-oriented prompt (“make a recommendation”). Outputs created during the session (exported tables and PDF printouts) were retained as artefacts for analysis.

Evaluation / Reflection

Evidence from the sessions was analyzed together with the functional comparison against common alternatives (Excel-based workarounds and standard ERP/PLM reports). Across sessions, participants were able to complete the core workflow from selecting a product set to producing shareable outputs (exports/PDFs) without manual copy-paste or multi-sheet joins. This is shown in Table 9, which compares the tool’s support for the task catalogue with (i) spreadsheet-based analysis and (ii) standard ERP/PLM reporting. Commissioned vendor reports and bespoke queries can also be used in practice, but stakeholders described them as costly, slow to obtain, and hard to iterate; they are therefore discussed separately rather than treated as a baseline alternative.

Overall, Table 9 indicates that PCAT provides portfolio-level views that are difficult to obtain with standard ERP/PLM reporting and time-consuming to assemble in spreadsheets. This was most evident for (a) sharedness ranking (“Used in X of Y”), (b) matrix-style checks of component presence and quantity consistency across products, and (c) interactive slicing by procurement-related attributes.

Across the five scenario-based think-aloud usability sessions (~30 minutes each), three R&D/Engineering participants (P1–P3), one PMO/business process development participant (P4), and one procurement engineer (P5) found the matrix view particularly useful for spotting missing components and quantity inconsistencies, while the sharedness ranking (“Used in X of Y”) helped focus discussions on high-reuse parts. The main usability issues related to the visibility of the legend and the discoverability of multi-select behavior in slicers; these were addressed through minor UI clarifications (labels, legend placement, and filter-reset guidance).

Participants also noted that, while portfolio-level views can sometimes be produced within ERP/PLM environments depending on the specific system configuration, more complex or recurring cross-product analyses in the case company typically required either (i) manual spreadsheet work or (ii) commissioned queries/reports from the system provider. They emphasized that commissioned reports/queries involved higher cost, longer lead time, and limited adaptability (fixed scope and slow to change) compared with maintaining a lightweight, refreshable in-house Power BI view.

Similarly, participants observed that customized reports commissioned from system providers typically address a fixed question; for recurring analysis needs that evolve over time, this approach was perceived as less flexible than maintaining a small set of refreshable analytics views.

By reducing manual copying, joining, and reformatting of BOM extracts, participants reported that PCAT shortened preparation time and reduced the risk of comparison errors when preparing engineering and procurement reviews.

6. Discussion and Conclusions

ETO manufacturers frequently encounter challenges because enterprise systems often do not provide adequate support for structured cross-product analysis. To address this gap, this paper introduced the concept of Product Commonality Analysis Tools (PCATs), and developed and tested such a system through an action-research collaboration with a European ETO laser manufacturer. The study indicates that a lightweight PCAT operating on exported enterprise data can make cross-product reuse patterns visible in ways that are difficult to achieve with standard ERP/PLM reporting and time-consuming to build in spreadsheets. In the evaluation, PCAT reduced manual preparation work and improved transparency in cross-product comparisons, enabling more repeatable, data-informed review routines. Specifically, the Compare & Filter view supports reuse ranking (“Used in X of Y”) and attribute slicing that links technical reuse to sourcing discussions, while the Commonality Matrix supports detection of missing components and quantity inconsistencies with drill-through to BOM line detail. Taken together, these capabilities move portfolio-level commonality checks from ad hoc and reactive handling toward more proactive, evidence-based routines.

Implications for Research

This study contributes by defining and empirically instantiating PCATs as a distinct class of lightweight, task-focused analytics overlays that make established commonality and platforming ideas usable with exported enterprise data. The contribution is not a new commonality metric; rather, it is a practical operationalization pathway that connects well-known theory to repeatable day-to-day analysis routines. This matters because prior research on modularity, commonality, and platforming highlights the performance impact of complexity reduction, but the translation of these concepts into everyday, enterprise-data–based decision support remains challenging (Fixson, 2007; Zhang, 2015).

More specifically, PCAT operationalizes several methods for reducing product variance that are prominent in literature:

• Standardization and part rationalization as a life-cycle cost lever. Prior work argues that increasing commonality and modularity can reduce cost through mechanisms such as reduced process complexity and economies of scale, and can improve manageability of product complexity (Fixson, 2007). PCAT supports this principle by making reuse patterns explicit across multiple products (e.g., reuse ranking and cross-product presence/quantity checks), enabling stakeholders to identify where commonality is strong and where reuse breaks down.
• Platforming and modularization as mechanisms to manage variety. Platforming research emphasizes reuse of components/subsystems and interfaces across a product family as a means to offer variety efficiently, and reviews report benefits such as reduced development time, reduced system complexity, and reduced costs (Zhang, 2015). PCAT contributes a practical support layer for such discussions by providing portfolio-level views that help inspect reuse footprints and deviations at BOM-line detail, which can inform platform and modularization decisions.
• Variety reduction procedures that link internal and external variety. In ETO settings, where high variety is expected, literature discusses modular configurations and the use of standard items as strategies to manage variety and improve cost/lead-time (Gosling and Naim, 2009). Related variety-management work also emphasizes the value of transparently linking internal (component/module) and external (finished-goods) variety using enterprise data such as BOMs and master data, although applicability is noted to be strongest outside pure ETO contexts (Staśkiewicz et al., 2022). PCAT complements these strategies by enabling repeatable cross-product analyses that support structured reviews of reuse, inconsistencies, and comparison outputs without requiring intrusive ERP/PLM customization.

Positioning PCAT as a tool concept therefore complements the literature by specifying a minimal set of portfolio views and operations needed to make commonality and platforming concepts actionable within typical enterprise-data constraints, and by providing empirical evidence from an ETO setting where variety is expected and costly (Fixson, 2007; Gosling and Naim, 2009; Zhang, 2015).

Implications for Practice

For ETO manufacturers, the main practical implication is that cross-product analysis does not necessarily require intrusive ERP/PLM customization. A read-only analytics layer can provide actionable portfolio views while preserving existing transactional workflows. The export/print features further support organizational handoff by turning analysis into shareable artefacts for engineering and procurement-aligned reviews (e.g., reuse rationalization, sourcing harmonization discussions). In practice, this suggests a pragmatic progression: start with export-based visibility (PCAT), stabilize review routines, and only then consider deeper integration if recurring decisions justify it.

Limitations and Future Research

Findings are based on one company and on export-based data integration. Tool usefulness depends on the quality and completeness of exports and the availability of procurement-related attributes in the item master. The prototype is read-only; therefore, it supports identification and decision preparation rather than implementing changes inside enterprise systems. The evaluation was based on a limited set of scenario-based sessions; while sufficient to demonstrate feasibility and perceived usefulness for the selected tasks, it does not establish long-term effects on portfolio outcomes.

Future work should test PCAT deployment across additional ETO contexts, incorporate more lifecycle-risk indicators when available (e.g., end-of-life flags), and examine longitudinal effects on duplicate reduction, reuse governance, and procurement harmonization. In addition, further studies could compare different integration strategies (export-based overlays versus deeper system integration) under varying data-quality and organizational constraints.