In the past six weeks, we conducted 20 interviews with industrial companies to understand why so many struggle with automation in engineering and industrial engineering. We wanted to learn where they stand on AI adoption and what obstacles they face when trying to automate. And to be transparent: our motives weren’t purely altruistic. We wanted to understand what requirements our platform must meet so we can develop it in a focused, purposeful way.

The interview results surprised us. To help you decide whether it’s worth reading on, here’s a brief overview of the key insights:

1. PLM doesn’t deliver full automation — even though many hope it will.
   
   Only 4 out of 20 companies use PLM comprehensively. Even those still face substantial manual effort in their customer-specific product business. PLM can be an important foundation, but it is not an end-to-end automation engine.

   
   

2. AI has already entered engineering — but mostly in copy-paste mode.
   
   Employees regularly use LLMs (often via private accounts). Daily. But it’s not integrated, not secured, and not governance-ready. There is a wide gap between strategic AI ambitions and operational reality.

   
   

3. Some automation features exist — but aren’t used.
   
   In theory, they exist in major engineering suites. In practice, many teams find them not user-friendly enough, too limited for real automation, or too hard to adopt.

   
   

4. Generic workflow automation platforms quickly hit limits in engineering.
   
   A lack of engineering-specific capabilities, combined with high security and governance requirements, is why generic workflow automation tools (like n8n) rarely gain traction.

   
   

5. Automation in mechanical engineering is not an IT project.
   
   All interview partners agreed: If engineering and industrial engineering don’t automate their own work, progress will be slow. IT often lacks the domain knowledge and bandwidth.

1. Are the insights transferable to you?

To help you assess whether these insights apply to your company, here’s who we spoke with: the companies had annual revenues between €50 million and €3 billion and mainly came from mechanical and plant engineering as well as industrial component and system manufacturing. They shared high technical complexity, strong variant diversity, customer-specific requirements, and a high share of engineering work. The range included large battery storage systems, filling and packaging plants, industrial mixers, customer-specific high-performance metal parts, bespoke enclosure systems, as well as window and fitting solutions, excavators, sensor-based sorting and transport solutions, and precision tools. Our conversation partners were CTOs, Heads of Engineering, COOs, Heads of Industrial Engineering, and Digitalization Managers.

 II. Variants still often emerge case by case instead of through automated processes — engineers spend less than 50% on value-adding work.

We initially wanted to understand the operational challenges — independent of AI and related topics. Technology is only a means to an end. What matters is that engineers can focus again on designing new products and planning production — and therefore on innovation — instead of spending large parts of their day on administrative work.

And when it comes to administrative work, the feedback was unanimous: engineers spend far too much time extracting information from drawings and text documents, moving data from one system to another, and running consistency checks across multiple tools. Many interview partners estimated that well under 50% of engineering time goes into actual value creation — the rest is searching, transferring, and checking.

The following manual activities were mentioned most frequently in engineering:

• Reducing part numbers:

  In many companies, the full parts portfolio isn’t maintained in PLM with clean, consistent nomenclature. As a result, teams cannot increase reuse through PLM capabilities alone. Standard-part catalogs may exist, but they aren’t followed consistently. The consequence: people manually search inventories to identify similar parts and increase the share of identical parts. It’s labor-intensive and not sustainable.

  
  

• Finding similar parts:

  Designers often don’t know that a customer requirement has already been implemented before. Then either an experienced colleague is asked and the search begins — or a new item number is created and a new part is designed under time pressure.

  
  

• Reading standards and company guidelines:

  Many companies serve different markets with different standards. Others have specific design guidelines (e.g., welding specifications) or plant-specific manufacturing guidelines to ensure manufacturability. These are typically extensive PDFs stored somewhere on SharePoint.

  
  

• Reviewing drawings:

  2D drawings still play a crucial role. Suppliers often manufacture strictly (more or less) according to drawings. Since many parts used to be produced in-house, drawing quality varies widely. Designers therefore spend significant time ensuring drawings are complete, correct, and unambiguous.

  
  

• Configuration rules in Excel:

  Variant configurations are still often built in (sometimes very fragile) “Excel monsters.” Results then have to be transferred manually into other IT systems. Interestingly, even companies using CPQ reported that end-to-end configuration of design and manufacturing documents often didn’t succeed there either.

  
  

