Dynamics 365 Supply Chain Management, Asset Management (Part 1)

In this first part of the series on Asset Management (AM) in Dynamics 365 Supply Chain Management (D365SCM), we will take a look at how master data is structured and configured, but before we got into this, I would like to briefly discuss the purpose of the module and its capabilities.

Purpose of Asset Management

What is the purpose of AM? Companies generally invest large sums in assets such as buildings, plant machinery and IT equipment. To keep these assets in working order and to retain maximum value, the asset must be maintained.

This is simply the purpose of Asset Management: maintaining company assets.

Some companies also maintain other companies’ assets, but this is not the purpose of AM in D365SCM – for this you need Dynamics 365 Field Service.

AM is often divided into three distinct disciplines:

1. Break-Fix (something has gone awry, fix it).
2. Preventive (based on usage or time, an asset is maintained before it breaks).
3. Predictive (based on data points we are able to predict when an asset will break).

At this stage, Asset Management supports break-fix and preventive maintenance.

Capabilities

The following figure shows an overview of the capabilities available in the AM module.

Here is a brief description of each capability:

ASSET MANAGEMENT: The module is centered around the concept of a physical asset. An asset can be hierarchical and is always installed in a so-called functional location. We will explore asset management in detail later in this blog post.

REQUEST MANAGEMENT: If an asset fails or needs general maintenance, users can raise a maintenance request. The request contains information about the fault and is routed to an Asset Manager, who validates the request. If relevant, the Asset Manager creates a work order to remedy the problem and puts it into the maintenance schedule.

WORK ORDER MANAGEMENT: The work order is the central component in carrying out maintenance work whether the maintenance is preventive or break-fix. Based on pre-configured scheduling parameters, the work order is routed to a Field Service Technician. A work order can contain multiple jobs and can be worked on from a mobile device.

SCHEDULING: The ability to schedule work order jobs based on predefined factors such as priority, worker availability, worker skills, service level etc.

SPARE PARTS TRACKING: When performing maintenance on an asset, the Field Service Technician can record parts consumption. This can be tracked and used to update the asset bill of materials.

CONSUMPTION: As maintenance work is performed, the Field Service Technician or Asset Clerk can record time, parts and other expenses against the work order.

KPIs: The system automatically calculates a range of KPIs including:

• Total Up-time.
• Total Downtime.
• Total Repair Time.
• Availability %.
• Number of Faults.
• Meantime Between Faults (MTBF).

COST CONTROL: All costs related to maintenance can be budgeted and recorded. The AM module has a Cost Control real-time inquiry that allows asset controllers to perform multi-dimensional analysis of budgets and costs.

FAULT MANAGEMENT: Through a matrix approach, the system can be configured to suggest a remedy to a fault. Fault details are recorded for further analysis.

PREVENTIVE MAINTENANCE: In addition to break-fix maintenance, the system supports maintenance plans and maintenance rounds. Both types allow automated creation of work orders based on pre-set maintenance schedules. We will look at plans and round in more details in a later part of this series.

Module Integration

Since AM is part of Dynamics 365 for Finance and Operations (D365F&O) it seamlessly integrates with other modules. We will look at this in more detail later in the series, but here is a brief list of the modules integrated with AM:

• Project Management and Accounting.
• Inventory Management.
• Procurement and Sourcing.
• Fixed Assets.

Master Data Structure

As mentioned earlier, in this part of the series, we will focus mainly on structure and master data. These topics will be explored in the following subsections.

Functional Locations

Imagine a factory. In that factory you have multiple production lines and each production lines consists of a number of work cells. This hierarchy is illustrated in the following figure.

Each part of this hierarchy is a functional location.

An asset is installed in a functional location.

This is important because this allows us to:

• Perform maintenance on (multiple) assets in a specific location.
• Assign workers to specific locations.
• Default information on new assets and work orders based on functional location.

In addition, functional locations can be used to filter reports and analyses.

Assets

Obviously, the core component of AM is the asset. An asset is a system representation of a specific physical asset and contains data to describe the asset including:

• Description.
• Manufacturer.
• Model.
• Serial number.
• Attributes (more on those later).
• Warranty information.
• Condition.
• Financial dimensions.

Assets can be linked together in a hierarchical structure. The following screenshot shows the asset hierarchy for the “EX-101 Extruder line 1”:

As you can see, the “EX-101” asset consists of five sub assets.

You can read more on the structure of functional locations and assets here.

Life Cycle State

A common (and very important) concept in AM is the life cycle state. Both functional locations and assets have a life cycle state attribute. The life cycle state describes where the functional location or asset is in its life cycle. It also determines what can be done to the object.

The above screenshot shows the configuration for asset life cycle state. As the example shows, the “New” state does not have the Active field ticked. This means that assets with life cycle state = “New” are not active and maintenance can not be carried out on them.

Life cycle states are governed in a life cycle model. The following figure shows an example of a life cycle model for assets.

The life cycle model determines the states an asset can go through and the sequence.

Similar life cycle models and states can be configured for:

• Functional locations.
• Work orders.
• Maintenance requests.

Summary

So to recap; assets are the key master data component in the asset module. Maintenance is carried out on the asset and assets are installed in functional locations. Both functional locations and assets can be structured in hierarchies.

Both functional locations and assets are governed by life cycle models consisting of a configurable set of life cycle states.

Mandatory Configuration

In addition to the life cycle model and life cycle states, some additional basic configuration is required for functional locations and assets.

Functional Location Types

When creating a new functional location, the user must select the functional location type. The functional location type controls a number of things including:

• Can multiple assets be installed in the location?
• What types of asset are allowed in the location.

Asset Types

Similarly, the user must select an asset type when creating a new asset type. Asset types are significantly more complex than functional location types, so please refer to the documentation for more details.

Optional Configuration

In addition to the mandatory configuration, some optional configuration is useful.

Counters

An asset can be associated with one or more counters. The counters are used to schedule preventive maintenance. The asset types determines which counters are allowed for an asset. In a future part of the series, we look at how counters are used in preventive maintenance and how counters can be updated automatically or manually.

Attribute Types

Since assets come in many varieties describing them in a simple master data record is not possible. Instead, an asset can be described in detail through attributes. An attribute on an asset is based on an attribute type. The following screenshot shows examples of attribute types.

Please note that attribute types can have different data types.

The asset type determines which attributes types are available on an asset.

In a future part of this series we will look at how attributes can be used when installing an asset in a functional location.

Further Reading

The official Microsoft documentation for AM is available here.

Next Part in This Series

In the next part of this series, we will take a look at a break-fix end-to-end scenario using a mobile device.