Established structures are hindering digitalization in mechanical engineering

Abstract

The article examines the current state of the system landscape in the R&D sector of mechanical engineering and makes it clear that without a fundamental overhaul of the methods, processes, and tools that have evolved over decades, the vision of Industry 4.0 will be difficult to achieve.

First, the typical characteristics of an organically evolved system landscape are described. Next, the advantages of modern paradigms—such as modular design and systems engineering—in conjunction with digitalization are outlined, along with the risks associated with inaction.

Finally, the paper outlines a method for consistently transforming even legacy system landscapes into highly efficient, state-of-the-art development platforms through a structured approach.

Introduction

The vision of a fully connected, end-to-end engineering ecosystem, also known as Engineering 4.0¹See Eigner, M. (2021), p. 29, comes up against the harsh reality of the system landscapes of established companies that have evolved over decades—characterized by unstructured data, inflexible corporate bill of materials, siloed thinking, and a reuse strategy based on the “clone-and-own” principle.

In the past, attempts to structure engineering data in an interdisciplinary manner right from the outset have failed. Reasons for this include, among other things, unsuitable approaches and technical constraints. Today, companies are reluctant to overhaul fundamental engineering structures again because they fear that it will be too costly and lead to failure. Furthermore, the potential of consistently applied functional and physical structures—in terms of internal processes, downstream processes, and future digital products—is underestimated.

With the right approach and an effective structuring strategy, the need for coordination can be significantly reduced. A clear, transparent overall concept can help achieve a high level of acceptance within the development team. By implementing the new structures into existing, adapted, or new systems, the changed way of working is embedded within the company. Future AI systems can then operate on unambiguous data structures, opening up new avenues for product optimization or future digital products and services.

In the next section, we will first examine some characteristics of today's system landscape.

The section then outlines the advantages enjoyed by companies that start out by directly adopting modern paradigms such as a true modular strategy and systems engineering.

Finally, the paper outlines a method for consistently transforming the existing, ad-hoc system landscape into a highly efficient development platform through a structured approach.

Engineering Today

Degrees of maturity

If we symbolically divide the system landscape into version stages, we can view the introduction of CAD as Engineering 2.0. Automated workflows and data integration, driven by the introduction of PLM systems, can be classified as Version 3.0, while the use of digital twins and AI agents is part of Engineering 4.0.

The version levels can also be interpreted as maturity levels, whereby the next level can only be reached after the previous one has been completed.

While today's discussion often revolves around the introduction of Engineering 4.0, we should examine the current state of mechanical and plant engineering so that resources can be optimally allocated toward the further development of engineering.

If a company exhibits at least some of the characteristics listed below, the term "Engineering 2.5" would be plausible.

Unstructured data

Examples of unstructured data include the contents of Office or PDF documents, which are often part of the engineering workflow—for example, in the form of requirement lists, specifications, or functional descriptions that contain screenshots of CAD models, fluid diagrams, or circuit diagrams. These documents rarely adhere to strict system boundaries or hierarchical structures.

In many cases, structured data is already available locally because engineering systems manage projects using data models. The goal here is to establish consistent terminology across all disciplines and to use identical content. These attempts have repeatedly failed because inappropriate approaches or technical limitations block standardization.

Inappropriate Approaches: For a long time, the R&D sector has sought to define mechatronic modules that consolidate all engineering data, such as CAD data, bills of materials, circuit diagrams, control software, etc. This process involves transferring experience from the physical world to the digital world. To optimize reusability, the goal is to „store“ all elements of the mechatronic component in one place—or in a digital repository. In the physical world, this is practical and understandable. In the digital world, however, this approach leads to unnecessary restrictions because the division into „boxes“ assumes that there is only a single way to break down the component across all disciplines.²See Weinberger, 2007. However, multidisciplinary product data must be broken down according to different criteria because different users have different requirements for views or system cross-sections. Consistency is maintained through referencing and not through collocation. The fundamental internal structures here are

• the physical product structure³A product structure refers to the hierarchical breakdown of a product into a tree structure (Svensson and Malmqvist (2000), p. 2). as well as
• the functional structure⁴See Gericke et al. (2021), pp. 241–251..

The latter receives little attention today in mechanical engineering outside the field of electrical design.

Technical restrictions: Ideally, MCAD should follow⁵Mechanical Computer-Aided Design-Assemblies and BOM structure of the product structure defined by the R&D department. However, when using a corporate BOM, the R&D department is required to repeatedly adapt the BOM structure based on production requirements. This results in blurred system boundaries due to discrepancies between the CAD assembly and the bill of materials for the corresponding material. This fundamental problem is discussed in greater detail below.

Group Bill of Materials

