Asset Strategy Management ASMx

A good maintenance plan needs a life after the workshop

Jason Apps’ Asset Strategy Management ASMx connects maintenance decisions with the organisational process needed to keep them useful. The publisher presents it as a guide for leaders: why strategy management matters, what it involves, and how it supports a reliability culture. Its value on this shelf is the link between technical analysis and what an organisation actually implements. Publisher’s overview.

The opening chapter describes organisations with reliability engineers, maintenance systems and improvement projects, but little control over the maintenance strategy itself. Plans may change informally, or remain untouched because changing them is too difficult. Neither situation guarantees alignment with the asset’s current needs. The published contents extend that discussion into strategy development, governance, digital tools, organisational culture and implementation. Official book preview.

My reading takeaway: ask what happens after an analysis is approved. Can the team find the reasoning, put the decision into practice, and return to it when conditions change? That is a useful test whether the starting document is an RCM study, an OEM recommendation or a local maintenance review.

Strategy and execution answer different questions

ARMS Reliability distinguishes strategic activity from the transactions that keep assets running. Strategy management determines the maintenance approach needed for the desired performance, cost and risk. Work management organises and executes the resulting work. A strong execution process is valuable, but its completion figures alone cannot establish that the underlying strategy is appropriate. Strategic and transactional asset management.

For example, a perfectly scheduled inspection can still have an unclear acceptance criterion. Improving schedule compliance will not resolve that ambiguity. Equally, a technically sound inspection is ineffective if the technician cannot access the measurement point. Both sides need attention; the table is our practical way of separating those conversations.

Build, deploy, sustain

In his public introduction, Apps presents ASM through three phases. Build establishes the structure and baseline strategies. Deploy connects those strategies to actual assets and the maintenance plans used in execution. Sustain keeps the process responsive as evidence and operating requirements evolve. His central point is that good strategies must reach the assets, remain reviewable and accommodate justified differences. Apps’ introduction to ASM.

A practical handover test is to follow one requirement all the way through. A document marked “approved” is insufficient if the corresponding job plan is missing. A job plan marked “active” is insufficient if the people doing the work still use an obsolete instruction. Check the actual route the information takes.

Reuse knowledge without ignoring the asset’s context

Apps’ article on ASM describes a consolidated base of reliability information that supports consistent strategies while allowing local operating differences. It also links this information to maintenance master data and to the deployment of relevant changes across an asset population. The missing piece in the asset management puzzle.

Consider three similar pumps: one runs continuously, one is standby, and one handles a more demanding fluid. A shared equipment model is useful, but identical hardware does not prove that every maintenance requirement should be identical. Our practical interpretation is to record what is common, what differs, and why. A local exception should be understandable to the next engineer, rather than depending on someone remembering a conversation.

This also changes how a useful finding travels. Ask which other assets share the relevant failure mechanism and conditions, instead of copying a new task to every pump. Reuse the reasoning first; then decide where the resulting task belongs.

A strategy change is an engineering decision

ARMS Reliability’s explanation of ASM emphasises controlled changes: proposed adjustments need justification, review and approval, with a route for applying useful improvements elsewhere. This includes changes to intervals, task content and execution requirements. Treating strategy review as an ongoing process also prevents each improvement project from becoming an isolated exercise. Why strategy management matters.

The useful record is short but specific: the affected asset, previous requirement, proposed requirement, supporting evidence, approver and implementation check. This gives a future reviewer something better than “we changed it last year”. The level of review should reflect the consequences of the decision.

Worked example: a recurring seal failure

Illustrative scenario, created for this guide: a process pump repeatedly develops seal leakage. The maintenance plan says “check pump condition”, and completed work orders contain little detail. The immediate temptation is to inspect more often. Start by finding out what that inspection would detect and what action would follow.

1. Define the problem. Record the required pump function and the circumstances of the leakage. Separate observations from possible causes. A seal defect, an operating excursion and an installation problem call for different responses.
2. Examine the existing task. Identify the measurement or observation, acceptance criterion, access requirements and response to an abnormal result. If these are unclear, a completion tick tells little about task effectiveness.
3. Evaluate a proposal. Suppose the evidence points to an operating condition that the existing round does not capture. Compare an operational check, a maintenance task and a design change. Do not assume that another recurring inspection is the best answer.
4. Implement the approved decision. Identify the affected pump and job plan, update the instruction, brief the people involved and verify that the next work order contains the intended requirement.
5. Review the result. Agree in advance what evidence will be collected and who will assess it. Record further leakage, relevant operating conditions and findings, including occasions when no defect is found.

No inspection interval or saving is prescribed here: neither can be justified from this fictional scenario alone. The point is traceability. Someone should be able to connect the field observation, engineering decision and deployed instruction without reconstructing the whole story from emails.

Let RCA improve the strategy

Apps’ article on integrating RCA with ASM makes two useful connections. First, a recommendation from an investigation still needs assessment before it becomes a maintenance requirement; adding tasks automatically can create ineffective work. Second, a solution developed for one failure may be relevant to similar assets, provided their owners assess its applicability. ASM supplies the route for reviewing and implementing those changes. Integrating RCA and ASM.

In practice, attach the investigation evidence to the proposed strategy change. Make the action owner responsible for confirming implementation, not simply for sending a recommendation. When the action is closed, retain the reason for accepting or rejecting it on related assets. That turns a local lesson into usable organisational knowledge.

Start with one complete loop

Our suggested first exercise is deliberately small: choose one asset family and follow one strategy revision from evidence to execution. Bring together operations, a technician, the planner and the reliability owner. Use the actual records, not an idealised process map.

• Before the review: collect the current instruction, relevant findings and the reason the task exists.
• During the review: agree the failure being addressed, the decision needed and who can approve it.
• After approval: check the live maintenance record and the instruction available to the technician.
• At follow-up: compare what was expected with what was observed, and decide whether another change is warranted.

For this pilot, track a few practical measures: how many selected tasks have a documented rationale, which approved changes remain undeployed, and how long those changes have been waiting. Treat these as process checks, alongside asset performance and risk. More completed reviews alone do not prove better reliability.

Read ASMx with RCM II for maintenance decision logic, Doc Palmer for preparing and scheduling work, and ISO 55000 for the wider asset management system. The connection to keep in mind is simple: decisions need an owner, an implementation path and a reason to be revisited.

Sources and reading notes

This independent reading guide combines the official book preview, the publisher’s description and the author’s public explanations linked above. It is not a chapter-by-chapter account of the full book. The pump scenario, checklists and diagrams are Reliability Factory’s own teaching material. Read the original for Apps’ complete argument and implementation framework.