The argument that maintenance is a value-generating asset rather than a cost line is not new. Maintenance leaders have been making it for years.
The problem is that the data they would need to defend framing maintenance as an asset isn't there in usable form. Notifications are half-filled, time bookings are rounded to the nearest hour, and schedules come from Excel and reconcile to SAP weekly. The idea that maintenance drives value is right, but the data underpinning it is completely lacking or not available at the right time.
The operational answer is closing the gap between reality and your EAM (Enterprise Asset Management) system, and therefore the organization, knows about it.
When technicians, operators, and planners use software that captures what they do and flows it back to the ERP cleanly, the data starts showing what optimized maintenance generates. Powering up SAP (Arkyn is a silver partner for SAP, the world's biggest EAM platform) for the maintenance teams running on it is what makes maintenance's value visible to the business.
The financial case is real, with the right data.
The numbers are not subtle.
Siemens' True Cost of Downtime 2024 report found that the world's 500 largest industrial companies lose roughly $1.4 trillion a year to unplanned downtime, around 11% of revenue.
ABB's Value of Reliability survey found that two-thirds of industrial businesses face unplanned downtime at least monthly, at an average cost of $125,000 an hour.
For producers running close to capacity, every hour of extra uptime is revenue the business would otherwise lose.
Revenue through increased uptime is one dimension of the value maintenance generates, here are two more worth naming.
The first is asset reliability. Equipment that runs reliably lasts longer, breaks less often, and pushes capital replacement decisions years into the future. When the data shows what fails and why, replacement timelines become decisions, not surprises.
The second is technician productivity. When a planner sends a technician in with the right tools and information, they fix the problem on the first visit instead of returning for a second or third. Reactive work shrinks, planned work grows, and overtime and subcrontractor costs come down.
None of these dimensions show up to the business without data that captures them.
A patchy data parable.
A maintenance lead at a European manufacturer we work with recently needed roughly 50 million kroner for a new production line. He could only justify the spend by showing that the existing line was running through enough downtime, repair labor, and reactive work to cost the business more than the replacement would. The decision was being made at headquarters by people who only have data to lean on.
Unfortunately, the data was patchy. Reactive maintenance issues were being captured at the wrong level in the hierarchy (not linking the fault directly to the right asset). Labour hours were incorrect because technicians keyed them in from memory at the end of a shift. And notifications didn't always specify what was actually wrong because information was passed on through pen and paper and scattered emails.
The case was real, but the data didn't tell the story cleanly enough to support it.
Where the data breaks down.
Three failure modes show up across asset-heavy SAP environments regardless of vendor or industry. Each one breaks a different part of the data trail that is needed to make maintenance's value visible.
1. Technician reporting friction.
The first is reporting friction at the technician layer. SAP GUI was not designed for someone in PPE on a factory floor or out servicing assets in the remote countryside.
So technicians do the work, go back to the workshop or log on at the end of a shift, and fill in what they remember or what they can discern from their notes. The resulting gap between reality and reporting in SAP reduces the quality of your operational data:
- Accuracy slips: time rounds to the nearest hour, spare parts get booked incorrectly.
- Context disappears: notes, observations, photos, and technician insights that explain what happened don't make it into the record.
- Failure detail flattens: Secondary damage (aka consequential failure) gets rolled into the primary failure instead of logged separately.
The asset history then looks cleaner than what actually happened on site, and reliability metrics like MTBF drift from operational reality.
Our comparison of mobile SAP work order apps that help with SAP reporting covers what the alternatives look like and where each one fits.
2. Issue notification friction.
The second is notification capture friction at the operator and frontline layer. To raise a notification about a potential asset issue in SAP, you typically need an SAP credential, training, and a desktop.
Operators on the line or in the field typically have none of these. So issues get reported by phone, by paper, or not at all.
The broader pattern is covered in our article on operator-driven reliability.
3. Planning and scheduling friction.
The third is planning friction at the scheduler layer. Most SAP planning ends up happening in Excel and gets reconciled to SAP weekly, sometimes less often.
Teams that did adopt SAP's own scheduler, Multi-Resource Scheduling (MRS), are also facing change: SAP is retiring it by 2027, with Resource Scheduling (RSH) and Field Service Management (FSM) as the successors.
The schedule lags reality by days, capacity views are stale, and half of the planner's day is reconciliation rather than planning.
SAP's value needs to be realized from the frontline.
The three frictions above share one root.
They are not about SAP failing, they are about the gap between SAP's platform investment and the solutions the people doing the work need to make use of it.
- Technicians need a user-friendly mobile interface, not stacks of forms or SAP GUI.
- Operators need a way to digitally and easily report issues without an SAP credential or a desktop.
- Planners need visual scheduling tools that update SAP in real time.
Good software designed for each of these layers is what turns SAP's platform investment into operational value.
Don’t forget adoption.
Recognizing the strategic shift and getting that software deployed is only half the equation.
Getting it used is the other half, or even more, and the research is consistent on why the second half is hard.
Gartner's 2024 Tech Trends in Manufacturing survey found that 48% of manufacturing software buyers regret a recent purchase, with implementation issues as the primary driver. Software gets bought, gets deployed, and then doesn't get used the way it was meant to be.
Deloitte's 2025 Smart Manufacturing and Operations study, surveying 600 executives at manufacturers with $500M or more in annual revenue, points to why: human capital is the lowest-maturity area in the entire smart manufacturing stack. Manufacturers invest in the technology, but not in the people who have to use it.
The World Economic Forum's Global Lighthouse Network 2025 report shows what the manufacturers who get this right do differently. For every $2 they spend on technology innovation, they spend roughly $5 on scaling and adoption.
The right EAM software at the frontline, plus the work to get it used there, is what makes maintenance's value visible to the business.
A platform with 35% adoption produces a partial data trail. A platform with 85% adoption produces one the business can act on. The gap between them is the difference between the data that proves maintenance's value and the data that doesn't.
The economics of this gap, with worked examples at the per-hour and per-month level, are covered in our article: Your EAM software ROI depends on one thing: whether anyone uses it.
For a quick sense of the figure for your own operation, the EAM software ROI calculator models it directly.
What changes when the data flows.
When the data trail improves, both the work itself and the case for it get better. Here’s are examples of three things that shift:
Reporting becomes a byproduct of doing the work, not a separate task at the end of the shift. Time gets recorded from a phone connected to SAP, against the actual asset, while the work is happening. The difference between rounding to the nearest hour and capturing the actual minutes compounds across thousands of work orders a month. Functional location attribution stops being approximate.
Planning shifts from triage to optimization. When the schedule reflects reality and updates inside seconds rather than days, the planner is no longer reconciling. They are making decisions about the next 90 days instead of firefighting the next 90 minutes. Capacity views become useful rather than decorative.
The case for maintenance changes shape. Technicians spend less time hunting for forms or information and more time on the work itself. Planners send people in with everything they need on the first visit. Reliability metrics start tracking what is actually happening on the floor and can be used for real optimization. And when the maintenance lead walks into a budget meeting, the data carries the case.
Energy Transfer's use of FastWork is a concrete example of what this looks like at scale: 8,000+ SAP technicians on Arkyn's mobile apps creating measurable value for the organization. The full case study covers the rollout.
Clean data for the agentic future.
Clean data does two things for maintenance. It shows the value already being created, and it makes the work itself better as it gets captured. SAP's autonomous future will amplify both.
SAP is putting AI agents and autonomous workflows into the platform, including a new Autonomous Asset Management scenario where agents analyze incident history to generate work orders.
All of them depend on clean operational data.
Maintenance teams that close their data gaps today are also setting up for what comes next.
Where to start.
Most asset-heavy SAP environments don't need a strategy day to identify the problem. They need to audit the data trail and find where it breaks first.
Start by mapping what reporting, notification capture, and scheduling actually look like for the people doing the work. Where are technicians keying data in from memory? Where do issues get reported by phone instead of into the system? Where does the schedule lag reality by more than a day?
Find the bottleneck and work on improving it.
Maintenance generates business value. It always has. The work now is making sure the people and systems that decide what happens next can see it.