Service Asset and Configuration Management (SACM) is the process of maintaining information about IT Assets and Configuration Items (CIs) required to deliver an IT service, including their relationships.

Service Asset and Configuration Management is a process that many organisations struggle to implement. Why?

In this blog article, we will provide you with some basic guidance to get you started!

Service Asset & Configuration Management Definition

Service Asset and Configuration Management (SACM) is the process name that we give to what was simply called Configuration Management prior to 2007 when the current version of ITIL was launched. Effectively it is the process that documents all of your physical and logical assets and IT components within your organisation.

The Importance Of Service Asset & Configuration Management

This question is like saying "why is it important to have solid foundations under your house?" It just is… Without solid foundations you can't build a house, or you could but you would soon see the cracks appearing. It's the same with Service Management processes. There's no point in documenting your infrastructure for documentations sake. It's the use that other processes will make of the data that makes it so essential.

Configuration Management is one of the few processes that under-pins all other ITIL Service Management processes and service lifecycle phases in ITIL. Without it, the effectiveness of the rest of your processes is in serious doubt.

The key deliverable of the SACM process is to produce an accurate and up-to-date Configuration Management Database (CMDB) which is basically a repository, or a database that stores and manages your configuration Items (CIs) and also manages them throughout their service lifecycle. When it forms part of an integrated Service Management tool it is simply invaluable.

(Before we go any further, you might be interested to take a look at our ITIL® 4 Foundation training course and certification).

What Is A Configuration Item (CI)?

Quite simply CIs generally comprise all the assets and the service components which require to be managed, or controlled, in order to deliver IT services.

Apart from promising clear visibility into the CIs and their relationships, a robust CMDB enables a range of direct and indirect advantages. It definitely leads to advanced change control and governance with significant reduction of risks. It provides a wider framework for improved security and regulatory compliance with real-time asset planning and monitoring. A system of well-managed CIs also substantially facilitates incident and problem resolution. In addition to setting a foundation for ITIL best practices, it solidifies and promotes a high level of planning and execution in respect to IT application management, and accelerates the governance of service orientated architecture initiatives.

What Is In A CMDB?

A typical CI, or configuration item can be construed as any IT service, hardware, software, network component, formal documentation or SLA. The CIs, apart from being tracked or managed, are subject to Change Management another core process in the ITIL framework.

Should the CMDB repository include all conceivable configuration items? The answer is NO. If you can't control it or manage it then you can't maintain its accuracy so don't even bother to track it in the first place.

The CMDB is organized and managed by a process-driven system, often referred to as the Configuration Management System (CMS), and the CMS has multiple layers - data sources and tools, information integration, knowledge processing and integration. The CMS captures the salient attributes and features of the tracked CIs in the CMDB in a designated format. This enables standard classification and identification and records your CI relationships.

(You might like to read this post looking at the difference between ITAM and SACM in ITIL4.)

CMDB - How Many?

It is possible to have multiple CMDBs, which all connect to a single integrated or core CMDB. Many organizations also resort to automated processes to load and update the CMDB by running discovery tools, inventory or audit tools. These tools often are used to populate an instance of an alternative CMDB, and then to subsequently compare and reconcile the existing information in the CMS with the actual live configuration discovered. Such comparison also empowers the IT organizations to trap any unauthorized or unmanaged change that might have sneaked through the change management process and enables them to take remedial steps. A key success factor in implementing a CMDB is the ability to automatically discover information about the CIs via auto-discovery tools and track changes as they happen.

How Do We Get Started?

Normally I would simply say "PICSV", or "Perhaps I Can See Vampires", or even "Pubs In Copenhagen Sell Vodka"… Which is my way of remembering Planning, Identification, Control, Status accounting and Verification and audit, which are the five main activities of SACM. Planning - Basically you need to start with a plan, a plan that enables you to design the CMS, the CMDBs and the SACM process itself.

Firstly you must define the scope of your plan as it's very important to know your boundaries otherwise you will bite off more than you can chew. Remember the saying "How do you eat an elephant?" The answer is "one bite at a time".

Don't rush the planning phase as you may not get a second chance if it all goes 'pear shaped'. Consider a pilot phase as part of your plan to ensure the plan actually works.

Identification - During the planning phase you should have consulted widely to identify what data is to be kept, who currently holds and owns CI and relationship data and how the data will be initially input or uploaded and how it will be kept up to date, manually or electronically and how it will be labelled.

You will need to consider naming conventions for CIs. Every service asset or CI must have a unique identification. It makes logical sense to name CIs in such a way that a mere glance can tell you most of the story - like what type of CI it is, location, complexity, and other attributes. However do not over complicate the naming convention and ensure it is flexible, scalable and future proofed.

Consider the use of verification tables for things like manufacturers name. You would be surprised how many variations there are of spelling "Hewlett Packard" or was it "H.P" or even "H.P.". Believe me even "DELL" can be misspelled in free format fields.

As part of your implementation plan ensure that you design and schedule regular baselines. Baselining of a CMDB must be scheduled at least once a year. A baseline is a benchmark drawn, for future reference to compare the changes between baselines.

Control - The next phase of configuration management is strongly linked with the change management process. Without a valid change ticket, a CI cannot be touched - for modifying of course. In other words, change management controls the changes to CIs on the CMDB, and without control you'll soon have chaos.

The configuration management plan must specify how the change management process will interface with the configuration management process, and, at what point of the change activity will the configuration management process be called upon.

Status Accounting - will ensure that you can track the progress of a CI throughout its whole life, so deciding on valid status for each CI type is important as it the mechanism that moves it from one state to another. It will also give you an audit trail to track the life history of any CI. This is important so that faulty components don't keep regularly reappearing after they have been repaired.

The long term accuracy of CI data is also essential. To ensure that it stays accurate, a number of verification and audits activities are necessary.

Verification and Audit - Verification is done by the configuration manager on a regular basis, and is mostly tool based. Modern tools are capable of providing reports that can help verify CI data. The Service Desk can also verify configuration data every time a user calls the Service Desk.

(Click here if you want to know more about our ITIL Service Desk training).

Audits on the other hand are generally performed by somebody other than the configuration manager or any of his team members. In an audit, a sample number of CIs are picked up, and are randomly verified against actual components. An audit report is prepared based on the findings, and the configuration manager will get a major or minor non-compliance depending on the degree of discrepancies (if any).

Other Considerations

Oh, you'll also need to consider introduction, goals, objectives, purpose, roles and responsibilities, definitions, CSFs and KPIs, reporting, process interfaces, training and lots of other interesting challenges.

So, What's Next?

I hope this insight has been of use and has whetted your appetite to learn more? If you would like further information about how Purple Griffon can assist you in developing or improving Service Asset and Configuration Management or for general information about IT training, consultancy and ITSM software sourcing then please contact us.

Regards

Steve Lawless

CEO - Purple Griffon

44 (0) 1539 736828 - Training

[email protected]

PS - Before you go, you might also be interested in this blog post we wrote about service delivery management or this one about being a service transition manager.