Asset Management in D365 SCM: Functional Locations, Assets, and the Maintenance Foundation
I am stepping sideways from master planning for a few articles, at Joni's request, into a corner of Dynamics 365 Supply Chain Management that production-heavy shops lean on but that gets far less airtime than manufacturing or warehousing: Asset Management, the module Microsoft used to call Enterprise Asset Management. If you run lines, presses, ovens, conveyors, or any equipment that has to keep running, this is where Dynamics 365 tracks what you own, where it sits, what condition it is in, and the maintenance work that keeps it alive. This first article lays the foundation, the structure everything else hangs from, because almost every problem I see in an Asset Management rollout traces back to the structure being rushed.
WHY ASSET MANAGEMENT EARNS ITS PLACE
Maintenance is the quiet partner of production. A finite-capacity schedule is only honest if the resources it schedules are actually available, and a resource that is down for an unplanned repair makes a liar of the plan. Asset Management gives you a structured way to record assets, plan preventive maintenance so failures happen less often, capture corrective work when they happen anyway, and post the cost of all that work where finance can see it. It is fully inside Supply Chain Management rather than bolted on, so a maintenance asset can be tied to the same resource your production orders consume, and the maintenance work order can draw spare parts from the same inventory your shop floor draws from. That integration is the reason to use it instead of a standalone CMMS, and it is also why getting the structure right matters: the structure is what connects maintenance to the rest of the system.
THE ASSET HIERARCHY: FUNCTIONAL LOCATIONS AND ASSETS
There are two foundational objects, and people constantly blur them. A functional location is a place in your operation where an asset can sit: a site, an area, a production line, a cell, a room. Functional locations are arranged in a parent and child hierarchy, so a line sits under an area, which sits under a site. An asset is the physical thing itself: the specific pump, the specific press, the specific forklift. The asset is installed at a functional location, and that relationship is the hinge of the whole module.
The reason to separate the two is that places outlast equipment. A pump fails for good and you replace it; the slot on the line where it lived does not change. If you have built your history around the functional location, you can ask "how much has this position on the line cost me over five years" across every asset that has ever occupied it, and you can swap the physical asset in and out without losing that thread. Build everything around the asset alone and you lose continuity every time you replace a machine. So I model the places first, as a stable skeleton, and then install assets into them.
Two settings shape the skeleton. A functional location type classifies what kind of place each node is, and the functional location structure defines which types are allowed to sit under which, so the hierarchy stays consistent instead of becoming a free-for-all. Spend time here. A clean, shallow, consistent structure is a pleasure to report on for years; a sprawling inconsistent one is a permanent tax on every query you ever write.
ASSET TYPES, MANUFACTURERS, AND MODELS
Every asset carries an asset type, and the asset type is doing more work than it appears. It groups assets that behave alike (all the forklifts, all the hydraulic presses) and it is the level at which a lot of downstream setup is defaulted: which maintenance job types apply, which counters are relevant, which preventive plans make sense. Get the asset type taxonomy wrong and you will be overriding things asset by asset forever, which defeats the point. Manufacturer and model are descriptive attributes underneath that, useful for spares commonality and for spotting that a particular model fails more than its neighbours. My rule of thumb is that asset type answers "how do we maintain this category" while model answers "what exactly is it"; keep those two questions separate and the taxonomy stays clean.
MAINTENANCE JOB TYPES AND THE WORK THAT FLOWS
Maintenance work in Dynamics 365 comes in through two doors. Preventive work is generated ahead of time from maintenance plans and maintenance rounds, time-based or counter-based, so an inspection or a service is raised before anything breaks. Corrective work starts with a maintenance request, which is the structured way someone says "this is wrong, please look at it." Both doors lead to the same place: a maintenance work order, which is scheduled, executed, and then ended, at which point its cost is posted.
The job type is the vocabulary that keeps this consistent. A maintenance job type names the kind of task (inspection, lubrication, replacement, calibration) and a job type category groups those into preventive versus corrective for reporting. The discipline that pays off later is consistency: if "inspection" is one job type used the same way everywhere, your history is analysable; if every technician invents their own wording, it is noise. So I treat the job type list as a controlled vocabulary, agreed once, and resist the temptation to let it grow uncontrolled.
The work order lifecycle itself moves through states: created, scheduled, in progress, completed, and finally ended. Two of those transitions matter more than the rest. Scheduling is where the work order meets capacity, the maintenance worker and the asset's own availability, and this is exactly where Asset Management touches the same scheduling concepts I have written about on the production side. Ending the work order is the financial event: that is when the labour, the items consumed, and any other costs are posted and the maintenance history is sealed. Leave work orders sitting completed but not ended and your maintenance cost reporting will quietly understate reality, because the cost has not actually landed yet.
LIFECYCLE STATES ON THE ASSET ITSELF
Beyond the work order, both functional locations and assets carry their own lifecycle states and lifecycle models, which control what you are allowed to do with them and when. An asset that is not yet in an active state should not be accumulating maintenance work; an asset being decommissioned should stop attracting new work but keep its history. The lifecycle model is simply the set of allowed states and the transitions between them, and it is worth configuring deliberately rather than accepting a default, because it is your guardrail against, for example, scheduling expensive preventive work against equipment that has already left the floor.
WHAT GOES WRONG
• Modelling assets without modelling places. Skip functional locations and you tie all history to equipment that gets replaced, so you lose the long-run view of each position. Build the location skeleton first.
• An asset type taxonomy that is too fine or too coarse. Too fine and nothing defaults cleanly; too coarse and unlike equipment shares settings it should not. Group by how things are maintained, not by what they are called.
• A free-for-all job type list. When every technician invents wording, maintenance history becomes unsearchable. Agree a controlled vocabulary once and hold the line.
• Work orders completed but never ended. Cost only posts at ending, so unended orders make maintenance spend look lower than it is. Close the loop.
• Ignoring lifecycle states. Without them you can raise work against assets that are not commissioned or already retired, which pollutes both the schedule and the numbers. Configure the lifecycle model on purpose.
TAKEAWAYS
Asset Management rewards the same instinct as the rest of Supply Chain Management: settle the structure before you chase the features. Model your places as a stable functional location hierarchy, governed by location types and a structure, then install assets into them so history follows the position and not just the machine. Classify assets by how they are maintained through a disciplined asset type taxonomy, and treat maintenance job types as a controlled vocabulary so the history is worth reading. Understand that preventive and corrective work both converge on the work order, and that the work order only becomes a financial fact when it is ended. Get those foundations right and everything that comes next, the preventive plans, the scheduling, the spare-parts integration, the cost analysis, has solid ground to stand on.
Next time I will go a level deeper into the preventive side: maintenance plans and maintenance rounds, how time-based and counter-based triggers actually generate the forecast of work, and how to keep that forecast from either flooding your technicians or going quiet.
In this series: previous article The Master Plan in D365: Static vs Dynamic Plans and Why You Run Two
I am stepping sideways from master planning for a few articles, at Joni's request, into a corner of Dynamics 365 Supply Chain Management that production-heavy shops lean on but that gets far less airtime than manufacturing or warehousing: Asset Management, the module Microsoft used to call Enterprise Asset Management. If you run lines, presses, ovens, conveyors, or any equipment that has to keep running, this is where Dynamics 365 tracks what you own, where it sits, what condition it is in, and the maintenance work that keeps it alive. This first article lays the foundation, the structure everything else hangs from, because almost every problem I see in an Asset Management rollout traces back to the structure being rushed.
WHY ASSET MANAGEMENT EARNS ITS PLACE
Maintenance is the quiet partner of production. A finite-capacity schedule is only honest if the resources it schedules are actually available, and a resource that is down for an unplanned repair makes a liar of the plan. Asset Management gives you a structured way to record assets, plan preventive maintenance so failures happen less often, capture corrective work when they happen anyway, and post the cost of all that work where finance can see it. It is fully inside Supply Chain Management rather than bolted on, so a maintenance asset can be tied to the same resource your production orders consume, and the maintenance work order can draw spare parts from the same inventory your shop floor draws from. That integration is the reason to use it instead of a standalone CMMS, and it is also why getting the structure right matters: the structure is what connects maintenance to the rest of the system.
THE ASSET HIERARCHY: FUNCTIONAL LOCATIONS AND ASSETS
There are two foundational objects, and people constantly blur them. A functional location is a place in your operation where an asset can sit: a site, an area, a production line, a cell, a room. Functional locations are arranged in a parent and child hierarchy, so a line sits under an area, which sits under a site. An asset is the physical thing itself: the specific pump, the specific press, the specific forklift. The asset is installed at a functional location, and that relationship is the hinge of the whole module.
The reason to separate the two is that places outlast equipment. A pump fails for good and you replace it; the slot on the line where it lived does not change. If you have built your history around the functional location, you can ask "how much has this position on the line cost me over five years" across every asset that has ever occupied it, and you can swap the physical asset in and out without losing that thread. Build everything around the asset alone and you lose continuity every time you replace a machine. So I model the places first, as a stable skeleton, and then install assets into them.
Two settings shape the skeleton. A functional location type classifies what kind of place each node is, and the functional location structure defines which types are allowed to sit under which, so the hierarchy stays consistent instead of becoming a free-for-all. Spend time here. A clean, shallow, consistent structure is a pleasure to report on for years; a sprawling inconsistent one is a permanent tax on every query you ever write.
ASSET TYPES, MANUFACTURERS, AND MODELS
Every asset carries an asset type, and the asset type is doing more work than it appears. It groups assets that behave alike (all the forklifts, all the hydraulic presses) and it is the level at which a lot of downstream setup is defaulted: which maintenance job types apply, which counters are relevant, which preventive plans make sense. Get the asset type taxonomy wrong and you will be overriding things asset by asset forever, which defeats the point. Manufacturer and model are descriptive attributes underneath that, useful for spares commonality and for spotting that a particular model fails more than its neighbours. My rule of thumb is that asset type answers "how do we maintain this category" while model answers "what exactly is it"; keep those two questions separate and the taxonomy stays clean.
MAINTENANCE JOB TYPES AND THE WORK THAT FLOWS
Maintenance work in Dynamics 365 comes in through two doors. Preventive work is generated ahead of time from maintenance plans and maintenance rounds, time-based or counter-based, so an inspection or a service is raised before anything breaks. Corrective work starts with a maintenance request, which is the structured way someone says "this is wrong, please look at it." Both doors lead to the same place: a maintenance work order, which is scheduled, executed, and then ended, at which point its cost is posted.
The job type is the vocabulary that keeps this consistent. A maintenance job type names the kind of task (inspection, lubrication, replacement, calibration) and a job type category groups those into preventive versus corrective for reporting. The discipline that pays off later is consistency: if "inspection" is one job type used the same way everywhere, your history is analysable; if every technician invents their own wording, it is noise. So I treat the job type list as a controlled vocabulary, agreed once, and resist the temptation to let it grow uncontrolled.
The work order lifecycle itself moves through states: created, scheduled, in progress, completed, and finally ended. Two of those transitions matter more than the rest. Scheduling is where the work order meets capacity, the maintenance worker and the asset's own availability, and this is exactly where Asset Management touches the same scheduling concepts I have written about on the production side. Ending the work order is the financial event: that is when the labour, the items consumed, and any other costs are posted and the maintenance history is sealed. Leave work orders sitting completed but not ended and your maintenance cost reporting will quietly understate reality, because the cost has not actually landed yet.
LIFECYCLE STATES ON THE ASSET ITSELF
Beyond the work order, both functional locations and assets carry their own lifecycle states and lifecycle models, which control what you are allowed to do with them and when. An asset that is not yet in an active state should not be accumulating maintenance work; an asset being decommissioned should stop attracting new work but keep its history. The lifecycle model is simply the set of allowed states and the transitions between them, and it is worth configuring deliberately rather than accepting a default, because it is your guardrail against, for example, scheduling expensive preventive work against equipment that has already left the floor.
WHAT GOES WRONG
• Modelling assets without modelling places. Skip functional locations and you tie all history to equipment that gets replaced, so you lose the long-run view of each position. Build the location skeleton first.
• An asset type taxonomy that is too fine or too coarse. Too fine and nothing defaults cleanly; too coarse and unlike equipment shares settings it should not. Group by how things are maintained, not by what they are called.
• A free-for-all job type list. When every technician invents wording, maintenance history becomes unsearchable. Agree a controlled vocabulary once and hold the line.
• Work orders completed but never ended. Cost only posts at ending, so unended orders make maintenance spend look lower than it is. Close the loop.
• Ignoring lifecycle states. Without them you can raise work against assets that are not commissioned or already retired, which pollutes both the schedule and the numbers. Configure the lifecycle model on purpose.
TAKEAWAYS
Asset Management rewards the same instinct as the rest of Supply Chain Management: settle the structure before you chase the features. Model your places as a stable functional location hierarchy, governed by location types and a structure, then install assets into them so history follows the position and not just the machine. Classify assets by how they are maintained through a disciplined asset type taxonomy, and treat maintenance job types as a controlled vocabulary so the history is worth reading. Understand that preventive and corrective work both converge on the work order, and that the work order only becomes a financial fact when it is ended. Get those foundations right and everything that comes next, the preventive plans, the scheduling, the spare-parts integration, the cost analysis, has solid ground to stand on.
Next time I will go a level deeper into the preventive side: maintenance plans and maintenance rounds, how time-based and counter-based triggers actually generate the forecast of work, and how to keep that forecast from either flooding your technicians or going quiet.
In this series: previous article The Master Plan in D365: Static vs Dynamic Plans and Why You Run Two
No replies yet. Be the first to respond!
