From metal bender to software provider: When machine manufacturers discover digital business models

When existing business models are no longer effective

I recently sat with the managing director of a medium-sized machine tool manufacturer. 450 employees, 35 years of experience, excellent metalworking equipment. The company has made a name for itself over decades - solid mechanics, proper control technology, reliable production, timely delivery.

“Our major customer now wants the machine to come with an asset administration shell and integrate with its Siemens Industrial Edge platform,” he told me. “Feature enablement via software license, digital twin for predictive maintenance, the full program.” He paused and looked at me. “We can do excellent mechanics and control technology. But software-as-a-service? That's where we're at the beginning. And to be honest, I don't even know how we make money with it or how we incorporate it into our billing system, not even starting from sales.”

A situation I've experienced more often. Mechanical engineering is undergoing a fundamental transformation. Hardware alone is no longer enough. Customers expect the latest technology, such as digital twins, seamless integration into their automation platforms, and software services that accompany the life cycle of the machine. Standards such as the Asset Administration Shell make these requirements mandatory, not optional.

But many medium-sized mechanical engineering companies in particular are struggling. Not because they lack technical expertise, but because software transformation is much more than just an IT issue. It's about new business models, changed organizations and sales, and a completely different way of thinking.

In this article, I'll show you

• What value creation potential is available for you
• Where the real challenges lie in implementation and
• How you can proceed pragmatically and evolutionarily.

1. The new added value: Software becomes the core of the product

It used to be clear. A machine manufacturer sold a machine. Offer, service agreement, customer investment, payment, delivery, installation, point. The controller was integrated, the software focused on the machine itself and interfaces went via fieldbuses and Industrial Ethernet, but the software was not a standalone product.

That has fundamentally changed. Hardware is now a kind of ticket, a transporter of services and the actual added value is shifting to the software or service level.

A specific example from my consulting practice: A plant manufacturer for packaging machines had previously implemented features such as additional format changes or extended control functions through hardware upgrades. That meant: technicians on site, conversion time, mechanical parts and... time. Today, it unlocks the same functions via a software license. The hardware is prepared from the start, and the customer activates features as required and ordered. The result: faster time-to-value for the customer, recurring sales for the manufacturer.

The implementation of such models now works mostly via industrial platforms from major players such as Siemens, ABB, Mitsubishi or Schneider Electric, but large medium-sized companies such as Weidmüller or Hilscher have also established their own platforms for data-controlled machine installation, control and monitoring.

But standards are needed for such models to work interoperably. The Asset Administration Shell (AAS) and the digital twin (digital twin) are important to you here.

• AAS is the standardized digital representation of an asset — in this case, your machine. It was developed by the Industrial Digital Twin Association and has been enshrined in the international standard IEC 63278-1 since December 2023. The IDTA, founded in 2020 by VDMA, ZVEI, Bitkom and over 110 industrial companies, specifies how machines must be described digitally. The AAS works via so-called sub-models. Each sub-model describes a specific aspect of your asset: the digital type plate, maintenance information, the CO2 footprint, technical data, or the interfaces for communication.vantage: These sub-models are standardized so that your machine can talk to other systems — across manufacturers. No longer a proprietary format, but open interoperability.
• The digital twin goes one step further. While the AAS provides the structure, the digital twin is the living digital image of your machine. It collects real-time data, simulates behavior (e.g. throughput times, speed, removal and other relevant parameters), enables predictive maintenance and is used to optimize production processes.advantage: The unique engineering model becomes a permanent companion throughout the entire life cycle of a plant and thus real added value for your customer.

2. The reality of integration: Welcome to the ecosystem jungle

It's getting complicated now. Because your machine is not alone in the world. It must integrate with existing automation platforms. And this is where the game for market shares, market power and standards begins.

Let's take Siemens as an example. With Industrial Edge and MindSphere, Siemens offers a comprehensive platform for edge computing and cloud services. Your machine should send data to edge devices, where analyses are carried out and results transferred to the cloud. Sounds good for now. But: Who defines the interfaces? Who controls access to data? And what happens when your customer works with Rockwell, ABB, or Schneider Electric?

Each of these platforms has its own ecosystems, its own rules of the game.

• Communication topic: OPC UA may be an important cross-platform standard for communication, but the implementation is different. MQTT for IoT communication, REST APIs for web services, and the interface and protocol landscape is diverse.
• Topic data storage: Cloud or Edge? For data protection reasons, some customers want to keep everything on-premise in their own data centers, others rely on virtual private cloud systems.