• Human interfaces:

  The biggest pain is manually extracting and transferring data from one IT system, Excel calculation file, or simulation tool to the next.

In industrial engineering, most struggle with the following manual activities:

• Finding reference parts:

  Very few parts are truly new. Usually, similar parts have been produced before. But finding those references in ERP or other systems is often extremely time-consuming.

  
  

• Checking design documents for completeness:

  Sometimes planning fails because manufacturing tolerances are missing from the design. In other cases, individual specs (or material choices) trigger significant changes on the shop floor. This leads to repeated (often phone-based) coordination between industrial engineering/work preparation and design.

  
  

• Selecting tools:

  Finding the right tool for a machining step often means opening the tool database (or SharePoint), the tool datasheet (or manufacturer catalog), and manually comparing requirements from the machining operation (e.g., turning tolerances) with tool characteristics.

  
  

• Finding the appropriate machine:

  Machine selection follows the same pattern — often made worse by incorrect master data in ERP. Planners then go to the shop floor to clarify requirements with colleagues on-site. This creates effort and consumes lead time.

  
  

• Creating routings and determining machining times:

  In the end, almost everything flows into routings. Typically, a reference routing is copied and individual operations are adjusted. This is time-consuming and often causes planning errors in the heat of the moment — triggering questions, rework, or costly shop-floor adjustments. Few companies feed actual machining times (from MES) back into planning.

  
  

• Determining assembly sequence:

  Assembly planning looks similar: assembly precedence graphs are created manually (experience-based), MBOMs are not automatically derived from EBOMs, and assembly sequences as well as workstation allocation are planned manually in Excel.

  
  

• Calculating production costs:

  Offer costing is often done in huge Excel spreadsheets. They need data inputs — and those rarely flow automatically from ERP or other systems into the calculation templates.

As you can see, these are very tangible challenges. This is not about “fancy AI visions,” like agents autonomously creating 3D models from natural language. I don’t mean to suggest AI won’t be able to solve such advanced challenges. But I believe most companies would already benefit enormously from a robust, secure solution for the topics listed above. Brief spoiler: I’m optimistic we’ll get there.

III. What does this mean for you as CEO, CTO, COO, or Head of Engineering/Industrial Engineering? For example, at least 40 percent wasted lead time. And thus revenue. And costs. And EBIT.

After these discussions, I suspect the average automation level in these companies is below 20%. From my project experience, I know that an automation level of 80% is achievable. What does that mean for lead time if you increase automation by 60 percentage points? In mechanical and plant engineering, pre-production functions typically account for around 70% of the total lead time from customer order to delivery. That implies up to 40% lead-time reduction is possible. Across the industry, excessively long lead times are now one of the biggest challenges for German manufacturers in global competition. Whoever delivers faster can sell more. Whoever has less manual effort per machine sold has lower costs — and ultimately higher EBIT.

Some department heads cautioned that these gains can only be realized if automation is cross-functional — and that few CEOs in the industry currently prioritize an end-to-end variant creation process. After many conversations, including at industry events, I’m convinced this is changing and the topic is increasingly moving onto leadership agendas.

 IV. The underlying causes? Highly fragmented engineering tool landscapes and regulations not operationally anchored

We always knew the technical office looks different from the commercial one. But we were surprised by just how heterogeneous tool landscapes can be: individual companies reported using 150 (!) different software systems, calculation tools, and similar solutions in production planning alone — many from different vendors, few integrated, most operated by highly paid engineers. Considering that CRM, CPQ, PLM, CAx, and MES also play a role in variant creation, the scale of manual work becomes obvious.

Many mechanical engineering companies have invested heavily in modularization, kits, standardization, and configuration over recent years and decades. That’s good — it’s a foundation for AI-enabled automation. But the core problem remains: these rules often live in individual software tools, documents, or Excel files. Very few companies achieve consistent, automated variant derivation across all systems.

 V. Wait. Don’t Product Lifecycle Management systems and suites with complementary modules exist for exactly this? Maybe — but only 4 out of 20 use them comprehensively and are satisfied.

We sometimes heard (mostly from IT): “Problem identified — we’ll introduce PLM over the next few years and integrate PLM with ERP. Then the problem is solved.” Unfortunately, in most cases, that won’t happen. Why?

In theory, the solution should be there: comprehensive data models, end-to-end processes, seamless integration of configuration, design, production planning, and shop floor. At least that’s the promise. Reality looks quite different.

