What SAP PM Taught Me About Maintenance Discipline

Early in my career at K-Electric, I was the plant team lead for implementing SAP's Plant Maintenance module at our station. I went in thinking it was about software. It wasn't — or rather, the software was the smallest part of it. What putting a plant into a system really teaches you is how disciplined you are, because a system won't accept the comfortable vagueness that paper and memory let you get away with.

You Cannot Computerise a Plant You Cannot Describe

SAP PM starts with a simple-sounding demand: describe your plant as a structure. The site breaks into functional locations — areas and systems with a defined function — and under them sits the equipment: every pump, motor, breaker and engine worth tracking on its own. Building that hierarchy forced questions we'd been avoiding for years. Is this cooling pump one asset, or part of a system? Where does the engine end and its auxiliaries begin? Which instruments deserve their own record, and which ride along with their parent?

No software answered those questions. They were engineering judgement, argued out in a room, asset by asset. Every implementation since has confirmed the same thing: a maintenance system is decided in those arguments, long before anyone configures a screen. A sloppy hierarchy gives you sloppy history for a decade. A sound one keeps paying you back for just as long.

The Work Cycle Is a Moral System

Once the plant exists in the system, work flows through it in a fixed order: operations raise a notification when something is wrong; the notification becomes a work order with scope, priority and permits; planning attaches labour, spares and a schedule; technicians execute and confirm what they actually did; and the order closes into history — costs, hours, failure codes and all.

The SAP PM work cycle — five steps that turn a fault report into permanent plant memory.

None of this is bureaucratic decoration. Each step kills a specific failure of the paper age. The notification kills the verbal fault report that evaporated at shift change. The work order kills the job that lived in one supervisor's notebook. Planning kills the overhaul that started before its spares existed. Confirmation — the step everyone resists — kills the quietest lie in maintenance, the job marked done in full when it was done in part. And history kills the recurring failure nobody recognised as recurring, because nobody could see the last four times.

What the Numbers Started Saying

Once two or three years of honest history build up, the plant starts to talk. Which equipment eats the most maintenance hours. Which failures repeat by season, by operating regime, by spare-part batch. What a station truly spends per megawatt-hour on maintenance, system by system, instead of in one unaccountable lump. I've used exactly this kind of evidence since — in budgets, in inventory decisions, and years later in regulatory work, where maintenance costs have to be defended line by line. None of it exists unless somebody, at the workface, typed the truth into a work order years earlier.

That's the part of SAP PM nobody puts in the brochure: the system's memory is built entirely out of small acts of honesty by busy people who'd rather be turning wrenches. Protecting their willingness to do it — simple screens, sensible mandatory fields, feedback showing their entries mattered — isn't an IT concern. It's the whole game.

The Lesson That Outlasted the Project

The implementation ended, as projects do. The discipline question didn't. SAP PM taught me that a maintenance organisation gets the data it insists on, and only that data; that a register is a mirror — if the plant in the system is fiction, every report built on it is fiction with better formatting; and that "the system is down" is never the reason maintenance history has gaps. Attitude is. Tools are. The software is just the most patient supervisor ever assigned to a plant: it asks the same questions every day, of everyone, without fear or favour — and it writes down what it hears.

Years later, working with other systems and other plants, I still judge a maintenance organisation by the standard that project set: show me your asset register and your last hundred closed work orders, and I'll tell you how your plant is really run. The turbines only confirm it.

The Takeaway

A CMMS implementation is not an IT project with a maintenance flavour; it is a discipline project with a software tool. Build the hierarchy with engineering care, defend the work cycle's honesty at every step, and treat the history you accumulate as the asset it is — because one day, in a budget meeting, an overhaul plan or a tariff hearing, that history will be the only witness that cannot be argued with.

Related tools and reading: Engineering Calculators · The Maintenance Mix.

Further Reading

Asset Management in SAP Cloud ERP (SAP) — where the PM concepts in this post now live in SAP's current product line: maintenance planning, scheduling, execution and asset analytics.

Saad Hafeez is a Chartered Mechanical Engineer and Deputy General Manager – Power Plants at OMS. In his first K-Electric tenure he was the plant team lead for the SAP PM implementation at his station.