Branimir Valentic Are you able to tell the exact time if you are looking at two watches? Certainly not. It’s the same with having overview and manage your assets. If you have same service asset in more than one place, it will be impossible to govern it. Why is that important?
To be specific
Let me show you a few areas where asset management is very important.
Service Desk and Incidents – when a user calls and reports an Incident, it will look professional if your service desk agent already has information about the assets that this user is referring to. I have often heard questions like: “What kind of PC do you have? Which model? Well, you know, there is a sticker on the back side and somewhere in the second or third row you will find something like…” You know – no Service Asset and Configuration Management in place.
Incident Management – while investigating and diagnosing an Incident, it will be necessary to have precise information about assets (and its dependencies with other assets) involved. Otherwise, a lot of time and investigation is needed to collect asset information. And, the SLA (Service Level Agreement) clock is ticking. To learn more about Incident Management, read Incident Management in ITIL – solid foundations of operational processes.
Change Management – while assessing and preparing change (for deployment), you have to know what will be affected or where it will be applied. Otherwise, starting the change process could be like stepping into a fog and trying to find your way out. Imagine you are trying to an upgrade operating system version and there is equipment that is not capable (e.g. due to hardware incompatibility) to handle it. To learn more about Change Management read Elements of Change Management in ITIL.
Therefore, effective and efficient Incident management, Problem management, and Change management are not possible without Service Asset and Configuration Management. As defined in ITIL, the purpose of the SACM process is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.
Who is who in SACM?
Service assets are any resource (infrastructure, application, money, people) or capability (management, organization, processes, knowledge, people) of a service provider. They need to be managed, and we refer to them as Configuration Items (CI). Characteristics of CIs are that they can be individually managed and are controlled by Change Management. Therefore, not every service asset is a CI. For example, a server or PC is an asset and a CI, while the knowledge of a technician is a valuable asset, but not a CI. CIs are described using attributes and relationships with other CIs. CIs with related attributes and relationships form a configuration record. As the name implies, there is a database where configuration records are stored – Configuration Management Database (CMDB). CMDB is managed by Configuration Management System (CMS). Service asset and configuration management ensure that CIs are identified, baselined and maintained and that changes to them are controlled.
Width and depth
When implementing SACM, there is a logical question: “What should be the scope?”
Before SACM implementation, you should be aware that CIs can be at different levels. Sometimes CI is a service, and sometimes a component, e.g. hard disc of a server. The general rule for level of detail is that you should not include attributes or relationships unless these create more value than it costs to maintain them. If you don’t need information about processors in laptops and PCs, then it costs more to maintain such information than the value added. There are a lot of assets that could be CI, but every organization has to decide whether something will be CI, its attribute, or omitted from the SACM of an organization.
CMS (Configuration Management System) holds all information about CIs, their status and relationships with other components (CIs), but may also contain records for related incidents, problems, known errors and changes. Additionally, CMS is linked with other databases if further information is needed (e.g. Human Resources database/system). From my experience, it is highly advisable that SACM implementation starts with a policy, which will contain goals, scope, model (processes, roles, responsibilities…) and critical success factors (CSF). The policy should also ensure that changes to CIs are authorized through change management, as well as mandatory updates of the configuration record status in case of any update of the CI.
Collecting data, filtering and creating a configuration record is a tough job. The next step is even tougher – to maintain actual status. It’s kind of like losing weight. It’s easy to lose a few kilos – but to maintain that weight loss is another story .
Figure: An organization should decide the scope of SACM – width and depth of the infrastructure
What if…?
Are incident and change management possible without full and functional CMDB/CMS? Sure they are. In fact, most IT organizations are conducting changes without having SACM in place. So, why bother with SACM? There are a lot of reasons, but here are just few practical ones:
- Increased number of successful changes due to the better control and overview of affected CIs, as well as efficient assessment, planning and delivery of changes
- Financial optimization– e.g. optimized provision of needed licenses or accounting of IT services in place. To learn more about Financial Management read Financial Management for IT services – theory and practice
- Efficient Incident and Problem Management and good foundation for proactive Problem Management
So, yes, it is possible to live (well) without SACM in place, but if you are Service Manager or organization that is “flying high” – it’s a must. After you implement it, you will ask yourself “How did we ever live without it?”
Download a free preview of our template for the Service Asset and Configuration Management (SACM) Process to get an overview of activities, roles, and responsibilities needed for successful SACM.