A machine tool manufacturer told me about his experience: “It took us four months to connect our machine to the Siemens platform. That's when the next customer came and wanted Rockwell. Another three months. We've noticed that we need an abstraction layer that makes us somewhat independent of individual platforms and helps us migrate more easily or at least faster.”

The Asset Administration Shell, among others, helps here. It acts as a standardized interface between your machine and the various platforms. Once implemented cleanly, different systems can access the same data without you having to redevelop for each platform.

But with the data economy, the issue of cybersecurity also comes into play. The EU Cyber Resilience Act (CRA) has been passed. Since 2024, there have been stricter IT security requirements for connected products. Software updates must be rolled out securely, vulnerabilities documented, risks minimized. Compliance is becoming a permanent construction site. CRA will then come into force from 2027. Anyone who does not yet have processes for product security and supply chains must now set them up quickly.

The good news: The CRA is not only another standard, but also a great opportunity to set up your product portfolio for the future. You can find out more about this in this article.

3. The business model dilemma: What is software worth?

Now we're getting to the heart of the matter. Let's say you have the technology under control. Your machine has an AAS, integrates into platforms, and the digital twin runs. The key question is: What are you asking for in return? In the end, you invested in infrastructure and IT systems, trained employees, hired new employees with the necessary expertise (if they found any).

This is where I experience the biggest uncertainties. A classic machine manufacturer is used to calculating a price for the hardware. Materials, manufacturing, margin, product income statement, all right. But software? “We did the development anyway,” many say. “How do we price this transparently and comprehensibly without scaring customers?”

It's a mistake in thinking. Software development, maintenance, updates, support, it all costs money. And permanently. If you don't price these costs into your business model, you're giving away added value. Or worse: You're subsidizing your competition, which is doing better.

There are various pricing models that work in practice.

• Subscription models, where the customer pays monthly or yearly for software features.
• pay-per-use, where usage is measured and billed, particularly interesting for rarely used special functions.
• Features-on-demand, where the customer unlocks features as needed, similar to buying a car with options and
• Support and maintenance services.

An example: A manufacturer of laser cutting systems today offers three software packages. The basic package is included in the machine price. The professional package with advanced cutting strategies and material optimization costs 3,000 euros per year. The expert package with AI-supported process optimization and predictive maintenance 8,000 euros per year. The highlight: The hardware is identical, the customer pays for the added value they actually use.

But the biggest hurdle is often the expectation of customers not to pay for software traditionally or at least not continuously when they want to buy a machine. Only one thing helps here: making the value transparent.

• Show what added value the software actually creates for your customer. Shorter set-up times, less waste, higher availability, lower maintenance costs.
• Precalculate the ROI Make software a visible value proposition, not an invisible appendage of hardware.
• And keep in mind that it can be attractive for the customer's finance side to rent machines and pay for their output depending on usage — this turns fixed costs into variable costs in relation to the customer's value-added asset.

4. Organization and Skills: When Two Worlds Collide

Technology and business model are one thing. But who implements it? This is where the actual transformation takes place. Hardware engineers and software developers work differently. Very different.

A hardware developer thinks in terms of product cycles of years. A product is specified down to the last detail, simulated, tested, certified, and then built. Changes are expensive and undesirable, and our German perfection, which has also made our mechanical engineering a world leader, plays a role here, of course. A software developer thinks in terms of iterations of weeks (or sprints of 14 days). Continuous integration, continuous deployment, quick updates, beta versions, that's his world.

In a workshop with a machine manufacturer, this became drastically visible. Hardware development proudly presented its 18-month development plan for the new generation of machines. The newly hired software lead asked: “And when do we make the first release?” Irritated looks. “After 18 months when the machine is finished.” The software lead: “You haven't made a single interim delivery for 18 months? How do you want to get customer feedback?”

Welcome to culture shock. DevOps in mechanical engineering means developing software while the hardware is still running. Roll out over-the-air updates without the need for a technician to be on site. Agile sprints parallel to classic milestones. This requires new processes, new tools and, above all, new ways of thinking and working.

Product management is also changing. You used to define features: “The machine must be able to do X, Y, and Z.” Today, you need to understand use cases: “What problem does the customer solve and how does our software help?” This requires more customer proximity, more market research, more willingness to experiment and customer involvement with MVPs.

