Maintenance runs on the work orders, equipment records, and history in SAP. Planners schedule against that data, reliability engineers analyze it, auditors depend on it, and the AI agents SAP is now building will act on it.
Yet the quality of that data is rarely decided inside SAP. It's decided at the frontline, by the people doing the work.
There's the SAP data that helps technicians get the job done, and there's the data they enrich SAP with as they work. Get that loop right and planning sharpens, wrench time climbs, and the maintenance and reliability record in SAP starts to match reality. Get it wrong and you have expensive software feeding a maintenance history nobody trusts.
This article is about the frontline as the critical breakpoint for maintenance and reliability data, and what it takes to make it future ready.
Where SAP maintenance data lives or dies.
Inside Plant Maintenance (PM), the core module of SAP's Enterprise Asset Management (EAM), maintenance teams work with two kinds of data, and it helps to keep them separate.
Master data is the stable backbone:
Equipment, functional locations, bills of material, task lists, maintenance plans, and the catalog profiles behind your damage and cause codes. It is set up and governed centrally, not created in the field.
Transactional data is the running record of the work:
Notifications, work orders, operation confirmations, time bookings, measurement documents, and the damage and cause codes entered when a job is closed. Most of this is created at the frontline, by a technician, an operator, or a planner, one entry at a time.
The frontline touches both:
It produces almost all of the transactional record. It is also the first place master data meets reality. The technician in front of the asset finds the functional location that doesn't match the field, or the bill of material that lists a part the machine doesn't use. When that person can flag the mismatch in the flow of work, master data gets better. When they can't, the gap stays hidden until it causes a problem.
So the frontline is where maintenance data is made as well as tested. That is why it sets the ceiling on everything downstream.
What frontline data is for, and which stream is the weak link.
Good data is not the goal in itself. It earns its keep when the three streams of maintenance data are connected:
- Asset registry and work history. The equipment master, functional locations, bills of material, notifications, work orders, and PM plans, most of it living in SAP.
- Operating context and condition signals. SCADA, historians, and sensor readings for vibration, temperature, pressure, and load.
- Inspection and execution reality. The readings, checklists, measurements, photos, defect observations, damage and failure modes, and notes that come from people doing work.
Two of those streams belong in SAP, and one does not. The asset registry, the work history, and the execution record are the system of record's job, alongside the procedures, permits, and skills that decide who can do what.
Condition and sensor data is different. It typically lives in specialized historians and OT and IT systems, connecting when it is needed.
SAP is the most powerful island in the enterprise, but it is still an island, and the frontline data has to reach it. Too often it doesn't.
Connect the streams and you can plan against what is really happening instead of last week's spreadsheet, move toward prediction rather than reacting to failures, and give the AI agents SAP is now building something accurate to act on. We wrote about SAP's AI shift in our guide to SAP's Autonomous Enterprise.
The three streams are not equally easy to capture:
- Asset registry and work history is structured by design.
- Operating context and condition signals arrive from sensors.
- Inspection and execution reality depends on a human capturing it.
The frontline is where most of the variance in quality lives, and the stream most likely to be thin, late, or missing.
This is also why maintenance is harder to automate than back office work. SAP's core processes such as finance, procurement, and invoice handling are already highly digitized and well-captured in the system, which is what makes them realistic candidates for the agents SAP is building.
Maintenance runs the other way. Much of what matters never reaches SAP at all. It lives in spreadsheets, in email, and as tribal knowledge in the heads of experienced technicians.
So the weakest link is the data that depends on people. Which brings us back to the frontline experience.
The frontline data loop.
How good that frontline data gets depends on the experience around it. Two things shape it: what a technician can see while they work, and how easily they can report what they did.
SAP data into the field.
Studies typically put maintenance wrench time, the percentage of working time technicians spend actually doing the work with tools in hand, between 25 and 50 percent for North American industries (Source: R. Keith Mobley and Ricky Smith's Rules of Thumb for Maintenance and Reliability Engineers).
Much of the rest goes to travel, waiting, and hunting for information. The work order detail, the asset history, the right bill of material, the document that explains how the job is done; a lot of that information already exists in SAP, it just isn't in the technician's hands at the moment of work.
Put helpful context in, say, a mobile app that works offline and loads fast, and time spent searching or waiting for information turns back into time spent fixing.
Data flowing back into SAP.
When reporting is fast and the software is easy to use, people are more likely to capture the full picture: the damage code, the measurement, the photo, the note about what they actually found.
When reporting is slow or difficult, they tend to do the minimum: defaults get accepted, codes get skipped, and time gets rounded to the nearest hour.
Research on maintenance data systems found that hard-to-use software pulls technicians' attention toward fighting the system instead of doing the task. The data that reaches SAP is then patchy, and planning built on patchy data is back to guesswork.
This is where the AI stakes show up. As our CTO, Rune Durhuus-Andersen, puts it plainly: "you can't really run AI on data you don't have."
Deloitte makes the same point from the data-governance side:
"Everyone is betting on AI. But AI without trusted master data, is like operating on a patient without knowing the patient's history – risky, unreliable, and potentially harmful if not fatal."
– Nishant Sinha, AI & Data, Deloitte
The agents act on what they read. If the frontline record is thin, the agent is confidently wrong.
Why the existing options fall short.
We have seen this up close. More than a decade ago, before Arkyn existed, our cofounder Rune Durhuus-Andersen was part of a field study at a large manufacturer, shadowing technicians through their day.
As he tells it: "We counted every system the technicians used to piece together what to do, when to do it, and how. It came to more than 40 different IT systems, plus a wall of paper forms." Almost none of it fed back into SAP, and what existed was scattered across those systems.
That is the status quo the common options inherit, and most were not built to close the loop.
SAP GUI on a desktop keeps the data central but wasn't built to reach the assets. So the field runs on paper, PDF forms, phone calls, and spreadsheets, and the record is updated hours or days later.
The SAP mobile stack can reach the field, but teams often find it slow and hard to use, leading to technicians reverting to old ways of working.
Custom builds can fit a single site, but they take months to deliver, typically struggle with large data volumes, and break when SAP is upgraded.
Generic CMMS and connected-worker software is often easier to use, but it lives in its own silo. The data takes a parallel path, syncs on a delay, and the SAP record, the one planners and auditors rely on, is always a step behind.
None of these is wrong, exactly. Each solves part of the problem. None of them delivers a fast, two-way connection to SAP that frontline workers use every day.
How a Frontline OS helps.
That gap, the lack of a dedicated layer between SAP and the frontline that technicians actually use, is what Arkyn's Frontline OS fills. Its job is to make the loop reliable: the right context (SAP data) out to the field, clean and structured data back into SAP, in real time, with no parallel database and no core modifications, in line with SAP's clean core direction.
At Arkyn, that is what we have built with our FastApp Suite.
- Technicians get work orders, history, and documents on a native app that works offline.
- Any employee can raise a SAP notification from their phone.
- Inspections and readings bind to SAP equipment and can open a notification the moment something is out of range.
- Planners schedule against live data.
- Leaders watch KPIs and data quality side by side.
- FastCloud carries it all to and from SAP PM and CS in real time.
Average adoption across our deployments runs at 85 percent. Adoption is what makes the rest real: software people don't use produces no data worth having.
SAP is moving toward agents that plan and act on maintenance data. The companies that get the most from that shift will be the ones whose frontline loop is already producing data worth acting on. That layer is built one work order at a time, at the frontline, and it is important to get right before the agents arrive.