Serio Blog

Tuesday, 17 Apr 2007

In the next IT-service related blog topics I’m going to post here, I’m going to look at Service Level Management (SLM). I'll assume that my readers are completely unfamiliar with this topic.

First of all, I’ll start with a definition. Service Level Management is a name given to management processes that include:

  • Identifying and agreeing the IT service level requirements of the organisation
  • Monitoring and reporting on actual service levels delivered to the organisation, identifying any weak areas in service levels achieved
  • Identifying cost-effective ways to improve service levels delivered.

If the above sounds vague I apologise – I’ll be adding some detail to this in later posts when I think it will become clearer. The bottom line is this: what does the business need, what is IT delivering, how can we improve and bridge any gap?

Of course I can’t talk about Service Level Management without mentioning Service Level Agreements (SLA). If you are a novice Service Level Manager, you’ll be wondering how you write an SLA. Well there is no such thing as a standard SLA first of all, any more than there is a standard company. Generally an SLA will have some or all of the following items contained within it:

  • Identification of services offered to users
  • Identification of different user groups or communities
  • Responsibilities of both the service provider and user
  • Reporting intervals and key IT/business representatives or stakeholders
  • Definition of service review mechanisms (usually face-to-face meetings)
  • Underpinning contracts (such as those we have with suppliers)

(I’ll expand on these items in later posts).

If you are reading this, & then looking at your ITSM tool which (like Serio) probably has all sorts of SLA measurement and monitoring features (often based around simple response and resolve targets), you might be tempted into thinking that you have a SLM process or (more prosaically) ‘we do SLAs’. Maybe, but too often when I ask questions... 

  • the SLA targets have not been agreed with all (or in some cases any) of the key business stakeholders,
  • key services are not identified,
  • reporting is ad-hoc and unstructured,
  • no proposals for improvement can be found.

These are all signs of an ineffective or non-existant SLM process.

My point is that SLM is a management process – the role of the ITSM tool is to help you manage your targets and monitor what you are delivering. The good stuff (meeting with business stakeholders and documenting what they need, costing this, documenting what you deliver, getting a statistic from your ITSM tool and interpreting it wisely, suggesting costed improvements) happens outside the tool. It’s the value-added things like this that tell how mature a Service Level Management process is, not how closely you monitor different alerts and warnings from your ITSM software.

What I’m going to do in future posts is expand on these ideas. I’ll be talking about Service Level Agreements to give you an idea of how you’d create one, the service catalog, and some of the benefits arising from SLM. Most of all I’m going to try to deal with specifics and practicalities.

Blog admin's note: follow-up posts are here, here, here and here as of May 7th 2007. 

Monday, 16 Apr 2007

This post will talk about SerioScript - the scripting engine that powers, amongst other things, the Serio Command Center. Specifically, I'm going to create a new script and use it to illustrate how you can display property values on the Command Center web pages - so you can see device values read from SNMP directly in your browser.

I'm going to assume that you know how to connect a script to a Device, and already have the web pages set-up.

1. Firstly, create a new Script using the SerioMIB (right-click on 'Validation Scripts' and select 'Add Validation Script'). Call the Script 'Blogtest'.

I'm going to get the Blogtest script to display the Free Memory (compared against an acceptable value) for a target machine on the Command Center web pages (I'll call these the CCWeb pages). Please note the standard (Default) script does this anyway, but this simple example will allow me to show you how you display a value on CCWeb.

In doing so, you'll see how to construct a script, from scratch, with your own Device Properties.

2. Click on the Device Property Definitions tab. Right-click on the page area, and select 'Add New Device Property Definition'. Use the following values.

  • Display Name: Minimum Free RAM
  • Description: Free RAM (Memory) available on the remote machine.
  • Device Property Type: Scalar

3. In the Symbols window below, right-click and select 'Add Symbol'. Use these values:

  • Display Name: Minimum Free RAM (MB)
  • Property Name: gnMinFreeMem
  • Description: Minimum Free RAM in Megabytes
  • Type: Number
  • Default: 80

4. Click OK to close the Symbol Editor window, and click OK to close the Device Property window, returning you to the Validation Script(Blogtest) window.

5. From the list of MIB variables in the left of the Validation Script window, notice that the top three are underlined? These are special places for you to attach code to. Right-click the one called 'InitializationSerioScript' and choose 'Add Validation Statements'.

