1. Introduction
The constantly changing conditions require companies that develop technical products to continuously adapt and realign themselves. The globalization of markets and the associated increase in competition, the faster pace of change, the higher demands placed on products and services and the resulting greater complexity, as well as technological advances, are just a few examples of reasons for transformation (Reference KotterKotter, 2018). For developing companies, such transformations primarily affect their core business: engineering. The need to redesign engineering is necessary to constantly address latest threats, maintain superiority, and leverage technological advances (Reference Zimmerman, Gilbert and SalvatoreZimmerman et al., 2019). However, the truth about digital transformations is that 70% of them fail. This is mainly due to a lack of strategy, an unclear scope of transformation, and vague goals (McKinsey & Company, 2018; Reference Forth, Reichert, de Laubier and ChakrabortyForth et al., 2020; Gartner, 2020).
A promising approach to avoid these pitfalls is a capability-based approach. A well-designed capability map converts abstract strategies into concrete implementation plans while providing a common language that bridges business and technological perspectives. Studies show that capability-based transformations are more likely to succeed. They are also significantly more effective, which is reflected in faster implementation and lower costs (Capstera, 2025). For this reason, an engineering reference capability map is presented. It is suitable for obtaining an overview of engineering capabilities and serves as a starting point for creating company-specific capability maps. The map should therefore form the foundation of engineering transformations, making them more systematic, efficient and successful.
2. State of research and related work
2.1. Capability
To develop an engineering reference capability map, it is first necessary to understand what a capability is. A capability refers to an organization’s ability and capacity to achieve a specific goal, result, or business purpose through the coordinated use of people, processes, technologies, information, and resources. It describes what an organization can achieve and thus forms an abstract, stable representation of organizational potential. Capabilities serve as structural building blocks of enterprise architecture and enable the analysis, design, and further development of organizational performance (Reference HomannHomann 2006; Reference Simon, Fischbach and SchoderSimon et al., 2013; Reference Helfat and PeterafHelfat & Peteraf, 2003; The Open Group, 2022; Reference Klinkmüller, Ludwig, Franczyk, Kluge, Abramowicz and TolksdorfKlinkmüller et al., 2010).
To clearly and unambiguously distinguish capabilities from processes, competencies, and technologies, they have the following characteristics. Capabilities are stable, abstract, and organizationally decoupled functional building blocks that describe what an organization can achieve, regardless of how this achievement is implemented. They are characterized by a high degree of temporal stability, as they represent structural elements that are valid in the long term, while processes, roles, and technologies change. Thanks to their implementation agnosticism and decoupling from organization, processes, and IT systems, they offer a common, cross-functional language between business and IT. Their modular and hierarchical structure allows for the structuring of higher-level capability domains down to detailed sub-capabilities, thus forming an expandable architecture of organizational performance. Finally, capabilities are always goal- and outcome-oriented. They are geared toward concrete business results and combine strategic intention with operational implementation. (LeanIX, 2025)
2.2. Engineering capability maps
Several capability maps already exist in the context of engineering. However, they have a limited scope and do not consider all aspects of engineering. Examples of existing engineering capability maps with a focus on digital or model-based working methods are the Model Based Capability Map from INCOSE (Reference Hale and HohebHale & Hoheb, 2020) and the PLM capability map from the PROSTEP AG (Reference WittkopWittkop, 2020). Both describe important parts of engineering, but are limited to the sub-areas of Model-Based Systems Engineering (MBSE) and Product Lifecycle Management (PLM), respectively. As a result, not all the capabilities required in engineering are taken into account.
Capability maps also already exist in the field of IT, that cover relevant sub-areas necessary to enable a digital way of working. For example, Forrester presents a reference IT capability map (Reference BetzBetz, 2024). This covers administrative, operational, and support capabilities that are necessary for the operation of an IT department. However, these capability maps are largely decoupled from the engineering domain, so that no connections or dependencies between engineering and IT capabilities can be mapped or identified.
Furthermore, there are models and overviews of the engineering domain that are highly detailed and comprehensive, but operate at a different level of abstraction than capabilities. For example, the Digital Engineering Competency Model (DECF) (Reference Hutchison and See TaoHutchinson & See Tao, 2022), the ASPICE process maturity models (VDA, 2017; VDA, 2023), and the INCOSE (Reference Walden, Roedler, Forsberg, Hamelin and ShortellWalden et al., 2023a) and GfSE manuals (Reference Walden, Roedler, Forsberg, Hamelin, Shortell, Endler, Kaffenberger, Rambo, Halama and BuschWalden et al., 2023b) describe the necessary competencies, processes, and guidelines for engineering, but neglect the level of strategic capabilities.
Overall, none of the related works presented, cover all the necessary capabilities in engineering to support a strategic engineering transformation. Nevertheless, they serve as an important basis for the development of the engineering reference capability map. By summarizing, supplementing, abstracting, and/or detailing the existing content, they contribute significantly to the development of the desired capability map.
3. Research design
3.1. Research questions
The state of research and related work described above reveals a research gap, that there is no comprehensive and detailed overview of the whole engineering domain at the capability level. This engineering reference capability map serves as a framework and central building block to support in-depth and comprehensive engineering transformation in industrial companies that create technical products, systems or services. With its help, company-specific and individual gaps, needs, potentials, and goals in the engineering domain can be identified and derived. To develop this engineering reference capability map, the following research questions must be answered as part of the associated research:
-
1. How is an engineering reference capability map structured?
-
2. What capabilities does an engineering reference capability map consist of?
-
3. How can the capabilities be described?
3.2. Research method
The development of the engineering reference capability map followed the research method for developing generic capability maps according to Reference Van Riel and Poelsvan Riel & Poels (2023). This research method enables the creation of capability maps specifically tailored to a particular area of application through its seven steps. It is therefore suitable for adaptation to the engineering domain, as there is a lack of similarly detailed domain-specific methods. First, the domain must be selected. Second, an understanding of the goals and content of the selected domain must be acquired. Afterwards, an initial draft of the capability map is created in the third step. To determine when the drafted map is stable and the design process can be completed, stability criteria must be defined in the fourth step. Verification is planned in the fifth step. To do this, relevant stakeholders and organizations that can be used for verification must be identified. In the sixth step, verification is carried out accordingly. The resulting changes are incorporated iteratively so that the capability map is refined until the stability criteria are met. In the seventh step, the changes made during verification are documented. In the following sections the application of the research method steps to the engineering domain is presented.
4. Development of the engineering capability map
4.1. Domain scope
The scope for the capability map development is tailored to the engineering domain. Engineering refers to the systematic, interdisciplinary application of scientific and technical principles to the development, implementation, integration, and use of technical systems throughout their life cycle (ISO/IEC/IEEE, 2023; Reference Walden, Roedler, Forsberg, Hamelin and ShortellWalden et al., 2023a). In this case, the technical principles are expanded to include supporting and enabling aspects that help to execute the development, realization, integration, and use of technical systems throughout their life cycle. In addition, due to the increasing digitalization of engineering, the focus is on digital engineering. Digital engineering also considers all disciplines, life cycle phases and activities, but as a digital approach, it primarily uses system data and models to create an authoritative source of truth (U.S. Department of Defense, 2018). Therefore, also IT capabilities are in scope.
4.2. Domain understanding
To gain a comprehensive understanding of the content, purpose of value creation, and objectives of engineering, a literature review was conducted. The results of the literature review consist primarily of scientific publications, established maturity models, reference manuals, white papers from consulting firms and tool vendors, as well as existing capability maps from the engineering and IT sectors. Table 1 summarizes the 21 sources and results of the literature review, that describe the understanding of engineering and serve as input for the development of the engineering reference capability map. Key engineering terms such as systems engineering, product-/systems- and application lifecycle management, digital engineering and engineering IT were used. This ensures that the most important engineering content is covered without delving too deeply into individual specialist areas.
Results of literature review for understanding the engineering domain
However, the listed literature sources do not describe the engineering domain at the same level of abstraction. The sources contain processes, competencies, technologies, capabilities, maturity levels, and strategies. Although these sources provide a good understanding of the engineering domain, they must be detailed, abstracted, or summarized depending on the level of abstraction to achieve a uniform level of abstraction at the capability level.
4.3. Initial design
Before the capabilities are collected from the previously identified sources, the basic structure of the capability map must first be defined. To do this, both a horizontal and a vertical structure must be established based on existing classification frameworks or related works.
For the vertical structure, the engineering reference capability map is based on the APQC cross-industry process classification framework (APQC, 2023) and the Capstera Capability Map (Capstera, 2025). Since the APQC framework is process-oriented, it must be adapted for an engineering reference capability map. While the original APQC framework consists of five levels, the engineering reference capability map consists of the following four levels:
-
• Level 1: Capability Category – Highest level of capabilities used for horizontal structuring.
-
• Level 2: Capability Group – Groups of capabilities that together realize an area of engineering.
-
• Level 3: Capability – Individual capabilities that can be largely distinguished from one another.
-
• Level 4: Sub-Capability – Subordinates that describe individual parts of capabilities in detail.
As already described for the vertical structure, the first level serves to define the horizontal structure so that it continues across the other vertical levels. Building on existing and established frameworks for capabilities, the engineering reference capability map is divided into the following categories:
-
• Technical Core Capabilities (TCC)
-
• Technical capabilities that directly contribute to the development of products.
-
• Lifecycle Management Capabilities (LMC)
-
• Capabilities for managing and coordinating activities throughout the entire product lifecycle.
• Cross-Cutting Capabilities (CCC)
-
• Discipline-spanning capabilities that influence multiple technical and organizational areas.
-
• Supporting Capabilities (SC)
-
• Organizational and administrative capabilities that support operational engineering.
-
• Enabling Capabilities (EC)
-
• Technological and infrastructural capabilities that enable other capabilities.
While the categories technical core capabilities, supporting capabilities, and enabling capabilities were adopted from established capability frameworks (The Open Group, 2022; Reference Leonard-BartonLeonard-Barton, 1995), the categories lifecycle management capabilities and cross-cutting capabilities are own engineering-specific extensions. This expansion is driven by the highly diverse and complex engineering landscape in terms of lifecycle phases (specification, implementation, industrialization, etc.) and disciplines (mechanics, electrical/electronics, software, etc.). The two additional capability categories allow the consideration and classification of both lifecycle phase- and discipline-spanning capabilities.
The hierarchical breakdown of the Level 1 capability categories into Level 2 (capability groups) and Level 3 (capabilities) is shown in Figure 1. In total, the five Level 1 capability categories are divided into 17 Level 2 capability groups, which are divided into 46 Level 3 capabilities. ISO/IEC/IEEE 15288, an established standard in systems engineering, provided a structuring template, especially for the technical core and lifecycle management capabilities at Level 3 (ISO/IEC/IEEE, 2023).
Hierarchical structure of levels 1-3 of the engineering reference capability map
All levels of the engineering reference capability map are visualized based on the periodic table of elements. This visualization has the advantage of high cognitive recognition, as everybody know the periodic table of chemical elements. In addition, on the one hand, it is well suited for grouping individual elements with explicit classification logic and, on the other hand, for distinguishing them from one another. Furthermore, its grid formation and simultaneous representation of several dimensions visually reduce complexity (Reference Lengler and EpplerLengler & Eppler 2007). Each capability therefore is represented as an element, like the example of the sub-capability “Requirements Elicitation” in Figure 2. To its name, each capability has a unique symbol, which is an abbreviation of the name. Further information regarding the hierarchy and capability type is contained in the corners of the tile. The symbol of the associated capability category can be found in the upper left corner. This also determines the colour of the tile. Technical core capabilities are blue, lifecycle management capabilities are green, cross-cutting capabilities are yellow, supporting capabilities are purple, and enabling capabilities are pink. The lower left corner indicates the capability group, and the lower right corner indicates the capability. All corners described are only filled in for sub-capabilities. Capabilities on higher hierarchy levels have empty corners.
Description of a capability tile from the periodic table of engineering capabilities
The capability type is specified in the fourth corner at the top right for all Level 3 and 4 capabilities. Level 1 and 2 capabilities are not assigned to a type, as clear type assignment does not add any value at this level of abstraction. The engineering reference capability map distinguishes between business capabilities (BC) and IT-capabilities (ITC). Since digital working is not possible without IT-skills, resources, and technologies, IT-capabilities are essential, especially regarding the digital transformation of engineering. In the capability map presented here, the two capability types are defined as follows:
-
• Business Capabilities (BC): Organizational abilities to translate strategic goals into value-adding activities and achieve business results through processes, resources, and competencies.
-
• IT-Capabilities (ITC): Technological and information technology abilities that ensure the development, operation, and development of digital tools, data flows, and applications.
Due to the large number of capabilities at the fourth hierarchical level, the sub-capabilities cannot be presented as a periodic table within the scope of this publication. Therefore, the sub-capabilities are simply listed in Table 2. In total, there are 45 TCC, 33 SC, 16 EC, 24 LMC, and 19 CCC in the fourth hierarchy level of sub-capabilities. Thus, the fourth level comprises a total of 137 sub-capabilities.
Level 4 engineering reference sub-capabilities
In addition to the hierarchy and type information that can be viewed directly on the respective capability tiles, each capability is described in detail in a profile, as shown in Figure 3 using the example of the sub-capability “Requirements Elicitation (REl)”. This profile contains information regarding the name, symbol, hierarchy, and type. Furthermore, the profile contains a description and the benefits of a successful implementation of the capability. Since a capability always has an impact on the four fields of action of an engineering transformation (Reference Wyrwich, Trienens, Hovemann and DumitrescuWyrwich et al., 2025), the respective effects on the product, processes & methods, organization, and IT systems are also listed. In addition, each capability can be implemented in different ways, and the implementation can be measured differently. For this reason, possible specifications and exemplary KPIs are provided. Finally, the dependencies between the capabilities are considered using the following types of relationships:
-
• Supports: Contribution to the effectiveness of capabilities without being a prerequisite.
-
• Contains: Sub-capabilities that represent sub-aspects of the higher-level capability.
-
• Requires: Dependence on the existence/characteristics of other capabilities to be implemented.
-
• Linked to: Relationship between capabilities without a hierarchy or dependency.
The detailed description and linking of capabilities ensure that there is no redundancy or inconsistency within and across hierarchical levels.
Capability profile using the example of “Requirements Elicitation (REl)”
4.4. Stability conditions
In the case of the engineering reference capability map, the criteria that determine when the capability map is stable are based on the rate of change or the incoming change requests from the verification partners. This means that the following stability criteria are defined: 1. No new capabilities at the levels 1-3; 2. No changes to the capability structure or its characteristics; 3. No fundamental change requests/suggestions from the verification partners. The decision that a stability criterion is no new capabilities at levels 1-3 and that level 4 is not considered is based on the reference nature of the capability map. Since this capability map is intended to apply to many companies of various industries, sizes, and depths of value creation, fundamental completeness and accuracy up to capability level 3 is more important than at the detailed level of level 4 sub-capabilities. Since the level of detail at level 4 is already very deep, it is difficult to reach agreement across all companies, as these can vary greatly. Any adjustments, additions, or fundamental customization must be carried out in the specific application of the capability map within the framework of a company-specific engineering transformation.
4.5. Case study sampling
The case study to verify the engineering reference capability map consists of 29 Stakeholders from seven different sectors. The distribution is as follows mechanical and plant engineering (6), automotive/agricultural engineering (6), research/science (6), household appliances (6), consulting (3), and automation technology (2). Within these sectors, the verification process primarily involved stakeholders who either have strategic responsibilities, company-/engineering-wide decision-making authority, or direct users from the engineering department. The positions of the stakeholders thus range from Division/Department Manager (6), Systems Engineers (11), Project Manager (2), Developers/Engineers (2), Research Associates (6) and Consultants (2). The verification therefore promises to provide an assessment of applicability and comprehensibility across the entire engineering, from a strategic to an application-oriented perspective.
4.6. Verification
The engineering reference capability map was validated in an expert survey using a web-based questionnaire according to Reference Prat, Comyn-Wattiau and AkokaPrat et al. (2014). A website was set up for this purpose and made available to the stakeholders described above. The structure and content of the capability map were explained, allowing the stakeholders to interactively explore the hierarchy levels and the content of the capabilities. To facilitate the evaluation of the subsequent feedback, users were only required to enter their company’s industry, their position within the company, and their professional experience. Feedback was then submitted using an evaluation form. All experts rated the capability map on a scale of 1 to 4 based on the five criteria of completeness, comprehensibility, simplicity, applicability, and level of detail. A rating of 1 is the worst rating (e.g., “very incomplete,” “very incomprehensible”). Ratings 2 and 3 are average ratings, each with a tendency toward the worse or better side (e.g., “rather incomplete” or “rather complete”). The rating 4 is therefore the best rating (e.g., “very complete,” “very understandable”). In addition, an overall rating was used to assess the suitability of the capability map for the further development of engineering with a yes or no. At the end, a free text field was used to provide additional comments, remarks, and suggestions for improvement for the revision of the Capability Map. The average ratings for the specified criteria are at least 3.0 and are distributed in Figure 4.
Average evaluation results for the defined criteria
In addition, 90% of participants rated the engineering reference capability map as an overall suitable tool for further development of engineering. Therefore, the verification results show that the capability map is useful, complete, understandable, simple, applicable, and has the right level of abstraction.
4.7. Design process documentation
The changes to the initial design stem primarily from the comments provided in the free text field of the feedback form. The adjustments can be divided into three categories: 1. Content changes, 2. Structural changes, and 3. Additions. In terms of content changes, the capability profiles have been revised. Examples of additions include references to standards such as ISO/SAE21434 in the (cyber)security capability, additions of missing links, the addition of KPIs such as MTBF (Mean Time Between Failure), and the spelling out of abbreviations such as RAM (Reliability, Availability, Maintainability). As part of the structural changes, the capability Hazard & Vulnerability Analysis was removed, as it overlapped with other capabilities. In addition, Requirements Management was renamed in Requirements Engineering, and Production in Manufacturing Engineering. Furthermore, the (sub-) capabilities of Engineering Quality Assurance and Engineering Risk Management were reclassified from Lifecycle Management to Supporting Capability. To ensure the completeness of the capability map, capabilities relating to System Operation and Maintenance, Circularity Engineering, collaboration with external development partners, Technical Product Management, and Strategic Product Management were added.
5. Conclusion and outlook
The scientific contribution of this research consists of the systematic derivation of an engineering reference capability map in the style of the periodic table. The map is structured in four hierarchical levels from capability categories to sub-capabilities. At the level of capability categories, the capabilities are divided into technical core-, lifecycle management-, cross-cutting-, supporting-, and enabling capabilities. In total, the capability map consists of five level 1, 17 level 2, 46 level 3, and 137 level 4 elements. Described in a profile containing various characteristics, a uniform and comprehensive understanding of all capabilities and their dependencies is achieved. Industrial acceptances were ensured and confirmed using an expert survey. As part of a comprehensive engineering transformation, the capability map serves to provide an overview of the scope and possibilities of the engineering domain. Further research is needed to integrate and utilize the capability map in the engineering transformation process. It can be particularly helpful in generating company-specific target pictures of what future engineering will look like, identifying gaps, potential, and development needs, and unlocking them. Since the scope and depth of engineering varies from company to company, the necessary capabilities also vary. To consider this, an assessment method must be developed, that identifies the needs of the company, translates them into necessary capabilities, and thus creates company-specific capability maps. To implement this, the assessment results must be compared with the capability profiles and evaluated. Finally, the resulting capabilities must be prioritized in terms of their relevance to create a transformation target picture and/or roadmap. A capability heat map seems promising for this purpose, as it can be used to identify existing capabilities and those that still need to be developed.
Open access
