Asset Analytics in D365 Asset Management: Lifetime Cost, MTBF, and the Replace or Repair Decision
Every maintenance article I have written in this series ends at the same point: the work order is ended and the cost posts. In the work orders article I made the case that ending orders promptly is a discipline, not a formality, because the ledger only sees the cost at that moment. Today I want to follow that cost after it posts, because the whole reason to run maintenance through D365 instead of a spreadsheet is what the history lets you do afterwards: see what an asset has really cost over its life, see how often it fails and how long it stays down, and decide with numbers rather than instinct when it is time to stop repairing something and replace it.
WHERE THE COST GOES AFTER THE ORDER ENDS
Three cost types flow through a maintenance work order: labour hours priced at the worker's cost price, spare parts issued from inventory at their inventory cost, and expenses such as external services or vendor invoices attached to the order. While the order is open, these sit as posted journals against the work order. When the order is ended, D365 posts the ledger side and, just as importantly for this article, stamps the cost into the maintenance cost history of the asset the order was raised on.
That history is what the cost control inquiries read. Asset management offers cost control views at three levels: per asset, per functional location, and per work order. The asset view is the one I use most, because it lets you pick a period and see the split between hours, items, and expenses for one asset, and compare it against a budget if you have created one. The functional location view rolls up every asset installed underneath it, which is why I keep saying that the hierarchy you designed in the functional locations article is not just a filing system: it is your cost roll-up structure. If a packaging line is a functional location with six assets under it, the line's cost is one click, and it is correct without anyone building a report.
Two practical points here. First, cost history is only as good as the ending discipline: an asset with five open orders looks cheap until the month someone closes them all at once and the trend jumps. Second, if you move an asset between functional locations, the cost follows the asset, but the location roll-up changes from the move date onward. That is usually what you want, but it surprises people who compare a location's cost across a year in which equipment was shuffled.
BUDGETS GIVE THE NUMBERS SOMETHING TO BE COMPARED AGAINST
Cost on its own is a number without a verdict. Asset management lets you create maintenance budgets, either entered manually or generated from the maintenance forecast of your preventive plans, and then compare actual cost against the budget in the same cost control views. I recommend generating the budget from the forecast even when nobody has asked for budget reporting, for one reason: the forecast represents the planned, preventive side of your maintenance, so anything that lands above it is, by construction, unplanned. That gap between forecast and actual is the simplest reliability signal you can get out of the module without any further setup.
FAULT HISTORY: THE DATA YOU ONLY GET IF YOU ASK FOR IT
Cost tells you how much; faults tell you why. Asset management has a structured fault model with fault symptoms, fault areas, fault types, fault causes, and fault remedies, and you can register a fault on a maintenance request or on the work order itself. The registration is optional, which is precisely the problem. If technicians close orders with a free-text note saying "fixed bearing", you have no data. If they select a symptom (vibration), an area (drive end), a type (bearing failure), a cause (lubrication), and a remedy (replaced and greased), you have a dataset that answers the question every reliability engineer asks: is this the same failure coming back?
My advice on fault codes is to keep the lists short and asset-type specific. A fault designer with two hundred causes will be ignored on a mobile device at the end of a shift. Ten to fifteen well chosen causes per asset type, with an "other" option that a supervisor reviews weekly, produces far better data than an exhaustive taxonomy nobody uses. Link the fault types to asset types so the technician only sees relevant choices.
DOWNTIME REGISTRATION AND WHAT IT UNLOCKS
Downtime is the third dataset, and it is the one production management actually cares about. Asset management lets you register asset downtime with a start and end time and a downtime reason code, and it distinguishes between downtime that was planned (the preventive stop you scheduled) and downtime that was not. Register it against the asset, and it becomes available both for the KPI calculations and for the production side, because a downtime period on an asset that is linked to a production resource can reduce the resource's available capacity.
• Register unplanned downtime from the maintenance request or the work order the moment the asset stops, not when the paperwork is done.
• Register planned downtime when you schedule the preventive order, so the production planner sees the outage in capacity before it happens.
• Keep downtime reason codes separate from fault causes: one describes why the asset was unavailable, the other describes what broke.
ASSET KPIS: MTBF, MTTR, AND AVAILABILITY OUT OF THE BOX
With cost, faults, and downtime registered, the module can calculate asset KPIs for you. The calculation is run as a periodic job over a date interval for a selection of assets, functional locations, or asset types, and it produces a KPI record you can inquire on and compare across assets. The figures I look at are mean time between failures (the average operating time between corrective events), mean time to repair (how long a corrective order typically takes from the fault to the asset being back in service), total downtime hours split by planned and unplanned, and the ratio of corrective to preventive work in both count and cost.
A caution about MTBF in particular: it is only meaningful when the calculation knows what counts as a failure. If every minor adjustment is raised as a corrective work order, MTBF collapses and looks alarming; if technicians fix things without raising orders, MTBF looks wonderful and is fiction. Decide up front which work order types represent a genuine failure and be consistent. I usually treat corrective and breakdown types as failures and exclude inspection, calibration, and modification types from the reliability calculation.
Run the calculation for a rolling twelve months and again for the last quarter. The comparison between the two intervals is more useful than either figure alone: an asset whose quarterly MTBF is half its annual MTBF is deteriorating right now, regardless of how good its history looks.
COUNTERS AND CONDITION ASSESSMENTS ADD THE LEADING INDICATORS
Everything above is lagging data: it tells you what already happened. Two features add a forward view. Asset counters, which I covered as triggers in the preventive maintenance article, also give you a usage denominator, so you can express cost per operating hour or per thousand cycles rather than per calendar month, and that is the fair way to compare a machine that runs three shifts against one that runs one. Condition assessments let you record a periodic inspection score against the asset, either from an inspection round or from a separate assessment record, and a declining condition score alongside a rising corrective cost is the earliest replacement signal you will get.
TURNING THE HISTORY INTO A REPLACE OR REPAIR DECISION
This is the part that justifies the whole data discipline. No single figure tells you to replace an asset, but three signals read together make the decision defensible.
• Cost trend: corrective cost per period is rising while the preventive baseline stays flat, and the cumulative maintenance cost is approaching a meaningful share of the replacement value.
• Reliability: MTBF is shortening over successive intervals, the fault history shows the same cause recurring, and MTTR is not improving despite the repeat exposure, which means the failures are not getting cheaper to fix.
• Downtime impact: unplanned downtime hours are concentrated on a functional location the production schedule cannot easily absorb. An unreliable asset on a redundant line is an annoyance; the same asset on a bottleneck is a business case.
The method I follow is simple. Pull the asset cost control for the last three years, add the cumulative corrective cost per year, and set it next to the replacement value and the expected annual cost of a new unit (typically the preventive forecast plus a small corrective allowance). When the corrective run rate plus the downtime cost exceeds the annualised cost of replacement, and the reliability trend says it is getting worse rather than stable, the decision writes itself. If the trend is stable, the honest answer is often to change the maintenance plan rather than the asset: shorten an interval, add a counter trigger, or change a spare part specification, and then watch the next quarter's KPIs.
CLOSING THE LOOP IN THE SYSTEM
Whatever you decide, record it. If you keep the asset, adjust the maintenance plan so the reliability data drives a real change rather than a meeting. If you replace it, use the asset lifecycle states to move the old asset through a decommissioning state rather than deleting it, so its history stays available for comparison against its successor, and create the new asset under the same functional location so the location's cost view stays continuous. The replace asset function handles swapping the installed asset while keeping the location and the plans intact. A year later, the new asset's KPIs against the old asset's final year are the proof of whether the decision was right, and that is the kind of evidence that turns maintenance from a cost centre into a function that can argue for its budget.
WHAT GOES WRONG
• Orders are not ended, so cost history lags reality and every trend is a step function instead of a curve.
• Fault codes are free text or too numerous, so nobody can answer whether a failure is a repeat.
• Downtime is never registered, so MTBF and availability calculate on an empty table and the KPI inquiry looks like the feature does not work.
• Failure definition is inconsistent across work order types, so MTBF compares assets on different rules.
• Assets are deleted at replacement instead of being moved to a retired lifecycle state, and the comparison that would justify the next replacement is lost.
Next time I will look at the link between asset management and production in more detail: how maintenance downtime and planned preventive stops feed resource capacity, how to connect assets to production resources, and how to keep the production scheduler and the maintenance planner working from the same calendar.
In this series: previous article Maintenance Work Orders in D365 Asset Management: Scheduling, Parts, Labour, and Cost
Every maintenance article I have written in this series ends at the same point: the work order is ended and the cost posts. In the work orders article I made the case that ending orders promptly is a discipline, not a formality, because the ledger only sees the cost at that moment. Today I want to follow that cost after it posts, because the whole reason to run maintenance through D365 instead of a spreadsheet is what the history lets you do afterwards: see what an asset has really cost over its life, see how often it fails and how long it stays down, and decide with numbers rather than instinct when it is time to stop repairing something and replace it.
WHERE THE COST GOES AFTER THE ORDER ENDS
Three cost types flow through a maintenance work order: labour hours priced at the worker's cost price, spare parts issued from inventory at their inventory cost, and expenses such as external services or vendor invoices attached to the order. While the order is open, these sit as posted journals against the work order. When the order is ended, D365 posts the ledger side and, just as importantly for this article, stamps the cost into the maintenance cost history of the asset the order was raised on.
That history is what the cost control inquiries read. Asset management offers cost control views at three levels: per asset, per functional location, and per work order. The asset view is the one I use most, because it lets you pick a period and see the split between hours, items, and expenses for one asset, and compare it against a budget if you have created one. The functional location view rolls up every asset installed underneath it, which is why I keep saying that the hierarchy you designed in the functional locations article is not just a filing system: it is your cost roll-up structure. If a packaging line is a functional location with six assets under it, the line's cost is one click, and it is correct without anyone building a report.
Two practical points here. First, cost history is only as good as the ending discipline: an asset with five open orders looks cheap until the month someone closes them all at once and the trend jumps. Second, if you move an asset between functional locations, the cost follows the asset, but the location roll-up changes from the move date onward. That is usually what you want, but it surprises people who compare a location's cost across a year in which equipment was shuffled.
BUDGETS GIVE THE NUMBERS SOMETHING TO BE COMPARED AGAINST
Cost on its own is a number without a verdict. Asset management lets you create maintenance budgets, either entered manually or generated from the maintenance forecast of your preventive plans, and then compare actual cost against the budget in the same cost control views. I recommend generating the budget from the forecast even when nobody has asked for budget reporting, for one reason: the forecast represents the planned, preventive side of your maintenance, so anything that lands above it is, by construction, unplanned. That gap between forecast and actual is the simplest reliability signal you can get out of the module without any further setup.
FAULT HISTORY: THE DATA YOU ONLY GET IF YOU ASK FOR IT
Cost tells you how much; faults tell you why. Asset management has a structured fault model with fault symptoms, fault areas, fault types, fault causes, and fault remedies, and you can register a fault on a maintenance request or on the work order itself. The registration is optional, which is precisely the problem. If technicians close orders with a free-text note saying "fixed bearing", you have no data. If they select a symptom (vibration), an area (drive end), a type (bearing failure), a cause (lubrication), and a remedy (replaced and greased), you have a dataset that answers the question every reliability engineer asks: is this the same failure coming back?
My advice on fault codes is to keep the lists short and asset-type specific. A fault designer with two hundred causes will be ignored on a mobile device at the end of a shift. Ten to fifteen well chosen causes per asset type, with an "other" option that a supervisor reviews weekly, produces far better data than an exhaustive taxonomy nobody uses. Link the fault types to asset types so the technician only sees relevant choices.
DOWNTIME REGISTRATION AND WHAT IT UNLOCKS
Downtime is the third dataset, and it is the one production management actually cares about. Asset management lets you register asset downtime with a start and end time and a downtime reason code, and it distinguishes between downtime that was planned (the preventive stop you scheduled) and downtime that was not. Register it against the asset, and it becomes available both for the KPI calculations and for the production side, because a downtime period on an asset that is linked to a production resource can reduce the resource's available capacity.
• Register unplanned downtime from the maintenance request or the work order the moment the asset stops, not when the paperwork is done.
• Register planned downtime when you schedule the preventive order, so the production planner sees the outage in capacity before it happens.
• Keep downtime reason codes separate from fault causes: one describes why the asset was unavailable, the other describes what broke.
ASSET KPIS: MTBF, MTTR, AND AVAILABILITY OUT OF THE BOX
With cost, faults, and downtime registered, the module can calculate asset KPIs for you. The calculation is run as a periodic job over a date interval for a selection of assets, functional locations, or asset types, and it produces a KPI record you can inquire on and compare across assets. The figures I look at are mean time between failures (the average operating time between corrective events), mean time to repair (how long a corrective order typically takes from the fault to the asset being back in service), total downtime hours split by planned and unplanned, and the ratio of corrective to preventive work in both count and cost.
A caution about MTBF in particular: it is only meaningful when the calculation knows what counts as a failure. If every minor adjustment is raised as a corrective work order, MTBF collapses and looks alarming; if technicians fix things without raising orders, MTBF looks wonderful and is fiction. Decide up front which work order types represent a genuine failure and be consistent. I usually treat corrective and breakdown types as failures and exclude inspection, calibration, and modification types from the reliability calculation.
Run the calculation for a rolling twelve months and again for the last quarter. The comparison between the two intervals is more useful than either figure alone: an asset whose quarterly MTBF is half its annual MTBF is deteriorating right now, regardless of how good its history looks.
COUNTERS AND CONDITION ASSESSMENTS ADD THE LEADING INDICATORS
Everything above is lagging data: it tells you what already happened. Two features add a forward view. Asset counters, which I covered as triggers in the preventive maintenance article, also give you a usage denominator, so you can express cost per operating hour or per thousand cycles rather than per calendar month, and that is the fair way to compare a machine that runs three shifts against one that runs one. Condition assessments let you record a periodic inspection score against the asset, either from an inspection round or from a separate assessment record, and a declining condition score alongside a rising corrective cost is the earliest replacement signal you will get.
TURNING THE HISTORY INTO A REPLACE OR REPAIR DECISION
This is the part that justifies the whole data discipline. No single figure tells you to replace an asset, but three signals read together make the decision defensible.
• Cost trend: corrective cost per period is rising while the preventive baseline stays flat, and the cumulative maintenance cost is approaching a meaningful share of the replacement value.
• Reliability: MTBF is shortening over successive intervals, the fault history shows the same cause recurring, and MTTR is not improving despite the repeat exposure, which means the failures are not getting cheaper to fix.
• Downtime impact: unplanned downtime hours are concentrated on a functional location the production schedule cannot easily absorb. An unreliable asset on a redundant line is an annoyance; the same asset on a bottleneck is a business case.
The method I follow is simple. Pull the asset cost control for the last three years, add the cumulative corrective cost per year, and set it next to the replacement value and the expected annual cost of a new unit (typically the preventive forecast plus a small corrective allowance). When the corrective run rate plus the downtime cost exceeds the annualised cost of replacement, and the reliability trend says it is getting worse rather than stable, the decision writes itself. If the trend is stable, the honest answer is often to change the maintenance plan rather than the asset: shorten an interval, add a counter trigger, or change a spare part specification, and then watch the next quarter's KPIs.
CLOSING THE LOOP IN THE SYSTEM
Whatever you decide, record it. If you keep the asset, adjust the maintenance plan so the reliability data drives a real change rather than a meeting. If you replace it, use the asset lifecycle states to move the old asset through a decommissioning state rather than deleting it, so its history stays available for comparison against its successor, and create the new asset under the same functional location so the location's cost view stays continuous. The replace asset function handles swapping the installed asset while keeping the location and the plans intact. A year later, the new asset's KPIs against the old asset's final year are the proof of whether the decision was right, and that is the kind of evidence that turns maintenance from a cost centre into a function that can argue for its budget.
WHAT GOES WRONG
• Orders are not ended, so cost history lags reality and every trend is a step function instead of a curve.
• Fault codes are free text or too numerous, so nobody can answer whether a failure is a repeat.
• Downtime is never registered, so MTBF and availability calculate on an empty table and the KPI inquiry looks like the feature does not work.
• Failure definition is inconsistent across work order types, so MTBF compares assets on different rules.
• Assets are deleted at replacement instead of being moved to a retired lifecycle state, and the comparison that would justify the next replacement is lost.
Next time I will look at the link between asset management and production in more detail: how maintenance downtime and planned preventive stops feed resource capacity, how to connect assets to production resources, and how to keep the production scheduler and the maintenance planner working from the same calendar.
In this series: previous article Maintenance Work Orders in D365 Asset Management: Scheduling, Parts, Labour, and Cost
No comments yet. Be the first to comment!