6. Add this line of code.

displayPropertyAdd('gnMinFreeMem', 'gnMinFreeMem', 2, '', 1);

Don't worry too much about what the arguments mean right now (you can look them up in the SerioScript Reference). All this function says is that, from a CCWeb perspective, this is a value I want to display).

Click OK to return to the Validation Script window.

7. From the list of variables in the left of the Validation Script window, right click on the variable that hold the current free RAM setting. It is called serioVarFreeMemKB. Right-click this and add these lines of code.

lnFreeRAMMB: number;

// Convert free RAM to MB.

lnFreeRAMMB := serioVarFreeMemKB / 1024;

// Check it against our expected value, and update the web pages accordingly

if lnFreeRAMMB < gnMinFreeMem then


displayPropertySet('gnMinFreeMem', numToString(lnFreeRAMMB,1)+' <=== Error!');

end else


displayPropertySet('gnMinFreeMem', numToString(lnFreeRAMMB,1));


// Display a print value as well on the console

Print("Free RAM in MB for "+serioVarDeviceName+" = "+numToString(lnFreeRAMMB, 1));

8. Now attach the script to a Device, and Go Online.

You'll see your target minimum free memory figure displayed against the current figure. When the observed value drops below the minimum for the Device (by default 80MB) you'll get a little 'error chevron displayed as well.

Friday, 13 Apr 2007

This post has been requested as a follow-up to my earlier ‘difficult customers’ post which seems to have been well received judging by the email feedback I’ve had. For those that don’t have it my email address is georger _at_ seriosoft _dot_ com - or of course post your comments below.

Whilst the role play seems like everyone to be a good idea, it seems it might be worthwhile going over some possible scenarios for your role play exercises, and more detail on how they should be conducted.

Starting off, I’d want to identify who should take part in our difficult IT support customer role-play. Emailer Rob asks if all staff who deal with customers (like engineers) should be involved, or just the service desk? My own preference is just the helpdesk/service desk – your central point of contact. This is the group we expect to excel in customer contact, and on whom suitable training will have the best results. Others can be included of course, depending upon the level of customer interaction you expect them to perform.

As an aside, emailer Karen objects to the use of the word ‘difficult’. Instead she suggests the terms ‘frustrated’, ‘angry’ or ‘concerned’ (or presumably all three at once - a FAC customer?). Despite Karen’s objection, I’ll stick with Difficult as a shorthand for all three as I can’t think of a better single word to describe what I’m writing about.

Make sure that is understood clearly by all those participating is that the role-play is not a test – it’s a training exercise. Make sure that your staff realise that they can’t ‘fail’ and that there will be no penalty if they find it tough.

If your staff are those fielding the test calls, you next need to decide who will play the role of the difficult customer or user. My preference would be for a peer-group exercise if at all possible – pick one of your more articulate, experienced and outgoing staffers to play the customer.

The environment should be private – with just the helpdesk/service desk staff participating in the exercise. My preference would be to complete the role-plays as a group, with each team member able to hear the others efforts. Calls should be played-out over the telephone, with the person playing the customer in another room. At the end of the exercise, when all have had a turn, have a group discussion where people review what they’ve learned.

Give your staff no warning about the calls, just brief them on the scenarios below.

1. Customer Bert calls to ask why the accounting system is down.

Scenario - Accounting system. The accounting system, used by 15 customers, is down having crashed in the mid-afternoon on a Monday. It’s the third such Incident in a 15-day period. You have no time estimate for when the system will be restored. Your manager has taken the afternoon off to play golf.

Key points: Demands to know when the system will be back. Attitude is somewhat aggressive. He wants to know what is being done. Wants to know why it keeps happening. Repeats that it ‘just isn’t good enough, some of us have work to do’. Asks ‘will any of your staff be here to help when I have to work late’. Refuses to put the phone down until satisfactory answers are given. Resorts to mild swearing.

2. Customer Kath calls.

Use scenario from 1.

Key points. Kath is calm – could be described as passive aggressive. Asks to know how many other such Incidents there have been recently. Asks the opinion of the person taken the call on the quality of service, she asks 'it's unprofessional isn't it'?. Demands the service is restored immediately. Then asks to speak to a ‘supervisor’.

3. Customer Arthur calls.

Scenario - Monitors. A colleague has replaced a monitor of a VIP who complained the original was fuzzy.