In the Bill of Materials (BOM) section⁶Bill of Materials) The concept of a corporate bill of materials (BOM) has become established in many companies. The BOM is created and managed by the development department. Production creates the work plans based on the BOM structure. The distribution of components across the hierarchical levels of the bill of materials poses a significant constraint on assembly planning, as this planning is performed separately for each material—that is, at a single BOM level at a time. If lower-level components—such as covers for subassemblies—are to be assembled only at the end of the main assembly line, these parts must be moved to the top level of the bill of materials (unless error-prone workarounds are used). These BOM changes are carried out by the development department as an internal service for production. While the corporate BOM enforces data consistency between development and production, it results in fragmented BOMs that no longer correspond to the assembly structure in CAD. This not only complicates end-to-end modularization and modular-based reuse but also hinders the generation of BOMs from the CAD system, since the target structure of the BOM differs from the assembly structure in the CAD system. In addition, when production takes place simultaneously across multiple plants, restrictions arise regarding plant-specific assembly processes and the timing of implementing changes.

Configuration Silos

Due to the increase in product variants, the departments were already required many years ago to introduce configuration technologies in order to automatically filter and extract discipline-specific data—such as bills of materials, work plans, control parameters, or circuit diagrams—into the correct variant on a job-specific basis.

In the configuration environment, distinct data silos have often emerged, partly as a result of in-house developments. Because overarching framework concepts are lacking, the configuration of the various systems is predominantly decentralized. High-level sales configuration is then frequently used as the lowest common denominator, from which the valued characteristics are extracted for further processing in specialized configurators within the individual business units. Because a component with many variants is usually represented in different systems simultaneously, this approach results in redundant configuration rules. The consequences are increased administrative burden and a higher risk of errors due to inconsistencies. In addition, decentralized configurators are often highly complex, which leads to increased administrative burden and a reliance on specific individuals.

Carry-over + clone-and-own

Instead of building a true modular strategy based on reusable modules and product families, the combination of carry-over, technology standardization, and a common-part strategy is sometimes regarded as a „modular strategy.“.

In a carry-over, a new machine project is set up based on an existing machine. Most of the assemblies are carried over, while a smaller portion is adapted or newly developed. In principle, this approach also allows for the use of assemblies across different machines. However, without corresponding overarching product family or platform development, this form of standardization is difficult to sustain.

If new requirements for the shared assembly arise from the machine project, there is increased pressure to adapt the assembly to the specific machine. In this case, a copy is created (new material, new document number), and the adaptation is performed independently of the original assembly. Alternatively, a variant is created using configuration parameters, but this variant then does not undergo cross-system variant optimization. This leads to uncontrolled variants that increase complexity throughout the entire company. To prevent this, a true modular strategy is required that distinguishes between module development on the one hand and platform or product family development on the other.

Competitive pressure from younger companies

The threat posed by new competitors can increase significantly if they start from scratch and employ modern paradigms, methods, and tools right from the start. As a result, data is already available in a structured format, and digitization projects can be implemented much more effectively using this data (see Figure 1).

From an engineering perspective, the approach of using AI to bring structure to unstructured data seems largely ineffective and stems from the hope that tools, processes, structures, and work methods can remain unchanged.

However, improving the development methodology alone already accounts for a significant portion of the efficiency gains. For example, the way requirements are currently gathered and broken down to specify subsystems appears to lack structure. If we want to avoid over-engineering, this is exactly where we need to start.

Figure 1: Greyfield vs. Greenfield

In a state-of-the-art engineering environment, data does not need to undergo time-consuming processing before it can be analyzed. It is classified or semantically described using standardized data models as soon as it is generated.

With a clear product and functional structure, consistent, cross-platform modules, and the separation and synchronization of eBOMs⁷Engineering Bill of Materials and mBOM⁸Manufacturing Bill of Materials, configurators with minimal redundancy, clear requirements, system models with code generation, and other automated processes make it possible to achieve a significantly shorter time to market.

The basic effects can be represented in simplified form as a cause-and-effect diagram (see Figure 2).

By feeding field data back into the development process, we can achieve faster improvements and continuous product development.

At the same time, a consistently implemented modular strategy enables the realization of economies of scale and, as a result, more cost-effective products.

Innovative, high-quality, and yet affordable products with short delivery times collectively offer significant potential for gaining market share.

A consistently implemented digitalization strategy also opens up opportunities to automatically make structured engineering data available for downstream processes. This allows scalable Digital products are creating new revenue opportunities. The revenue generated from these, in turn, creates additional flexibility regarding hardware or physical products—for example, by setting lower contribution margins. As a result, established companies that are not yet taking full advantage of the opportunities offered by digitalization may come under even greater pressure.

All in all, this results in two key positive feedback loops—that is, causal relationships that reinforce themselves:

First, economies of scale, i.e.,. faster, cheaper and second, the systematic use of field data to improve products, that is,. faster, better.

The key strategic point, therefore, is this: Anyone who limits their activities to minimal, incremental improvements in engineering runs the risk of losing their strategic advantage.

Figure 2: Effects of Engineering 4.0

In addition, a modern engineering platform, with its structured data, offers significantly better opportunities in the medium term for AI-based agents, which will lead to even greater efficiency and a shorter time to market. Apart from that, a modern engineering platform can have a positive impact on talent acquisition, particularly in the fields of IT, AI, and control engineering.

Conclusion and Solution

Anyone who wants to continue to successfully develop, produce, and operate machinery and equipment in Germany in the future must consistently modernize the engineering landscape and the routines it entails.

