Most documents called an Asset Management Plan are maintenance plans wearing a better cover page. A list of preventive tasks, a criticality rating, maybe a spares list, all correctly done and still not an Asset Management Plan, because maintenance is one input into the decision, not the decision itself.
Asset management is the coordinated activity an organisation undertakes to realise value from its assets, and that value is both financial and non-financial: revenue and cost on one side, service, safety, reputation and risk on the other. An Asset Management Plan is where that balancing act gets made specific and decided for one asset class: what this asset class must deliver, what it will cost across its whole life rather than this year, how much risk is acceptable, who is accountable, what data has to exist for any of that to be trusted, and what happens when circumstances change. Maintenance strategy answers one part of one of those questions. Everything else in that list is still the plan's job.
This article sets out what actually belongs in an Asset Management Plan once it is built to the full width of the discipline rather than the width of one function's expertise, why it has to be built one asset class at a time using your asset classification structure, and why most organisations, understandably, only ever get around to building a third of it.
One Plan Per Asset Class
An Asset Management Plan is written for an asset class, and that scoping decision is what makes everything downstream specific enough to act on rather than aspirational enough to ignore.
A single crusher and a single conveyor do not carry the same criticality, the same demand profile, the same failure economics or the same skills requirement, so a plan broad enough to cover both usually ends up saying very little about either. A mining operation with twelve major asset classes needs, in substance, twelve Asset Management Plans, not one plan with twelve paragraphs.
This is exactly where asset classification earns its place as a prerequisite rather than a side project. Asset Class sets the plan's boundary. Asset Class Type is usually where demand, risk and delivery genuinely start to differ within that boundary. Asset Class Type Variation is where the plan sometimes needs one further level of precision, because two variations of the same type can carry different economics even though both sit under the same heading. Scope the plan against a classification structure that has not been properly defined, and every ambiguity in that structure becomes an ambiguity in the plan.
The Decisions It Actually Has to Make
Strip away the paperwork and an Asset Management Plan exists to answer a small number of genuinely hard questions, deliberately, rather than by default.
What service or output does this asset class have to keep delivering, now and as demand changes. What is an acceptable level of risk for this class, given its consequence profile, and who decided that acceptable level rather than inherited it from whatever tolerance happened to exist before. Where a repair, a refurbishment or a full replacement are all technically viable, what criteria decide between them, and at what point in the asset's condition does that decision get triggered rather than argued about during an outage. How much should be spent maintaining current performance versus improving it, and how is that trade-off made consistently across a portfolio rather than won by whoever argues loudest at budget time.
Most organisations do make these decisions. What they don't do is write down the criteria beforehand, which means the same decision gets re-litigated from scratch every time it comes up, usually under pressure, usually inconsistently between sites. An Asset Management Plan that only describes the current maintenance regime has skipped the harder and more valuable job: setting out, in advance, how this asset class's cost, risk and performance trade-offs will actually be decided.
Where the Money Lives
A plan that engineering trusts and finance quietly works around is not a functioning Asset Management Plan, it is two separate versions of the truth that happen to describe the same equipment.
This is the dimension a purely technical plan almost always leaves out, and it is usually the one that determines whether the plan gets funded at all. The plan needs to state, for this asset class, what spending is capital and what is operating, because that classification changes who approves it and how it is reported, and getting it wrong is a recurring source of friction between engineering and finance. It needs a whole-of-life cost view, not an annual maintenance budget, because a decision that looks cheap this year and expensive over ten years is not actually the cheap decision. And it needs to connect its condition and criticality data to how the asset is valued and depreciated on the books, because an asset register that only reliability engineers look at and a fixed asset register that only finance looks at will drift apart, quietly, until an audit or a write-down forces the conversation nobody wanted to have earlier. None of this requires an accounting qualification to write. It requires treating finance as a stakeholder in the plan, not a function that receives the invoice afterwards.
Delivering It
This is the layer most asset management content starts with, spends all its time on, and mistakes for the whole plan.
Once the decisions and the money are set, the plan needs a genuine, analytically grounded delivery strategy: the preventive, predictive and corrective maintenance mix appropriate to this asset class's actual failure modes, developed through FMECA or RCM rather than inherited from whatever the previous site did; how the asset class will be operated day to day within its design envelope; how acquisition, renewal or upgrade projects for this class will be planned and executed; and how shutdowns or outages affecting it will be scheduled and managed. This is real, necessary work, and it is where a lot of Shivaan Asset Management's own hands-on expertise sits. It is also, on its own, only one of several equally necessary dimensions. A plan that is excellent here and silent everywhere else is a strong maintenance strategy that has borrowed a bigger title.
The Data Foundation
None of the decisions above are worth much if the system underneath the plan cannot be trusted to record what actually happened.
Treat this data the same way you would treat any other asset the organisation depends on: it needs an owner, a defined structure, and a quality standard, not just a database. Asset classification defines what each asset is. A properly built functional location hierarchy defines where it sits and how its data rolls up. Only then does a failure code library mean anything, and every asset class type variation needs its own set, aligned to real failure modes rather than three generic codes that catch everything and explain nothing. Skip this step and technicians default to free text, condition data stops rolling up cleanly into the valuation the finance team relies on, and reliability trending, dashboards or any AI-based analysis inherit the same weak foundation no matter how good the tool sitting on top of it is. Get the classification and the failure codes right once, and every future use of that data, financial, technical or compliance, gets faster and more trustworthy.
The People, Partners and Supply Chain Behind It
A well-reasoned plan with nobody accountable for it and no parts to execute it is a plan on paper only.
The plan should name who owns it and who is accountable for each major decision, not leave accountability implied. It should state the specific competencies this asset class requires and how the organisation currently covers them, across its own workforce and its contractors, and it should name where deep troubleshooting knowledge currently sits in one or two people's heads rather than in the organisation's systems, because that is a resourcing risk worth writing down, not a fact to discover when someone resigns. It should define the Bills of Materials for the class, built from the same classification structure so identical asset class type variations share BoMs instead of duplicating parts lists under different names, identify genuinely critical spares based on failure consequence and lead time, and name the approved vendors and OEMs, where the organisation is single-sourced and exposed, and what happens as an ageing asset class approaches the end of OEM support. Culture matters here too: a plan nobody feels ownership over gets treated as compliance paperwork, and compliance paperwork is exactly what does not survive contact with a production target.
Risk Beyond Failure
Failure-mode risk is the risk most Asset Management Plans manage, and it is only ever one part of the risk picture for an asset class.
The plan should also account for what happens when the assumptions underneath it change: a shift in demand, a regulatory change, a new safety case, a supply chain disruption, or a climate-related event affecting an asset class that was designed for different conditions than it now operates under. It should say what triggers an out-of-cycle review rather than waiting for the next scheduled one, and it should be genuinely reviewed against actual performance, not just re-approved on the anniversary of the last version. A plan that only manages the risk of equipment breaking has covered maybe half the ways an asset class actually lets an organisation down.
Want a structured way to work through all of this for your own asset classes? Download the Asset Management Plan template and build your first one properly, dimension by dimension, rather than starting from a maintenance schedule and hoping the rest gets added later.
Keeping It Alive
The organisations that get real value from their Asset Management Plans treat every one of them as a live management tool with an owner and a rhythm, not a document produced once for an audit and reopened only when the auditor comes back.
Every decision in the plan should trace to a specific objective in the Strategic Asset Management Plan it serves, and the line of sight has to run both ways: the AMP doesn't just receive objectives from the SAMP, it feeds back the cost, risk and performance evidence that tells the next SAMP review whether those objectives were realistic in the first place. That feedback loop, more than any individual section of the document, is what separates an Asset Management Plan that governs real decisions from one that quietly goes out of date the week it is approved.
The Plan That Actually Covers the Discipline
An Asset Management Plan done properly is a genuinely cross-functional document. Engineering has a stake in it. So does finance, procurement, HR and whoever owns the CMMS. That is precisely why most fall short: they get written by one function, in that function's language, and the other stakeholders never really pick them up.
Build one that sets out the decisions deliberately, connects to how the organisation actually accounts for money, delivers through an analytically sound maintenance and operations strategy, stands on a data foundation that other systems can trust, names the people and partners who make it real, and manages risk wider than equipment failure, and the SAMP stops being an aspiration and starts being how the organisation actually runs, asset class by asset class.