Key points. He says his ‘new’ monitor is worse, and is fuming because your colleague closed the call without asking him if he was happy. He demands you get up from your desk immediately to return his old monitor. Asks ‘do you like working here?’, and asks, of your boss, 'is this the level of service he is happy with' asking you to comment on your boss.

4. Customer Bill calls.

Scenario - CRM. Bill manages the CRM system and can’t access a particular report.

Key point. We need to know the error message listed in the Event Log on the computer, but Bill will not co-operate or follow the instructions of the first-line technician he has called. He repeats ‘this is a problem with the upgrade you did, don’t waste my time’ and every suggestion is rejected. Bill will not co-operate to get his problem fixed.

I hope you enjoy the role-plays, & have a great weekend!

Wednesday, 11 Apr 2007

This is a follow-up to my earlier ‘Introducing the Serio CMDB’ post – this time I’m going to talk about some of the other data attributes and something new we’ve added. I’ve posted more generally about the Configuration Management Data Base (CMDB) here.

My earlier post discussed three attributes on an Item – Item Type, Product Type and Customer. There is other important data you can add, as follows.

Network Name. This is used mainly for computers, but can also be used for other types of network-connected devices such as routers and hubs. It’s simply the DNS name of the device if trying to connect to it over the network. This is because in some organisations, the ‘Asset Tag’ or sticker with a unique ID physically attached to the device is sometimes different to how the device is identified on a network. This attribute is used by Serio’s network audit and monitoring software to connect to remote devices and obtain data. Personally, I think like is a lot less complicated if the network name and the sticker on the side of the box are the same.

Status. The use of Status is not immediately obvious. Typical values might be ‘Deployed’, ‘In warehouse’, ‘Awaiting repair’, ‘On loan’. It’s simply there to tell you how an Item is being used, or to which ‘pool’ of equipment something belongs. In my post from April 2nd about difficult customers I mentioned that my employer at that time kept a significant inventory of spare, new kit ready to be deployed at a moments notice. Using that article as an example, the fuzzy monitor might have a status initially of ‘Deployed’, which is then changed to ‘Awaiting repair’ as it is taken away. The replacement might have a status of ‘Ready to deploy’ initially, quickly changed to ‘Deployed’ as it is swapped to a user’s desk. If we think about this for a second, it means I could have queried the system for all ‘Monitors’ (Item Type) that are ‘Ready to deploy’ and seen the spare sitting in stock.

SLA and Supplier SLA. You can attach two different SLAs to an Item. The first (your Service Desk or Helpdesk SLA) is used on Incidents when you use the Item to log an Incident (on other words, it override the Default SLA and any SLA Selection Rules you have). If you then assign that Incident to a Supplier (search this blog for Supplier Management) then the Supplier SLA from the Item is used to gauge supplier performance.

Something new has been added to Serio. It’s called Item Schedules – basically a diary system for booking Items in an out on loan. You can record the booking out of Items to customers between different dates, with the system telling you about ‘double booking’ of any item. It’s a nice feature for anyone running an equipment library.

Friday, 06 Apr 2007

My post today is on the subject of ‘the big rollout’ – when a new or upgraded application is rolled-out to end users.

My experience of this over my career is mixed to say the least. It varies between someone calling and saying ‘I’ve got a problem with this new application WidgetSkillz’ and me saying ‘Oh what’s that?’ at one end of the scale, whilst at the other, I had an employer plan meticulously for 1000 ‘rollout’ Incidents in the first week and receive only 20 or so.

Firstly, I’ll risk being a master of the obvious and state why new rollouts cause problems

  • The new application of service might be buggy or have errors in its configuration
  • Users may be unfamiliar with the application
  • If the rollout involves deployment to desktop machines, you can usually be sure that some of these will fail (or at least not be 100%)
  • Some users don’t like change, and need someone to vent their frustrations on (often the Helpdesk and Service Desk staff).

This post is all about how some of the things I’d so for the front-line team – your Helpdesk or Service Desk.

1. Pick the roll-out time carefully. This is a tough one, because often there is some business driver (like a new contract) that gives you the start date. However, often you can influence the date even if you bring it forwards a little. Dates are important because there is often a ‘cyclic’ nature to IT support, with periods of greater activity coinciding with greater user activity and stress at certain times. At least consider this carefully, use reports (like the 26 week-by-week report in SerioClient) to spot any such cyclic activity and consult widely to see what other things are happening in the business.