Out of 20 companies, only 4 said they use PLM comprehensively and across departments. The other 16 were in one of these situations:

• Either they had no PLM yet.

• Or they planned to introduce PLM.

• Or they had PLM — but were dissatisfied and effectively used it more as a PDM system.

Let’s look at the four companies using PLM broadly. They essentially structured their portfolio into two categories:

1. Standard products, mostly fully configurable

2. Special products, highly customer-specific, but still containing configurable parts

In the standard business, the achievements were impressive: they could automate from product configuration through BOM and work plan to machine programming on the shop floor. Variants were derived rule-based, documents generated automatically, NC programs created. That’s exactly how people imagine it.

But that’s only half the story. Getting there required enormous effort. In practice, many still experience PLM as engineering-centered. Other systems came from different vendors and had to be integrated through costly, time-consuming custom development projects.

And once you move into special products, a high share of manual work persists — even with strong PLM usage. Why? Because complexity is higher and repetition is lower than in standard products. At that point, custom development quickly hits economic limits.

Key conclusion: even with broad PLM usage, significant automation needs remain. PLM is not a cure-all for end-to-end automation.

And the other 16 companies? Here the full extent of the problem becomes visible. Some reported working on PLM implementation for years (!). Licenses are already paid. The system still isn’t productive. And further months of implementation are expected. Internally, many already believe the system won’t deliver the level of automation they originally hoped for.

Other companies described a different phenomenon: with major PLM upgrades, every release feels like a new implementation project. Why? Because 20–30% of the system is customized. Each new version requires adjustment, testing, and integration. That ties up resources and can paralyze the organization. Some companies currently don’t plan PLM at all and deliberately push the topic into the distant future.

And particularly interesting:

In our sample, no company plans to throw everything out and standardize on a single suite.

Why?

Because over the years, a lot of expertise has been embedded in existing tools. Because specialized software solutions (and startups) often solve individual tasks far better than generic PLM suites. To keep this post from getting even longer, I won’t go deep into the recently debated technical limitations of many PLM systems (keywords: monolithic architectures, tech roots in the ’90s, relational databases holding large amounts of process logic). For that, I recommend the posts I value highly from beyondplm.com.

So what does this mean overall?

PLM can be an important foundation. But PLM alone does not automatically deliver seamless variant automation.

 VI. Are workflow automation platforms like n8n or RPA platforms like UiPath the solution? Not really.

Four companies (interestingly, different from the four advanced PLM users) made first attempts — mostly IT-driven — to automate individual steps using n8n, UiPath, or Power Automate. Results were mixed and overall limited. What did they learn?

1. Interface libraries
   
   The core advantage platforms like n8n often bring in other contexts didn’t translate well to engineering and industrial engineering: out of the box, they lacked domain-specific interfaces and data models for CAx/PLM/simulation solutions.

   
   

2. Templates
   
   Automations had to be modeled manually from scratch. There were no ready-made templates for tasks like similar-part analysis, work plan creation, or production cost calculation.

   
   

3. AI services
   
   Recurring tasks such as identifying similar CAD models were not meaningfully automatable because engineering-specific AI modules — and above all context — were missing (data model, semantics, BOM/CAD references).

   
   

4. Governance
   
   As flexible (and admittedly cool) as these platforms are, the risk of uncontrolled growth is real. If every engineer starts automating locally and there is no layer to turn this into robust, maintainable, controllable processes, variant creation can spiral out of control. In the most critical value-creation process of a machine builder, nobody wants that.

   
   

5. Security
   
   Anyone connecting core IT systems via a platform rightly expects enterprise-grade security.

   
   

6. Hallucination
   
   This topic surfaced only at higher maturity — after teams had built many automations. Many tasks can be automated without deep intelligence. But at higher complexity it becomes clear: without clean context, rules, and security, LLMs start hallucinating — and results become unreliable. One company is therefore exploring a knowledge graph to combine product and process data from multiple sources and provide machine-readable context for LLMs.

Interim conclusion:

Workflow automation is the most promising path — if you can overcome the limitations above.

 VII. What about AI? How is it currently used? Not really — at least not embedded into processes yet.

