Simplify Complexity with Asset Management in Dynamics 365 Finance and Supply Chain
Benefits of Formal Asset Management
Asset Management is a set of tools in Dynamics 365 Finance and Supply Chain to allow users to plan and track costs and history for individual assets deeply integrated to all the domains of ERP. Companies with very limited maintenance budgets, and few critical units of equipment can sometimes get by without Asset Management disciplines by deploying workarounds and back-office gymnastics in accounting. Where the assets are crucial to schedule, margin, and quality of application in production or project the solution must support a maintenance team and the data they need to for efficient operations at many levels. To be accountable for asset availability and efficiency, these teams need event-driven planned and ad hoc work orders and the cost history to keep the efforts of maintenance visible and prioritized.
Asset Structure in D365 Finance & Supply Chain
One key feature in asset management which provides leverage to the maintenance team productivity is the multi-level structure of assets. Just as a product might have a bill of material to define it, a productive asset may require “Child” assets to support operational and maintenance outcomes.
Whether the asset child is part of a unit procured as one unit, or we build proprietary equipment of our own design or customization, the asset hierarchy separates the cost and maintenance streams in valuable ways.
The decision to structure equipment assets to a child level is critical to a good deployment of asset management, although it is also possible to add levels of asset structure at a later phase of implementation. An important feature of a well-designed asset management solution is the flexibility to add features as and when the teams and data are prepared to deploy them.
For the following example, we use a pump which is integral to many types of equipment in numerous industries. Most pumps are manufactured by specialized vendors and selected for the design of equipment instead of designed and built by the main asset OEM’s:
The parent unit (firetruck) we buy might last twenty years of effective life, and the pump may have a life of three years to retire or rebuild. Since pumps can be expensive, they may deserve their own fixed asset value, and we may keep copies on hand for prompt replacement. The parent unit may have a warranty for its chassis and vehicle features, but the pump is warranted only by the pump manufacturer with different timing and coverage.
Some of this can be handled by spare pump items in spreadsheets, inventory, and/or fixed assets in ERP. If we wish the fleet of pumps to be visible in the right condition we must track more specific data and organize it. We may define the pump as a child asset under the firetruck parent. These details include:
- Tracking and analyzing cost activities to the fleet of pumps is important to understanding the overall cost of the fleet or firetrucks. If the repair and preventive costs are booked to the parent firetruck, instead of the specific pump, the analysis of pump costs and history is blinded.
- Warranty tracking/covenant – the acquisition date, and the nature of the warranty might be important and may be different between serial numbers of the same pump design but different commercial arrangements. The vendor may need to be able to see the maintenance executed on the pump to validate the warranty.
- Planned Maintenance – asset management allows the user to attach to each unit upkeep tasks which are to be executed based on calendar or based on quantitative counters registered for the unit. The pump may require to be lubricated at every fifty hours of use. That counter may not be applicable to the firetruck as a whole. The pump child must retain both the counters history and the maintenance executed on that child unit along with the costs wherever the child pump is assigned throughout its life.
- Predictive and Preventive maintenance – Hosted locally, or by a service contractor, dealer, or OEM the dataset must have specific unit identities and data in order to recommend artificial intelligence-based actions based on the inputs of telematics and counters along with other data from ERP.
- Counters for analysis – counters (mentioned in the planned maintenance discussion above) are also useful for the analysis of lifecycles of the pumps. Hours, material volume pumped, temperature readings, failures, etc. are all important statistics for critical KPIs. For many types of equipment, the manufacturer or dealer may offer remote telematics or support which is not applicable to the parent, but is related to the child specifically, and must move with the child whether mounted on a different truck, parked in a depot, or out for renovation.
- Faults – Symptoms, causes, and remedies can be tracked for every unique asset to assist in supporting a knowledge base and reporting KPIs. The reporting codes for a pump will be different from the reporting codes for the truck.
- Admin Maintenance/data – some assets or children require activities that are not physical maintenance, but administrative in nature. These include elements such as RFID tag identity, license, calibration history, classification for regulatory reporting, etc. the child unit is the identity for some of these demands throughout its lifecycle
- Parent associations – Child Assets that are candidates for rebuild have numerous lives. The data for a unit that has been mounted on more than one parent and costs spread over the timing of those parents must have its own identity to ensure visibility of costs, maintenance, and investment events along with the counters of the entire life of the unit. For reporting purposes, the parent history and counters must also be kept up to date.
- Specification attributes – Attributes allow us to make specific data relations to the asset to include anything necessary for differentiation: VIN, tested output, small but not trivial attributes like left-hand or right-hand drive, dealer purchased/rented from, model, and year details to assist with maintenance support, etc. These can be defined as required. Attributes can be added as required without any software change.
- Attachment documents and other files affiliated to the specific unit or the type of unit of the child: maintenance diagrams, approved parts, procedures, damage photos, user training guides, etc.
- Condition assessment – inspection observations collected for the child … history moves with the unit
This commentary does not address “attachments” which are related accessories that might be critical to accomplishing work but can also be left at the depot when not needed. A good example of this is the respiratory gear used by firefighters which may be affiliated to the firetruck in the varying count of copies, or assigned to another support vehicle. Although mission-critical to firefighting, the affiliation to the truck is not fixed. “Asset-Children” are almost always permanent and required components or subsystems. Asset Children are onboard sub-systems inherent in making the unit productive such as an engine, or an actuator. Asset attachments may require tracking, cost control, and more, but are not part of operating the parent by necessity.
Scorecard for Asset Hierarchy choices:
(200 points suggests identifying the assets uniquely as children)
90 pt. Cost of Repair/Maintenance assigned to the specific child
80 pt. Reporting across many instances of a “type”
80 pt. Status – Lifecycle definition
90 pt. Renovation lifecycle Via investment Work Order
70 pt. Counters / Meters for analysis Move with history
70 pt. Planned Maintenance Routine based on time or counters
70 pt. Map to Fixed Asset to accommodate differentiated depreciation, acquisition costs, and retirement appraisal
60 pt. Warranty tracking/covenant
60 pt. Direct record of symptom / fault / remedy tracking
40 pt. Application of costs to precise COGS/project/overhead accounts
50 pt. OEM data and services connection
40 pt. Specification attributes
40 pt. Location/store/spare : View of Branch / Depot / Site / Yard