2. Make sure your Service Desk/Helpdesk team leader (or your Incident Manager) is part of the project team. This is not always the case, particularly when you’ve got an in-house team writing or upgrading the new application. My experience has almost always been that developers focus solely on the code and delivering a stable application at the expense of issues like training and documentation.

3. Make sure a late, stable version of the application is available for your front-line support team to learn about. Make sure they have time to use it and understand it’s key functions. But please, don’t ‘give it to them to play with.’ I’ve seen this so many times and it always ends the same – the people who need to know how to use the application know nothing.

Instead, give them (the front-line team) a suite of exercises to perform, usually involving a couple of business processes, and ask them questions at the end. Make sure their time is structured and not wasted.

4. If you can, run a pilot. A pilot roll-out to a select band of users.

5. Using the pilot, try to develop a Frequently Asked Questions (FAQ) list, or collection of knowledgebase documents, to help get over any rise in calls coinciding with the rollout.

6. Finally, look at your leave rosta carefully. You wouldn’t be the first manager to plan a big rollout for a day when a large number of staff were on holiday.

For those of you on holiday over Easter have a great time, for those of our readers working (and there are quite a few) you have my commiserations.

Wednesday, 04 Apr 2007

I’ve been posting previously about getting your own CMDB (Configuration Management Data Base) off the ground. This post is about some of the specifics of the Serio CMDB.

First of all, a question I’m often asked is this: ‘Can I convert data from the Serio discovery tools to CMDB data?’. The answer is yes, you can. However, you should remember that this does not mean you have a CMDB (as I’ve discussed here). Configuration Databases contain business knowledge – things like how many concurrent users use a particular service, where the equipment is physically located, who maintains it – and this type information cannot be obtained by a mere network scan (though I’ve known vendors [not Serio, I hasten to add] who claim they can auto-generate a CMDB).

Data created in this way (from a network scan) does however offer a reasonable start point for you, but resist the urge to view it as anything more than that.

So let’s look at some of the specifics. Firstly, categorisation. An individual Configuration Item (referred to as Item in Serio for short) has two main types of categorisation: Item Type and Product Type.

  • Item Type: This is best used as a generic classification, and is hierarchical – having both an Item Type Category and Item Type. By generic, I mean it’s a less specific way of considering an Item. An example might be a category of Computer, with Item Type values underneath it of Desktop, Laptop, and Server.
  • Product Type: This is a much more specific categorisation. Like Item Type, this is a hierarchical data value but with 3 levels – Product Type Category, Product Type, and Product Version (the Version is optional). Generally if follows the manufacturers designation of an Item, with many users putting the manufacturer into the category part, with the Product designation underneath.

Having these two values means you can combine them to allow you to work on different subgroups – for things like upgrade planning.

Aside from these two, one of the other most important values you can store against the Item is the Customer. This is normally the main user of an Item, and as you would expect applies more to desktop equipment than server equipment. Setting this value is useful during Incident logging in the following ways.

  •  If you select the customer for an Incident, Serio will automatically load the Item into the logging form for you.
  • If you log the Incident by selecting the Item first, then Serio will automatically load the customer.

I’ll continue this thread of topic over the new few weeks.

Monday, 02 Apr 2007

A long time Serio customer and friend (who shall remain nameless) asks ‘I’ve been asked to write-up some guidelines for our operations manual about dealing with difficult customers who call our help desk. I’m struggling so I thought I’d ask you!’. What prompted this was an exchange between a first-line helpdesk staff member and an internal customer with a print problem which seems to have gone badly wrong.

I’m always glad to help. However, after hearing the following anecdote (which I apologise for re-telling) you may think otherwise about asking for my assistance.

After graduating in the late 1980’s I worked at a Bank in London – my first proper job. This was not a retail bank, but a bank that made money by trading forex, shares, risk – anything you like really that can be traded. As the new graduate, I wound up on the helpdesk taking calls from (amongst others) traders. My training consisted of being shown how to use the 1-page logging system and told ‘they shout – a lot. I’m outa here’ and with that, after 10 minutes, I was on my own.

My first 10 or so calls were easy, then this happend.

Caller: ‘My monitor is fuzzy. I want a new one.’

Me: ‘Have you checked to make sure the video cable is not near an AC power source?’

Caller: ‘What?’