First of all: I’m not an AI evangelist. My goal isn’t to pick a technology and go hunting for a problem. But we use AI constantly at wailand, and I’ve seen the impact it already has in many domains (just think of software development). I’m convinced AI will fundamentally change engineering and industrial engineering — and you can already see early effects in the day-to-day work of designers and planners. Almost every designer or production planner we spoke to said they already use LLMs. But via private accounts and copy-pasting into chat windows. That can’t be the future (security, IP) — everyone agrees. But it also won’t work without AI. How else should European industry compete with Asian competitors?

What I don’t believe works (and yes, I used to run many of these projects myself):

Months-long strategy programs and ideation workshops, followed by building a few isolated “fancy” AI services. It’s too slow, and honestly, I rarely saw anything truly transformative come out of it.

So what does work?

Of course, you need executive commitment and budget for consistent automation. But you don’t need months or years of consulting-heavy strategy work. In my view, the four companies that started with workflow automation platforms did many things right: start, automate the first steps, learn, experience limitations, and then solve them. I’m confident these companies will be far more successful over the coming years than those embarking on lengthy AI strategy projects now.

VIII. What requirements should I set as CEO, CTO, COO for an automation solution in engineering / industrial engineering?

After all discussions, one question inevitably follows: if PLM and generic workflow automation platforms aren’t enough on their own — what should decision-makers look for? What must a solution deliver so it doesn’t become just another tool in an already overloaded landscape? I would summarize it in six core requirements.

1. UI/UX designed radically from an engineer’s perspective

It sounds trivial, but it isn’t. If engineers don’t want to use a platform, it won’t succeed. Period. Excel shadow solutions will reappear, and manual workarounds will return. An automation solution must be designed so that it:

• intuitively maps engineering logic

• can be automated without programming skills

• delivers quick results

• integrates into daily work instead of adding friction

Engineering is not an IT project. Success requires tools designed for designers and industrial engineers — not for “techies.”

2. AI alone is not enough – deterministic rule sets are mandatory

LLMs and AI agents are powerful — no question. But engineering isn’t only about probabilities. It’s about tolerances, safety requirements, compliance, standards, and manufacturing constraints. That means: in addition to AI, you need clean, deterministic rule sets. AI can support, interpret, and suggest. But robust end-to-end automation comes from combining probabilistic models with hard, deterministic rules.

3. Strong governance instead of uncontrolled growth

Many companies know what happens when automation grows uncoordinated: Excel monsters, local scripts, opaque logic. Anyone serious about automation needs:

• clear approval mechanisms

• roles and permissions

• transparency into dependencies

• traceability of decisions

Without governance, you won’t get a scalable system — only a patchwork.

4. Enterprise-grade security

Automating engineering means accessing the company’s most sensitive knowledge:

• Product architectures

• Calculation logic

• Manufacturing processes

• Machine programs

• customer-specific solutions

These are the crown jewels of every machine builder. Security therefore must be non-negotiable. Access control, encryption, multi-tenancy, audit trails — these are not nice-to-have features; they are prerequisites.

5. Cloud or on-prem? Reality is split.

Some companies still want to operate engineering data and systems exclusively on their own infrastructure. At the same time, a growing group has a clear cloud-first strategy. These companies are willing to move sensitive engineering data to the cloud — if security and compliance are right. A future-proof solution must support both worlds.

6. The knowledge graph as backbone

One key component can be a knowledge graph — because it brings product and process knowledge together so AI and rules can work reliably on top of it. It makes the following connections machine-readable:

• relationships between components

• dependencies between configuration rules

• links between EBOM, MBOM, and work plans

• assignment to machines, tools, and resources

• standards and guidelines in the context of specific product structures

Only when knowledge is structured, semantically linked, and machine-readable can AI fully unfold its potential and automate variant creation end to end.

What we at wailand specifically do – and where we stand

I’m Patrick Kübler, one of the founders of wailand. At 14, I worked as a factory helper during school holidays for the first time — and I’ve been connected to manufacturing ever since.

Our work on these topics is not just theoretical. At the core of our platform is a workflow automation engine designed to meet the requirements described above for engineering and industrial engineering. We have built initial connectors into typical engineering and ERP environments. Core security and governance mechanisms are in place. And as a first service, CAD similarity analysis is already available in production.

We work with customers on real process automation across the variant creation process — step by step. Always with the goal of robust end-to-end automation, not isolated “flagship” use cases. But we’re far from done. That’s why we’re continuously looking for new, challenging customer problems from teams that are serious about automating engineering and industrial engineering.