One of the most common misunderstandings about ITSM is the difference between an asset and a configuration item (CI).
And that’s understandable. After all, ITSM toolsets store assets and CIs in exactly the same way: they’re stored in the same place, with the same relationship options.
But, and this is crucial, they aren’t the same thing. And if you try to treat them as though they are the same, you’ll wind up wasting a lot of time and resources.
Why Draw a Distinction?
It’s important to realise that, since assets and CIs are stored in the same way, the difference is almost entirely arbitrary. As far as your ITSM toolset is concerned there’s no difference between the two, which leaves you in charge of determining the difference.
But why draw a distinction at all? If they’re stored in the same way, why not simply treat assets and CIs as the same thing?
Simple: If do treat them the same, you’ll wind up wasting a huge amount of time, which in all probability means your ITSM toolset will never function the way you intended.
Let’s imagine your organisation has a total of 8,000 devices, which will be stored in your ITSM toolset as either assets or CIs. Of those, 7,500 are workstation devices such as PCs, laptops, printers, smartphones, and so on. The other 500 are core pieces of infrastructure, such as servers, and relate directly to your data centre.
Where should your efforts be focused? All of these devices have relationships of some sort, but which should be prioritised?
Often, organisations become obsessed by the task of defining relationships for every single PC, laptop, and smartphone. But that’s crazy. It requires a huge amount of time and resources, and achieves very little. After all, if a single PC has a fault, that only impacts one user.
A faulty server, on the other hand, could impact the entire organisation. And this is precisely why it’s important to draw a distinction between assets and CIs. By focusing your time and resources on defining relationships for the 500 important devices you’ll dramatically improve the value of your ITSM toolset.
The Difference in a Nutshell
If we had to explain the difference between assets and CIs in just a few words, it would be this: CIs have relationships, assets don’t.
Of course, assets do have some relationships, they just don’t need to be anywhere near as detailed as those needed for a CI.
An individual asset must have an owner and a location… and that’s about it. Most CIs, on the other hand, need a whole range of relationships in order to be useful, including to other CIs, users, and groups.
Returning to our example, then, the 7,500 PCs, laptops, and smartphones are all examples of assets. We need to know where they are, and who owns them, but that’s about it. The other 500 devices, though, need a far more comprehensive set of relationships in order for your ITSM toolset to function properly. For this reason, we arbitrarily label them CIs, and focus the majority of our efforts on ensuring their relationships are fully defined.
Incident Management vs Change Management
Another way to think about the difference between assets and CIs is in terms of incident and change management.
An asset, being typically an endpoint device used by a single user, will mostly fall under incident management. If a fault occurs, the user reports it, and an incident is raised to either fix or replace the asset.
But CIs are far more complex. Let’s imagine you need to install a new version of an important application, which is located on a server that also hosts a number of other applications. In order to plan this project effectively, your server will need a full set of defined relationships to ensure the update doesn’t cause a major disruption to other important services.
And its heart, this difference epitomises the distinction between an asset and a CI. There’s almost no scenario in which a desktop PC fault could cause major disruption to your organisation, or impact more than a handful of users. On the other hand, there are few scenarios in which a fault with an important server wouldn’t cause a significant disruption.
Soothing the ITSM Headache
Laying your ITSM groundwork can be a long, difficult process, and getting it wrong can cause huge problems down the line. Properly distinguishing between assets and CIs, and defining relationships appropriately, is a big part of that.