MetaCre8 GmbH has developed a four-level framework for modernization (see Figure 3).

Figure 3: A 4-Level Model for Modernizing Engineering

Level 4: Vision

The first step is to assess the current situation. This can be determined methodically and objectively through checklists, random samples, and interviews with experts, based on the development process currently in place.

This will be followed by the development of a vision for engineering, which should be communicated by the Executive Board in light of the upcoming changes in work processes and the cross-functional impact. A systematic goal-tracking process should also be established to transparently monitor implementation and to take appropriate action at an early stage in the event of deviations.

Level 3: Planning

Planning should take place on a regular basis and be integrated into fiscal year planning and forecasts. To ensure the best possible alignment between ongoing product development and the transformation of engineering, regular reconciliation of both roadmaps is necessary. This is where decisions are made, for example, regarding which adapted or new structures, systems, roles, or processes will be used in specific machine projects, so that the teams and managers involved in the department can be prepared in a timely manner and actively engaged. The commitment of managers is crucial, as they must allocate the necessary resources from their departments for the design and implementation of the engineering transformation and actively address any potential resistance. Incentives are particularly crucial in business units to balance out managers’ existing, product-related goals.

Process ownership is also an important way to help managers identify with the new engineering processes.

Level 2: Team, Organization, Management

A matrix structure should be used for program organization. Employees from the line organizations as well as from central functions contribute to engineering transformation projects on a part-time basis. In some cases, full-time participation may also be required.

At its core, the team consists of individuals from the R&D, IT, and CAD/PLM support departments. These departments are most affected by the changes. Depending on the topic, other functional areas may be brought in. Agile is a suitable methodology for project and program management because it ensures a high degree of adaptability and responsiveness in the context of this complex, novel development—with all its interdependencies and relatively frequent adjustments to timelines and content.

Level 1: Tools and Implementation Steps

A framework should be used as the central tool. Using the method MetaCre8^® ED – Engineering Design Companies can benefit from an effective tool. The underlying framework is clearly structured, easy to understand, and can be put into operational use in no time. It supports the development of a shared mental model, which results in significantly more efficient discussions within cross-functional teams. A shared understanding of complex engineering processes also leads to better overall solutions, and projects can be more easily executed in parallel, which increases the speed of implementation. The framework allows both current and target processes to be clearly visualized. It serves as an effective tool for communication and design.

Demonstration scenarios based on real-world case studies are crucial. Not only do they illustrate critical pain points and serve to validate the systems, but they are also extremely useful for communicating the results throughout the company.

As is customary in the product development environment, the engineering design process should also allow for rapid feedback and the acquisition of experience. Therefore, appropriate test environments must be provided. Through proof-of-concept, optional benchmarks, pilot projects, and rollout, the implementation of each individual project within the engineering program is prepared and executed with minimal risk. Policy and process portals, internal training, and a continuous improvement process support the integration and acceptance of the new methods, processes, and tools.

Conclusion

The digital transformation of established engineering environments is challenging and requires sufficient resources, even in areas that are already operating at full capacity today. This makes it all the more important to deploy limited resources in a targeted and effective manner. To achieve this, a structured approach using a framework such as the MetaCre8^® ED – Engineering Design obvious. The commitment of top management, the involvement of managers, and the active participation of subject-matter experts are another key factor for success.

The 4-level model presented here can significantly reduce the time and effort required for the transformation.

It remains to be seen which industries will gain importance in the future. Efficient mechanical and plant engineering is certainly an essential prerequisite for the rapid scale-up of new industries. A significantly higher pace of engineering work than in the past will help attract new industries to Germany and Europe and retain them in the long term.

Sources

Eigner, M. (2021). „Engineering 4.0 – Fundamentals of Engineering Digitalization,“ in Eigner, M. System Lifecycle Management: Digitalization of Engineering. Berlin, Heidelberg: Springer-Verlag.

Svensson, D. and Malmqvist, J. (2000) „Strategies for Product Structure Management in Manufacturing Firms,“ in Proceedings of the 2000 ASME Design Engineering Technical Conferences (DETC2000), Baltimore, Maryland, USA, September 10–14, 2000.

Gericke, K., Bender, B., Pahl, G., Beitz, W., Feldhusen, J., and Grote, K.-H. (2021). „Functions and Their Structures,“ in Bender, B. and Gericke, K. (eds.) Pahl/Beitz, Design Theory: Methods and Applications for Successful Product Development. 9th ed. Berlin, Heidelberg: Springer Vieweg, pp. 241–251.

Weinberger, D. (2007). Everything Is Miscellaneous: The Power of the New Digital Disorder. New York: Times Books.

Citation Format

To cite this article, please use the following citation:

Karlberger, A. (2026): „Established Structures Are Hindering Digitalization in Mechanical Engineering.“ In: MetaCre8 GmbH Expert Blog. Published on September 9, 2026. Current version: 1.0. URL: https://metacre8.com/greyfield-blockiert-digitalisierung-im-maschinenbau (Accessed on: [DD.MM.YYYY]).

Version History & Changelog