EAM

Enterprise Asset Management

Definition

EAM (Enterprise Asset Management) is used to manage the purchase, depreciation, maintenance, and disposal of enterprise fixed assets. The Asset Management in Device Management Platform can integrate with EAM and ERP to achieve bidirectional synchronization of device asset data.

Core Functions

EAM covers asset ledger, procurement and warehousing, depreciation accounting, maintenance planning, maintenance history, spare parts management, and disposal. Compared with CMMS, EAM focuses on the full lifecycle of assets and the financial perspective, while CMMS focuses on maintenance execution and work order processes; the two are often integrated.

Integration with DMP

The Device Management Platform synchronizes equipment registration information, Connection Status connection status, Device Health Score health score, OTA records, fault alarms, etc., to EAM, enriching the asset operational view. Asset master data, location, and responsible personnel in EAM can be written back to the platform, achieving a one-to-one mapping between devices and assets, supporting asset utilization analysis, idle identification, and replacement decisions.

Application Value

Achieves the integration of "Asset—Device—Data," meeting multiple requirements for financial depreciation, compliance audits, and operation and maintenance decisions. Suitable for enterprises in energy, manufacturing, transportation, and other sectors with a large number of IoT devices, enhancing asset visibility and management efficiency through the integration of EAM and DMP.

How the financial ledger and operating data line up

In device management, enterprise asset management means recording a fixed asset, from the financial and physical point of view, through acquisition, depreciation, location, maintenance, and disposal, and matching it to the terminal that can connect. The asset system cares about original value, depreciation, and ownership. The device platform cares about identity, connection, upgrade, and faults. The key to lining the two sides up is not copying every field across. It is one stable asset number pointing at one stable device identifier. When a communication module is replaced or credentials are issued again, the asset number stays. When an asset is split or transferred, the project and location on the device platform have to follow. Without that correspondence, operating data cannot say which asset produced them, and depreciation cannot exclude a terminal that is no longer on site.

This connection fits when both the asset card and the device record already exist, and the site allows the same number to be labeled or entered. A prototype that is only a device, and does not yet have an asset card, should not have financial data invented for the sake of synchronization. The direction of synchronization has to be split. Asset number, responsible organization, and the disposal decision go from the asset system to the device platform. Connection, faults, and upgrade history go from the device platform to the asset system. When this conflicts with the device lifecycle, the disposal decision says whether it may still be put in service, and the device platform carries out whether it can still connect. Relative to a work order, repair cost may return to this asset card, but closing the order does not mean the asset has been disposed of or fully depreciated.

Asset numbers and device identifiers used apart

A common mistake is an asset number assigned by purchase batch and a device identifier assigned by connection account, with no mapping table in between, so matching can only be a fuzzy match on the name. Once the name changes, historical cost hangs on the wrong object. Another is one gateway with many child devices, and only one asset card for the gateway, so every child-device fault is recorded on the gateway. Or the reverse: every sensor has its own card, and when the gateway is replaced dozens of cards lose connection at once with no parent-child relationship. Depreciation still calculated as in service, while the device has in fact been disposed of but is still online, leaves finance and the site each holding their own account.

One-way synchronization loses the write-back. The device platform updates the install location, and the next full overwrite from the asset system writes the old location back. A named field should have a named source, rather than whole records covering each other. An asset already disposed of, if the device platform is not told to disable credentials, keeps producing new operating records and looks as if the asset has come back. When matching fails, keep an unmatched list. Rows that do not match must not be dropped silently. Spaces, case, and leading zeros in numbers should be normalized on import. Otherwise the same card splits into two rows, and depreciation and maintenance are each recorded on half.

Do not crowd a gateway and its child devices onto one card

The granularity of an asset card has to be decided in advance. When a gateway has many probes that cannot be valued on their own, there may be only one card for the gateway, but faults and replacements must be recordable against the specific probe. They must not all be written as the gateway itself having failed. When probes are valued and depreciated on their own, each should have its own card, and the card should say which gateway it depends on. After the gateway is replaced, the connection relationship of those cards has to follow. They must not all become offline assets of unknown origin. The two granularities cannot be mixed in the same synchronization, or some objects are skipped and some are depreciated twice. A financial disposal decision says whether the device may still be put in service. The device platform is responsible for carrying out the disable. Closing a work order only means this repair has ended. It does not mean the asset has been disposed of or fully depreciated.

Synchronization must not overwrite a whole row in either direction. If the device platform updates the install location, and the asset system writes back an old full record, the location is changed back. Agree which side is the source for each field. Numbers that do not match should stay on an unmatched list. They must not be dropped silently. Spaces, case, and leading zeros in numbers should be cleaned by the same rule on import. Otherwise the same card splits into two rows, and cost and history are each recorded on half. A disposed asset, if the device platform is not told to disable credentials, keeps reporting and looks as if an asset already written off has returned to the site. The aim of the match is to point the financial object and the connectable object at the same physical thing, not to copy the two databases until they are the same size.

Related Terms

Return to Device Management Platform terminology