News, Reviews and Resources for ITSM Professionals.

Configuration Management How To (Part 1)

Home » Featured, Guides » Configuration Management How To (Part 1)

Overview Of Service Asset & Configuration Management

Service Asset & Configuration Management (SACM) is the process responsible for ensuring 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.

Done correctly, Configuration Management is a key enabler for resolving Incidents, identifying the root cause of Problems, impact assessing Changes and building the technical layer of a Service Catalogue. It’s also the process that tends to make people panic because of all the databases, information systems and scary terminology; so here is our panic free guide to Configuration Management. Configuration Management is made up of the following steps and we will look at each one in turn:

  • Planning
  • Identification (Baselining)
  • Control
  • Status Accounting
  • Verification


Configuration Planning

7802754212_0fd2e22154_zLet’s start with the basics. Configuration Management is one of those processes where you really, really need to have a plan. I’m not talking any old plan either; I’m talking Hannibal from the A Team level planning. Why is planning so important? One of the biggest reasons Configuration Management fails is because people try to do too much so setting the process scope is a key activity.

Let’s start with the inventory layer. Inventory Management takes care of consumables; keyboard, mice, USB sticks and SecureID cards. Stuff that needs to be tracked for monetary value and to make sure it’s in stock but that’s about it. The next layer is Asset Management. Examples of assets include PC’s, Laptops and printers. Stuff that we need to keep track of for monetary reasons, to make sure they’re in stock when needed, locational info and how they are supported. The final layer is Configuration Management. Items under the control of Configuration Management (CIs) are the big chunky items that make up your critical services. Servers, network devices and software applications should all be under the control of Configuration Management to make sure they are managed, supported and subject to the appropriate Change control.

The plan should also explain any naming conventions or nomenclature. Confused? Every CI or item that is under the control of Configuration Management should have a unique name or identifier. When I’m tasked with implementing a Configuration Management process from scratch I try to use a naming model that will make it easy for the CI to be identified so I tend to use the following:

Type of Service – Location – Level of Complexity

So a WinTel server based in Dublin requiring third line support would be WinTel1234 – DUB – L3 and a business spreadsheet located in London requiring first line support would be Exl-LON-L1 and so on. In terms of naming conventions; it doesn’t matter what framework you use, as long as everything has a unique identifier. When I worked for an investment bank in London, the naming convention was food based so all WinTel servers were named after Italian food, all UNIX servers were named after Chinese food. Another example is from a firm that I worked for in Reading; all WinTel servers were named after characters from Terry Pratchett books and all Network devices were named after monsters from ancient Greek mythology. Both worked really well and as an Incident Manager it was pretty hard to get stressed during a Major Incident when someone shouted Rincewind’s fallen over again!

The plan should include a reference section. When you’re building a CMDB you will be talking to support teams, service architects and project managers. Ensure that you capture the source of the information whether it be from a Service Catalogue, support documentation or even from SLAs so that it can be verified before it’s placed in your CMDB.

Does your organisation have a Configuration plan? Let us know in the comments!

 

ConfigEnterprise Service Management Webinar Module 3: CONFIGURATION MANAGEMENT

Don’t forget to join us for our 3rd webinar of the series – Configuration Management on 31st March, 2pm GMT. Register here!

 

Image Credit

Vawns Murphy

Irish mum of 3. ITIL V2 Manager (red badge) and ITIL V3 Expert (purple badge). SDI Managers certificate. Further qualifications in COBIT, ISO 20000, SAM, PRINCE2 and Microsoft. Author of itSMF UK collateral on Service Transition, Software Asset Management, Problem Management & the "How to do CCRM" book. Reviewer for the Service Transition ITIL 3 2011 publication. When not being pelted with brightly coloured balls in name of ITIL, I am a senior ITSM analyst for Enterprise Opinions.

More Posts

Follow Me:
Twitter




1 Response to " Configuration Management How To (Part 1) "

  1. Mauro Gario says:

    My attention was catches by the unique asset name format you propose.
    It depends really from the volume of your IT environment, its geographical distribution and variety of platform do you use.
    In a multinational environment with 1500 servers o 4 platforms, I found that this way was not good to identify CIs because they can change location and you will be mislead by their name. Moreover, if you run more applications on it you don’t have just one severity level. If you choose to indicate the highest one and you remove such application you should change it. I agree that this is not the right way to allocate applications, but it happens…
    Having dealt with such issue I decided to use a really simple prefix to indicate the platform followed sequential number with alphabet sequence included: W001a for a Wintel platform.
    This works perfect in any case.
    You can argue that this had no meaning but is the CMDB that has to make it meaningful.

Leave a comment