Understanding the roles, functions, and relationships
One of the most common misunderstandings about ITSM is the difference between an asset and a configuration item (CI). The answer is: It’s complicated. Not all CIs can be qualified as assets, and not all assets are CIs. This is because the management of both is distinct and different.
Defining the Difference
To understand this relationship, we first need to define the difference between the two. An asset typically represents a tangible item managed by the company and usually incorporates the fiscal and procurement elements. When we talk about “lifecycle management,” we are referring to the asset – the requesting, ordering, invoicing, shipping, receiving, paying, imaging, deployment, lease vs. purchase, warranty, depreciation and retirement/end-of-life of the device
CIs, on the other hand, represent the technical details on the particular item, literally the “configuration.” They can be successfully managed via a configuration management database (CMDB). If an element of a device changes, say additional memory, that detail is noted in the CI record. From an ITIL perspective, incidents and problems are tracked against the CI record. That is, if a problem occurs, the user reports it, and an incident is created and tracked against the CI (not the asset), so that the appropriate person or department can perform repair or replacement against it.
Management is an important component, too, because if a fault occurs in a CI, significant disruption to an organization’s processes and procedures can result. Dependency mapping, that is, the depiction and management of elements upon which devices or services are interrelated and dependent on one another, are all maintained at the CI level.
IT asset management is the practice of managing assets across their entire life cycle. As such, part of implementing any asset management system should include the procurement processes described above. Most company resources (if not all) can be managed in this way, which can complicate the process if not properly administered. However, with procurement properly configured, the Asset/CI dilemma can be holistically addressed.
The Overlap: Assets and CIs
Your company server is a physical asset – its financial value can be known and tracked over its life cycle. At the same time, the server can also have a CI record within your CMDB, which would include details like software items or interactions with other servers on the network.
The point of implementing asset management is to manage lifecycle states from acquisition through retirement and to maximize cost benefits of the asset. Managers who successfully understand the overlap and the different asset management practices will realize the most value for their organization over time.
Problem Item: Orphan Assets
An “orphan” asset may be the result of one of the following:
A Discovery process that creates a CI automatically also creates a corresponding Asset, but the CI is then subsequently altered or deleted, and the corresponding asset is “disconnected”
An Asset is created through a manual process, but no corresponding CI is generated. When the actual CI is discovered, it either attempts no reconciliation with an asset, or (worse!) creates a duplicate asset.
An “orphan” asset lacks a relationship to the CMDB and the actual CI that it represents, therefore any changes that may occur against that CI would never be tracked.
Problem Item: Orphan CIs
An orphan CI may be the result of one of the following:
CI discovered and created but no Asset ever matched with it
A forced “manual” detachment of the CI from the Asset (rare)
While there may be legitimate times when a CI can exist without a corresponding asset (e.g., a peripheral, consumable, or non-tracked or non-serialized internal item such as a network interface), the orphaning of a CI from its original asset can be problematic for the same reasons noted above: the complete detail of the Asset / CI item relies on the successful synchronization of both records.
To gain a holistic view of the Asset/CI pairing, a recommended best practice would consist of the following scenario:
The asset is created as part of the procurement process. Ideally, this would occur with the processing of an Advanced Ship Notice (ASN), where the full procurement detail of the asset (cost, cost center, purchaser, etc.) is matched with a uniquely identifiable element of the asset (typically serial number).
When the asset is created, its corresponding CI is also automatically created, albeit with limited detail, and the identifiable element is matched.
As the asset progresses through its receipt and deployment phases, its state is continuously updated to reflect both its whereabouts and its current disposition.
Once the item is deployed, it is “discovered” through some automated scanning tool (e.g., Microsoft SCCM, SN Discovery).
The detail gleaned from the discovery process “enriches” the CI record with all pertinent CI detail (hardware configuration, installed software, IP address, etc.)
From this point forward, the Asset and CI pairing presents a complete picture of the item, marrying both fiscal and technical detail, along with tracking of any changes to either.
By reducing or eliminating the occurrences of “orphan” assets, the cost benefits of a CMDB can be measured and achieved. Successful IT Asset Management protocols will:
- Avoid instances of “orphan” (incomplete) assets
- Be able to quickly respond to audits
- Reduce or eliminate extraneous costs, e.g., paying for leased equipment that has already been returned
- Understand the role of the asset record and its corresponding CI record and managing synchronization between them; and
- Understand and manage the exception cases.
These protocols, along with a holistic view of the asset and configuration item pairing, will help you on your way to understanding the true different between an asset and a CI. Looking for even more information? Let Cask help.
Solutions Architect at Cask
Laurent brings over 35 years of IT experience to his projects. Beginning with network integrations and IT project management, he began specializing in IT Asset Management in 2000 and continues to build on the breadth and depth of that experience to design and manage solutions on the ServiceNow platform.