01
Record only
Example: A single failure with low downtime and a known cause
Approach: Coded on the work order and trended across sites
Multi-Site Maintenance
Multi-site maintenance standardization for plants that each report differently
Every plant codes failures its own way, counts downtime its own way and runs root cause analysis when it has time. Agnotic Technologies builds the software layer that gives all your sites one maintenance standard: shared asset classes, failure codes, PM templates, KPI definitions and one RCA method, on top of the CMMS each site already runs.
Shared failure codesPM templatesComparable KPIsOne RCA method
Trusted by global innovators
How do we standardize maintenance across all our sites?
Standardize maintenance across all your sites by agreeing one shared model, which asset classes, failure codes, work order types, priorities, PM templates and KPI formulas every site uses, and then building software that applies it in each site's CMMS or maps each site's local codes onto it. Agnotic Technologies builds multi-site maintenance standardization as that layer: a standard library owned by central reliability, connectors to SAP PM or the CMMS at each plant, mapping rules for codes that differ, and reports that flag sites drifting from the standard. Sites keep running their own work; the data they produce becomes comparable.
Benchmarking
How do we compare maintenance between sites when every site reports differently?
Compare sites only after each metric has one definition and each site's data is mapped to it. Maintenance benchmarking across plants fails on definitions far more often than on data, so this is the table we agree with your reliability team first.
| What you compare | Why sites report it differently | What the shared standard fixes |
|---|---|---|
| Downtime | One site counts from the breakdown, another from the work order, a third leaves out short stops | One start and end event, and one minimum duration, for every site |
| Failure counts | Free-text descriptions, or local code lists of different depths | Shared problem, cause and action codes, with local codes mapped to them |
| Planned versus reactive work | Work order types and priorities named and used differently | Common work order types, so the planned share means the same thing |
| PM compliance | Different grace periods and different rules for skipped tasks | One rule for on time, late and missed, applied by the software |
| Maintenance cost | Contractor and spare part costs booked to different places | Cost elements mapped to one structure per asset class |
| Mean time between failures | Assets grouped and named differently at each site | Shared asset classes, so like is compared with like |
Site leaders sign off the definitions before any comparison is published. Where a site cannot meet a definition yet, the report says so instead of showing a misleading number.
Root cause analysis
How do we make every site run RCA the same way?
Give every site the same trigger rules, the same steps and the same record, built into the software instead of a slide deck. Root cause analysis software for maintenance then guides each investigation and stores it where other sites can find it.
Trigger
A failure that meets a shared rule, such as repeat failure, safety impact or long downtime, opens an RCA automatically.
Team
The investigation names its lead and members, including the site that runs the same asset class if you choose.
Evidence
Work order history, sensor and CBM data, photos and the failed part are attached before analysis starts.
Analyze
The team uses the method set for that level, such as 5 Whys, a fishbone diagram or a fault tree.
Act
Corrective actions become tasks with owners and due dates, and PM template changes go to central reliability.
Share
The finished RCA is coded by asset class and failure mode, so every site with the same asset sees it.
RCA levels
Which failures need a full RCA?
Not every breakdown needs a full investigation. Shared trigger rules decide the depth, so sites do not each decide alone. The thresholds below are examples your reliability lead replaces with your own.
02
Quick RCA
Example: A repeat failure on the same asset within your set period
Approach: A short 5 Whys by the site team, reviewed by the maintenance lead
03
Full RCA
Example: Long downtime, high cost or a failure on a critical asset class
Approach: A cross-functional team, a structured method and actions tracked to closure
04
Safety or process safety event
Example: An incident with harm, or one that could have caused a serious release
Approach: Your incident investigation procedure, with the RCA record linked to it
The standard
What goes into the shared maintenance standard?
The library central reliability owns and every site uses.
Assets
- Asset classes and hierarchy levels
- Criticality rules
- Naming and tagging rules
Codes
- Problem, cause and action codes
- Failure modes per asset class
- Mapping from each site's local codes
Work
- Work order types and priorities
- PM and CBM templates per asset class
- Task lists and spare parts
Measures
- KPI formulas and event definitions
- Downtime start and end rules
- Cost structure
Different CMMS at each site
Does every site have to run the same CMMS?
No. Standardization is about the data model and the method, not the brand of CMMS. Sites on SAP PM can carry the shared codes in their notification catalogs, and sites on another CMMS can keep their local codes while the software maps them to the standard.
Moving every site to one CMMS can still make sense later, and a shared standard makes that migration easier because the codes and templates are already agreed.
Failure points
Why do multi-site standards drift?
Where standardization programs lose ground, and what the software does about it.
Challenge
The standard lives in a document nobody opens.
Agnotic approach
The standard is the code list and templates inside the system, not a separate file.
Challenge
Sites add their own codes when the list does not fit.
Agnotic approach
New codes are requested, reviewed and either added or mapped.
Challenge
Benchmarks are argued about instead of acted on.
Agnotic approach
Definitions are signed off before reports are published.
Challenge
RCAs stay inside the site that ran them.
Agnotic approach
Finished RCAs are searchable by asset class across every site.
Challenge
PM templates diverge after each local change.
Agnotic approach
Local changes are tracked against the central template and reviewed.
What do we build for multi-site maintenance?
Modules for central reliability, site maintenance leads and planners.
Standard library
Asset classes, codes, PM templates and KPI definitions with version history.
CMMS connectors
Work orders, notifications and history read from SAP PM and other CMMS at each site.
Code mapping
Each site's local codes mapped to the shared standard, with gaps flagged.
Cross-site reports
Benchmarks by asset class and KPI, with data quality shown beside each number.
RCA workflow
Trigger rules, methods, evidence and actions, the same at every site.
Failure pattern search
AI that finds similar failures and past RCAs across sites for an engineer to review.
CBM data
Condition readings from sensors and historians linked to assets and failure modes.
Drift reports
Sites, codes and templates moving away from the standard.
Related builds
Where does standardization connect?
The standard sits on top of the systems each site already uses.
CMMS software
The work order system at each site, which keeps running day to day.
SAP PM integration services
Notifications, catalogs and maintenance orders exchanged with SAP PM.
Predictive maintenance software
Condition monitoring and failure prediction on the assets the standard defines.
Asset performance management software
Asset health and criticality across the portfolio.
Facts and sources
Which OSHA rules shape maintenance records and investigations?
Process safety management rules for inspection records and incident investigations at covered processes, each linked to the eCFR.
In processes covered by OSHA process safety management, 29 CFR 1910.119(j)(4) requires inspection and testing procedures that follow recognized and generally accepted good engineering practices, at a frequency consistent with manufacturers' recommendations and good engineering practices, and more often if prior operating experience shows it is needed.
Source: 29 CFR 1910.119(j)(4) (eCFR)29 CFR 1910.119(j)(4)(iv) requires each inspection and test on covered process equipment to be documented with its date, the name of the person who performed it, the equipment's serial number or other identifier, a description of the inspection or test and its results.
Source: 29 CFR 1910.119(j)(4)(iv) (eCFR)For an incident that resulted in, or could reasonably have resulted in, a catastrophic release, 29 CFR 1910.119(m) requires an investigation started no later than 48 hours after the incident and a report that includes at least the date of the incident, the date the investigation began, a description, the factors that contributed and any recommendations.
Source: 29 CFR 1910.119(m)(1) to (m)(4) (eCFR)29 CFR 1910.119(m)(5) to (m)(7) require a system to promptly address and resolve the report's findings and recommendations, documented resolutions and corrective actions, and retention of incident investigation reports for five years.
Source: 29 CFR 1910.119(m)(5) to (m)(7) (eCFR)
Standards
Standards we build the shared model around
ISO 14224ISO 5500129 CFR 1910.119(j)29 CFR 1910.119(m)SAP PM catalogs
Who it is for
Operators with several plants and one reliability team
Groups that need to compare sites and share what each one learns.
Multi-plant manufacturers
Similar lines at several sites, with different maintenance histories.
Process and chemical groups
Shared asset classes, with process safety records at covered sites.
Food and beverage groups
Plants acquired over time, each with its own CMMS habits.
Utilities and energy operators
Spread-out assets maintained by regional teams.
Scope
What decides the size of a standardization build?
We do not publish prices. These are the drivers we size on the scoping call.
Sites and systems
How many sites, and which CMMS or SAP PM setup each one runs.
Asset classes
How many classes the first release standardizes.
Code mapping
How far each site's local codes are from the standard.
KPIs
Which measures are compared first, and the data each needs.
RCA workflow
Trigger rules, methods and how actions reach each site.
CBM data
Sensors and historians to connect, if any, in the first release.
Engagement
How does a multi-site standardization project run?
We start with two sites and one asset class, then extend.
1.
Scoping call
We review how two or three sites code failures, measure downtime and run RCAs today.
Scope2.
First release for one asset class
A fixed-scope first release: the standard for one asset class, mapping for two sites and the first comparable report.
Build3.
More sites and the RCA workflow
More asset classes and sites, the shared RCA workflow and drift reports, with support after launch.
ScaleFrequently Asked Questions
No. Historical codes can be mapped to the standard where the meaning matches, and history that cannot be mapped is shown as unmapped rather than guessed. New work is coded to the standard from go-live.
Usually a central reliability or maintenance excellence team, with a named contact at each site. The software routes code requests and template changes to them for review.
Yes. A site can vary a template for its own conditions, and the change is recorded against the central template so reliability can see the difference and decide whether to adopt it.
No. Each site keeps its CMMS for daily work. The standardization layer sits above it, sets the shared codes and templates, and reads the data back for comparison and RCA.
We do not publish prices. Sites and systems, asset classes, code mapping, KPIs, the RCA workflow and CBM data decide the size, and we agree a fixed first release on the scoping call.