Me: ‘Have you checked to make sure the video cable is not near an AC power source?’

Caller, slowly this time: ‘My-monitor-is-fuzzy-I-want-a-new-one.’

Me: ‘er…’ (I was starting to panic) ‘It might just be that the AC power source is interfering with…’

Caller: ‘What the [deleted] is this a physics lesson you [deleted]?’ Then aside to a colleague ‘they got [colourful phrase] Jonny Ball working on the [more colourful language] helpdesk and the [four letter word] is giving me a [expletive] physics lesson.’

Me: ‘It’s just that if you –‘

Caller: ‘You’ve got 5 seconds to say the magic words or that’s it. 5-4-3-2-1 bye’. Then the phone was slammed down.

Ten minutes later I was within a whisker of being fired, & not allowed to work on the helpdesk again.

So, how can you avoid making my mistakes?

1. Role play. Although my correspondent asked specifically for text for an operations manual, I don’t think this is what he should be asking for. Text written in an operations manual will not help you at the time that you need it – when you’ve got an angry person on the phone. Instead, you should develop role-play exercises and use these should be used by your staff. Make sure the exercises are played-out in a private environment (just the front-line team) and that the scripts you are following are realistic – if you like base them on real customers or situations. Then back this up with some written guidelines. Make sure that each new start gets a chance at the role play – you can almost guarantee that if you don’t they will be the ones to get the irate customers.

2. Make sure staff, particularly, new starts, understand what customers can reasonably expect. In my anecdote above, I did not understand that the traders got whatever they asked for – and quickly. The company actually kept spare (new) equipment all configured and ready to be swapped in or out, having a stock to rival your local computer superstore.

3. Don’t argue. Your job is not to defend the helpdesk or service desk position. If the customer is complaining about something bad you’ve done apologise to them, agree with their complaints, and stress you will try to do something about it. If you don’t do this then the situation escalates, as shown above. During the role-play, listen for staff who sound patronising or insincere and talk to them about this. However, avoid obsequiousness (grovelling) – so some angry people this is like fuel to the fire.

In the example above, I was arguing with the caller. He made it clear that he was not going to check anything to do with his monitor, yet I persisted. Although I did not disagree with him, this is still arguing.

4. Avoid agreeing with the customer if they start to infer that the whole service offered by your helpdesk or service desk is rubbish. Just deal with the specifics of what the customer is irate about.

5. Make a careful not of what has irritated or upset the customer. Make it clear to the customer by re-stating what they want, or what has upset them.

6. Don’t get angry in return. I always find that standing-up can help during a difficult call, as it help you to breathe more easily and relax.

7. Optionally, have a complaints procedure, and ask if the customer wishes to raise a formal complain. Be prepared to explain the complaints procedure.

8. Whilst listening to the customer complaint, learn to become deaf to rudeness.