It's getting even more exciting in sales. Instead of a one-time project deal, you are now selling subscriptions. That means:

• Customer success instead of final commission.
• Negotiate service level agreements instead of a sales contract.
• Long-term customer relationships instead of one-off deals.
• Upselling and cross-selling software packages.

Your sales team must adapt and learn to think in a new way.

And then support. Previous: “If you have any problems, call our technician, he will be there in three days.” Today: “Software update will be rolled out in 10 minutes, problem solved.” This requires 24/7 hotlines, remote access, structured ticketing. Many SMEs are not (yet) prepared for this.

5. The realistic path: evolution instead of revolution

After all these challenges, the good news is that you don't have to do everything at once. The key lies in a pragmatic approach.

• Start with quick wins and small steps. Where can software features immediately add value without turning your entire business model upside down? A manufacturer of bottling plants, for example, has started with a remote monitoring dashboard. Customers were able to see plant performance in real time and faults were reported automatically. Development costs: manageable. Benefits for customers: immediately noticeable. And the manufacturer learned how software deployment works.
• Collaborate with lead customers. Find three to five customers who are open to new digital services and ready to experiment together. Co-creation instead of laboratory development. They develop features that solve real problems and receive direct feedback. These pilot projects are worth their weight in gold — not only technically, but also for your internal learning curve.
• Decide strategically about Make-or-Buy. Do you have to develop everything yourself? Often not. There are specialized software partners who offer platforms for asset administration shells, that provide edge computing solutions, or that deliver digital twins as a service. Focus on your core competency — these are probably machine-specific algorithms and use cases. Others can do the infrastructure better.
• A medium-sized special-purpose machine manufacturer has cleverly solved this problem. He has signed a partnership with a software company. The software house provides the aaS infrastructure, the monitoring dashboard and the cloud connection. The machine manufacturer focuses on machine-specific features: process optimization, parameterization, diagnostic algorithms. They both benefit.
• Build governance. Who decides which software features are developed? Who releases releases? Who takes care of pricing? You need a product board that brings together development, sales, service and management. Agile methods such as OKRs help set priorities and measure progress.

And above all: Start small but think scalable (start small — scale big). Your first software feature may be simple. But the architecture behind it should be able to grow. Invest in clean APIs, modular structures, and standards-compliant interfaces right from the start. Otherwise, you will build up technical debts, which you will pay dearly later on.

Conclusion: This is how the transition to software-based business models is successful

Software transformation in mechanical engineering is not an IT issue, but a strategic realignment of the entire company. Standards such as the Asset Administration Shell make digital integration mandatory. Automation platforms are defining new rules of the game. Customers expect software services as an integral part of the machine.

Whoever acts now secures competitive advantages. Anyone who thinks, sells and develops software as an independent product opens up new sources of revenue. Those who take organizational challenges seriously and approach them pragmatically build up sustainable expertise.

The alternative? To become a pure hardware supplier in a software-dominated ecosystem. Replaceable, with falling margins, without access to customers. No one wants that.

Mechanical engineering has all the prerequisites for this transformation. Deep technical understanding, close customer relationships, innovative strength. It is now a matter of translating these strengths into the digital world. With speed and structure, as I call it. Experiment boldly, but proceed systematically. Discover new territory, but with a clear compass.

Start the dialog

How is your company dealing with software monetization? Have you already implemented Asset Administration shell submodels or introduced feature enablement? What challenges do you experience in everyday life, from a technical, organizational or business model?

I am looking forward to sharing your experiences. As a sparring partner on equal footing, I support medium-sized companies in precisely these transformations. Let's talk — about your specific situation, your next steps, and how you can turn software from a cost factor into a growth driver.

‍

Sources

• Industrial Digital Twin Association (IDTA) (2023): Asset Administration Shell Specification Version 3.0, [online] https://industrialdigitaltwin.org [retrieved on 05.11.2025]
• International Electrotechnical Commission (2023): IEC 63278-1 Asset Administration Shell for Industrial Applications - Part 1: Asset Administration Shell Structure
• Industry 4.0 platform (2023): 2023 progress report. Industry 4.0: On the way to an intelligently connected industry, [online] https://www.plattform-i40.de [retrieved on 05.11.2025]
• Siemens AG (2024): Industrial Edge — Edge Computing for Industry, [online] https://www.siemens.com/de/de/produkte/automatisierung/themenfelder/digital-enterprise/digitaler-zwilling.html [retrieved on 05.11.2025]