A prediction that lands on a dashboard nobody opens is not a maintenance decision — it's a screenshot in a monthly deck. The planner's day starts in SAP PM or Maximo, and it ends there. If an AI model spots the preheater fan bearing drifting three weeks out and the output of that insight is an email, someone has to re-key it, guess the functional location, pick a notification type and hope the equipment number is right. Most of the time nobody does, and the failure that was predicted still happens on an emergency work order.
iFactory / Enterprise integration layer
Predictions Arrive as SAP PM Notifications, Not as Another Dashboard
iFactory maps its models onto your functional location hierarchy and equipment master, then writes maintenance notifications and work orders into SAP S/4HANA, IBM Maximo or Oracle EAM through standard interfaces. No ABAP in your core, no second planning system, no rip-and-replace.
Model output
ID fan DE bearing — rising envelope, 18-day horizon
Mapping layer
Functional location + equipment no. + catalog codes + priority
SAP PM
Notification created, routed to the planner's existing list
Standard APIs
no core changes
Closure loop
feeds the model
The Problem Is the Last Ten Metres
Cement plants have spent two decades getting maintenance into one system of record. The functional location hierarchy exists — plant, line, section, equipment, down to the individual cyclone stage and the ID fan motor. Planners schedule against it, cost sits against it, and the reliability numbers everyone reports are derived from it. That discipline is exactly why bolting a separate AI dashboard on the side fails: it asks a plant to run a second, unreconciled view of its own asset base.
The technical work is not the model. It's the mapping. A vibration model knows "kiln line 1 ID fan, drive end." SAP needs a functional location code, an equipment number, a notification type, a damage code, a cause code, a priority and a planner group — and Maximo needs a different shape of the same thing. Get that mapping right once and predictions flow into the work the plant already does. Get it wrong and you generate notifications nobody can action, which is worse than none.
Where the Prediction Dies Today
Four exits, all of them common, none of them ending in a scheduled job against the right asset.
Vendor dashboard
The condition-monitoring portal shows the alarm correctly. The planner doesn't have a login, doesn't open it on a Tuesday, and plans the week from the SAP worklist. The alarm is still amber when the fan fails.
PDF report
A monthly analyst report lists eighteen findings across the plant. Somebody transcribes the top four into notifications by hand, guessing at equipment numbers. The other fourteen exist only in a PDF filed on a shared drive.
Reliability engineer's Excel
A carefully maintained tracker joining predictions to planned shutdowns, owned by one person. It works well until that person changes role, and it never contributes to MTBF or cost history because it lives outside the system of record.
The morning meeting
Raised verbally, agreed verbally, actioned if the mechanical supervisor remembers. No notification number means no history — so when the same bearing goes again in fourteen months, nothing shows it was called correctly the first time.
What the Integration Layer Actually Maps
Four mappings decide whether an AI notification is actionable or noise. All four are established during scoping, against your live master data rather than a sample export.
Functional Locations
Your hierarchy as it really is — plant, kiln line, preheater stage, raw mill, separator, packing — so a model's asset concept resolves to the exact node a planner and a cost controller both recognise.
Source: FL master, read-synced
Equipment & Points
Equipment numbers, serial and class data, and measuring points with their characteristics — so a predicted value can post as a measurement document against the point the maintenance strategy already uses.
Source: equipment master
Catalogs & Types
Notification and order types, damage, cause and object part codes, priorities and planner groups — populated correctly at creation so the notification doesn't stall in someone's queue for want of a field.
Source: your catalog profiles
Materials & Stock
Bill of materials and spare availability checked at the moment the prediction is raised, so the notification carries a plain answer on whether the part is on site or needs a lead-time decision now.
Source: BOM + stock check
What Gets Written Back
Four objects, in your system, in the shape your planners and auditors already expect.
Notification
SAP PM
Maintenance notification against the functional location and equipment, with catalog codes, priority, required-by date from the model's horizon, and the evidence attached as long text.
Work Order
IBM Maximo
Work order or condition-triggered record with asset and location, failure class, job plan reference where one exists, and a route into the existing approval and scheduling flow.
Measurement
SAP / Oracle EAM
Model outputs posted as readings against measuring points — free lime estimate, bearing condition index, mill differential — so existing counter-based strategies react without new logic.
Closure feedback
Read back to iFactory
Completion text, actual damage and cause codes, and parts consumed read back after the job — the confirmed label that turns each prediction into training data instead of a guess.
Ask your maintenance planner how many condition-monitoring findings from last quarter became a notification with a number. If the answer comes from a spreadsheet rather than from SAP, the insight layer and the work layer aren't connected. Book an integration scoping call — we'll walk one real functional location branch end to end.
12-Week Integration Shape
One kiln line, one target system, twelve weeks. Nothing is written to production until the notification shape has been reviewed by the people who will receive it.
Weeks 1–2
Master Data Discovery
Read-only pull of the functional location hierarchy, equipment master, catalog profiles and planner groups for one line. Gaps and duplicates are surfaced and listed — most plants find some, and it's better found now.
Weeks 3–4
Shape Agreed in QA
Connection built in your sandbox or QA client. The planner and the reliability engineer review real sample notifications and change the wording, codes and priority rules until they'd action them without asking a question.
Weeks 5–8
Shadow Creation
Live model output creating notifications in QA only. Deduplication and suppression tuned against real volume so one drifting bearing produces one open item, not a daily repeat. Accept-versus-cancel rate measured weekly.
Weeks 9–12
Production & Closure Loop
Transport to production under your change process. Closure feedback enabled so completed jobs return actual cause codes to the model. First accuracy review held against confirmed outcomes rather than opinion.
Who Owns the KPI
Integration succeeds or fails on four numbers held by four different people. If only IT has a metric, the interface will be technically live and practically ignored.
Maintenance Planner
AI notifications actioned vs cancelled
Owns whether the output is usable. A high cancel rate is a mapping or threshold problem to fix, not a reason to switch the feed off — and it's visible in week one rather than in a quarterly review.
SAP / IT Applications
Interface error rate and auth scope
Owns the technical contract. Standard interfaces, a named service user with least-privilege authorisations, and errors that surface in your existing monitoring rather than in a vendor's log.
Reliability Engineer
Planned vs reactive work on target assets
Owns the outcome. The point of the write path is that findings convert into planned jobs in a shutdown window — the ratio shift on covered equipment is the proof the model is changing behaviour.
Maintenance Head
Unplanned kiln and mill downtime hours
Owns the business case. Downtime avoided on the covered line, traceable to notification numbers that exist in the system of record — an argument that survives an audit and a budget round.
FAQ
Will this flood our planners with notifications?
That's the failure mode we design against first, because a planner who has been spammed once will filter the source out permanently. Three mechanisms handle it: deduplication, so a condition that persists updates one open notification rather than creating a new one each day; confidence and horizon thresholds set per equipment class with the planner, so low-confidence signals accumulate silently until they firm up; and a suppression rule against already-open work, so a prediction on an asset with a job already scheduled attaches evidence to that job instead of competing with it. The shadow phase exists specifically to tune these against your real volume before anything reaches production.
Our functional location hierarchy is incomplete and some equipment isn't in the master. Does this still work?
Yes, and you'll get a usable master-data gap list out of it, which several plants have told us was worth more than the first quarter of predictions. The integration binds at the most specific node that genuinely exists — if the ID fan motor has no equipment record but the fan section has a functional location, notifications go to the section and say plainly which physical asset they concern. Nothing is invented, and no shadow hierarchy is created on our side. Where a gap is blocking value, we hand your master-data owner a specific, short list of records to create rather than a request to clean up the whole plant first.
Does this require changes inside our SAP or Maximo core?
No custom development in the core, and no modification objects. The integration runs side-by-side and uses the published interfaces your system already exposes — the standard OData and API services on S/4HANA, or the classic function-module and IDoc route on ECC; the REST and integration framework on Maximo; and the REST APIs on Oracle EAM and Fusion. What you do need to provide is a service user with a defined authorisation set, network reachability from the iFactory deployment to the application server, and a transport path through your normal change process. Read scope is limited to the object types listed above, and write scope is limited to notifications, orders and measurement documents — both are stated explicitly so your basis and security teams can review them rather than take our word for it.
Your planner should never have to open a second system.
See a Real Notification, Against Your Own Functional Location
Bring one line's functional location branch and one recurring failure you already know about. We'll show the notification iFactory would have created, with the codes, the priority and the evidence filled in — and you tell us whether your planner would have actioned it.
