Configure for Execution
You or one of your team gets back from an SMRP conference, takes a class, tests for a cert, and asks a reasonable question: what is our proactive-to-reactive split?
What follows is a research project. Somebody exports twelve months of orders, opens Excel, and starts reading closure notes to work out whether "pump repair" was a breakdown, a PM finding, or scheduled work. Three weeks later, if they didn’t give up, there is a number. Nobody fully trusts it and there is no way to produce it again later in the year without running the whole exercise a second time.
Ask for failure modes and it gets worse. No one uses the legacy notification codes. Engineers in different areas have their spreadsheets. Some of it is in an APM. Some in a SharePoint list.
Ask why jobs ran long and a planner builds a Power App.
SAP can do all of this. It probably cannot do it the way it was configured by the tech team.
The Opportunity
SAP ends standard support for the legacy version (ECC) next year. Extended support is available at a premium until 2030. Over half of the market has not yet converted to the new version – S/4HANA. If you are in that bucket, there is opportunity in the coming pain – but only if you know what configurations you really need to focus on to enable your maintenance execution – how you conduct it and how you measure it.
There is a full manual in our Practitioner Library here.
A few key items are called out below.
Work type. Order type and maintenance activity type do different jobs. The order type is heavy machinery — settlement, approval, workflow, number ranges — so keep the set small and justify every one by processing behavior that genuinely differs. The activity type is a lightweight classifier on the same order, and it carries the reporting taxonomy. Few order types, more activity types. Get that split right and the proactive share is a query rather than a project.
Failure coding. The failure mode is how the machine stopped doing its job. The damage is the physical process that got it there. The cause is the circumstance that started it. Most builds let damage quietly do duty for all three, which is what makes failure history unusable later.
Take a seized pump bearing. Coded across every slot — seized, bearings, lubrication failure, improper or missed lubrication — it lands in the defect-elimination queue with a name on it. Change the cause code to normal wear-out, service life reached, and the identical bearing becomes expected life. That one field is the difference between knowing what your own maintenance is costing you and reporting a comfortable zero.
Delay codes are the same story. S/4 carries a variance code field in the Perform Maintenance Job app, so the craft can record the permit that didn't come or the part that wasn't staged at completion. Configure the code list and you have a duration with a cause on it. Skip it and somebody builds the app.
Where to go next
The SamOS SAP EAM Configuration Manual works through the ten decisions that determine whether your numbers assemble themselves or get rebuilt by hand every quarter — how work is classified, how findings are coded, what makes a job ready, what release actually means, and how what the field found gets back into the standard. It closes with a decision register you can take into a blueprint session, and it covers ECC and S/4HANA phase-based processing.