[Edit: I posted a follow-up to this here

Friday, 30 Mar 2007

A few of the more recent posts have covered aspects of Asset Management, Configuration Management and the CMDB. This post is related to the series about Configuration Management for beginners because it discusses a very useful tool for gathering Configuration information.

This tool is a small software agent which is installed on a target machine and is capable of returning configuration information over the network ‘live’ - but what about those machines that are not switched on when this information is gathered?

Those of you who are Serio users will recognise this as the Serio Inventory Agent (SIA). The agent is installed on each machine and it's main purpose is gathering detailed Configuration information regarding the machine (which we all know by now is known as the Configuration Item or CI) over the network, on-demand.

These agents are great for helping to manage your network BUT if the machine it is installed on is not switched on or connected to the network, then none of the information it can provide can be accessed. This means you could try and gather information about your network on numerous occasions and still be missing vital information because some machines are not detected.

This is where the File based Inventory Agent mentioned in the title becomes important. This tool will gather all the same information from a computer and will save it to file in a specified location. Typically it is installed centrally on a server, and run as part of user login scripts (it completes its work very quickly). This information can then be accessed at any time and included in your network plans, giving a complete and detailed overview of your network whether the machines are switched on or not.

The type of information that can be gathered by the Inventory Agent is extensive and includes Software, Hardware and other miscellaneous information. Software could include installed software applications, information about the machine name and operating system, running processes and internet settings. Hardware information would include attributes like network configuration, display adapter characteristics, hard disc configuration and memory / CPU information.

The Inventory Agent would make all this information available to the Service Desk agents at the click of a button helping to deliver a better IT service. In addition to this the Inventory Agents can now be queried from a single location and provide detailed information about the computers on your network (we call this a network snapshot).

Having all this information stored in one location now gives you added control over your network. Any changes made on the network between each snapshot will be highlighted immediately (which can be a huge step in working towards proactive Problem Management). This will also help you to identify exactly which machines on your network are using a specific piece of hardware or software.

Tasks such as license reconciliation also become easier as it becomes clear how many of each licensed products are installed on the network, which can be compared to the actual number of licenses you have purchased.

Tuesday, 27 Mar 2007

This post is another in the series about Configuration Management for beginners.

I’ve posted previously about Asset and Configuration Management, compared some of the differences between the two and the challenges that you face if doing either. This post will extend that by examining how you can make a start on your Configuration Management Data Base (CMDB).

Before you start entering data and creating the CMDB, you need to get a feel for the project with a bit of forward planning. What you need to do is understand what level of detail you are going to go to, what data is going to be stored directly in a tool like Serio and what is going to be linked to, what a CI actually is, and so on.

This is how I would go about it – I’d avoid generalities and concentrate on specifics. Pick a system or service (ideally modest in scale) and on paper try to identify what the Configuration Items are that combine to deliver that system. I’d probably ignore desktops for the time being, and simply focus on the enterprise level components. If you find the task of identifying the Items difficult, consider only those things you wish to subject to Change Control.

You’ll come across lots of little micro decisions to be made. For example, you might find a network device like a router. Taking the case of the one I have sitting next to my desk, it has 3 interfaces – one of which is a BNC-type connector, the other 2 RJ45. Each of these has a specific routing table, and a specific IP address. So how to you represent this in the CMDB? You could:

  • Represent it as a simple ‘black-box’ Configuration Item, and just say it routes network traffic?
  • Represent it as 3 CIs (one for each interface) linked to a ‘main’ CI that represents the router service?
  • Use a simple single CI, but embellish the CI. For example, a Serio user might create Item Attributes to store information about the 3 interfaces.
  • Choose to store all of the information about how the router is configured in the CMDB. In Serio you might create a custom data field, or you might choose to link a document.
  • Decide none of the above works for you, and miss the router altogether (though I would suggest this is unlikely).

Finding solutions to problems like this will help you understand the right approach for you. Working with a specific system will give you experience, and working on paper (in the first instance) stop you being distracted by any issues arising from your tool or lack of experience with your CMDB tool.

Then take your first draft CMDB, and use it to create a guide for yourself – indicating what data is to be included, the level of detail and so on. It will help you to create a consistent, useful Configuration Management Data Base.

I'll follow this up on Thursday with a post about some specifics of the Serio CMDB.

Friday, 23 Mar 2007

This is a follow-up to my earlier beginners Asset Management and Configuration post.

I described previously how it was difficult to keep an Asset register up to date – but keeping a CMDB up to date is harder because it holds more information.

Here’s the problem. In the previous post I mentioned some computers (Items) that ran enterprise-level services, and how we’d show them on a CMDB. Part of the information we’d store about each Item might include

Operating System (such as Win2003)

Major Patch Level (such as Service Pack One)

Configured network cards

…and so on. The problem is that this can change – for instance, Microsoft might release another major service pack, and an engineer takes this one evening and updates the server. So now something quite important in the information we hold is incorrect – even though the machine is sitting exactly where it was, doing exactly the same job. Anyone using this data for Incident management (or any other discipline) will now be working with incorrect data.

To spell it out, CMDBs are more of a problem to maintain because they hold more data.

Typically, Change Management is used to keep the CMDB up to date by having a specific stage or task within the Change process where the CMDB is brought back in line. Without an effective (and strictly observed) change process, you’ll struggle to maintain the integrity of your data.

Maintenance is only part of the issue. I described previously how the Asset register could be created by just ‘walking about’ recording what you see. With a Configuration Data Base, you have to understand how complex systems are constructed from parts that themselves might be complex – and then be able to represent that in a comprehensible and useful form.

So far, I’ve only talked about the challenges of creating and maintaining a CMDB, and said nothing of the advantages. There are many however, such as some objective information from which you can perform impact assessments for use in Change Management.

To sum up, what you do will be driven by the resources you have, what you are trying to achieve, and where you are right now in terms of your IT service management maturity.