Serio Blog

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. 

Wednesday, 21 Mar 2007

This post is at the request of a customer trying to make sense of Asset Management and Configuration Management. I’ve covered these topics before (search in this blog and you’ll find them) but this post will assume no prior knowledge or experience.

Let’s get started with some definitions – in my own words.

Asset Management: This is where you maintain a list of assets for housekeeping and accounting purposes. Typically the assets are computers, monitors, printers and so on. When I say maintain a list I mean just that – a list, one after the other, usually classified in ways that are helpful to you.

Configuration Management: This is where you try to create a map (or diagram) that shows how building blocks (Configuration Items, [CI or Items for short]) combine together to deliver services to users. If you take a system that our customer might be familiar (such as Serio) it might show, at the risk of showing my age, something like this:

SerioServer running on a computer Zephod, with a dependency to a SQLServer instance running on a computer called Gargleblaster. A web server instance also running on computer Zephod, with a dependancy to the SerioServer instance

.. and so on . I can count 5 Items in the above description, and these would all be linked together (possibly as a System, if you are so minded). The terms used for such data is Configuration Management Data Base (or CMDB for short).

Hopefully the definitions are clear. I’ll leave the issue of why we might do either of these until later.

Now you might be thinking ‘Configuration Management sounds more useful and advanced, I’d better go for that’. My response to that is: not necessarily. It depends entirely on your situation, your maturity in terms of IT Service Management, and what your goals are. We’ve got a ‘golden rule’ at Serio about data, and it’s this:

Don’t store data you can’t verify or keep up to date.

So there is your first challenge. Regardless of what you do, you need to address the issue of keeping your Asset register or CMDB up to date. The golden rule sounds simple and obvious (and it is) but it’s surprising the number of people who create data stores with no regard to its future integrity.

Generally speaking, keeping the Asset register up to date is easier. You make sure all new equipment must have an approved number on it (usually by setting up a protocol with your purchasing or goods-in department) and allocating the number allows you to book it in. When Assets are scrapped you have a similar protocol, and delete from the register.

In the real world however, you will find that people still find ways to introduce Assets you are not aware of – like going down to the local computer store and using an expense account credit card.

Creating an Asset register is tiresome, but usually straightforward. Simply walk around your office putting tags on things, recording their details as you go (easy if your got 250 computers, not so easy if you’ve got 25000).

I’ll continue this topic in future posts. 

Monday, 19 Mar 2007

This is a post about some gadgets and features you may not know about on Serio 4.6 and later versions.


There is a Helpdesk/Service Desk Agent-to-Agent chat facility. It works between users of SerioClient, and lets you hold a text chat session with them, just like you might have seen with other messenger-type applications.

To use Chat, click on the ‘Users’ icon in the bottom-left hand side of SerioClient, and then select the person you want to chat to from the left-hand side  Serio will then launch a chat panel, simply type your message and go.


Very few people seem to know this, but there’s a ticker tape message. For example, you might want to broadcast

  • Our billing and accounts system is down or
  • There are free cakes in the meeting room

and have all SerioClient users see that as a ticker-tape message running across the top of SerioClient, then simply click the Serio logo, and select ‘Create a Ticker-Tape Message’.

Export all or part of an Incident/Problem or Change to HTML

Like the title says, exporting Incidents in a convenient HTML form is easy. You can even control the format that’s used by editing a template (for instance, you add your company’s standard font or logo). To do this, simply right-click in Incident, Problem or Change Management lists, and select ‘Export to Public Knowledgebase’.

All this does is tell Serio you want the content of the Incident is HTML format – it’s up to you where you store the document, there is no need to put in into a KB directory. Serio will only export Actions you’ve flagged for export to the KB (these display in SerioClient with a KB icon beside them). You can read more about this by searching for the topic ‘Exporting Issues to the Public Knowledgebase’ in the HowTo guide.

Linking together Incidents, Problems and Changes

The quickest was is by using Copy/Paste link – it takes just a few clicks.

Linking Items Together

Again the quickest way is by Copy/Paste Link

This is a follow-up to my earlier Problem KPI post. Commentator Mark asked ‘what about Known Errors’, something my suggestions for KPIs did not cover. Thanks Mark.

Remember that the whole point of Key Performance Indicators is to tell us how effectively some process or activity (in this case Problem Management) is working. Therefore the question is what Known Errors tell us from a KPI perspective – should they be included or not as a KPI?

My feeling is we should. The Known Error count is another indicator of ‘health’ of the Problem Management process, so I’ll amend point 2 of the earlier post as follows:

2. Problems Resolved or with acceptable outcomes

Show the number of Problems resolved as follows:

  • Counts of Problems Resolved by raising of a Change(s)
  • Count of Problems that lead to a Known Error state
  • No. of Problems flagged with a Workaround

Interpreting the figures you get is quite tricky, as of course there is no ‘right’ figure. However, a constant run of zeros (or very low numbers as a percentage of the whole) would indicate to me that there may be some issues in identifying these outcomes as part of the process.

Friday, 16 Mar 2007

This is a follow up to my last post on the subject of KPIs in Problem Management – read that previous post for background. In what I write I’m assuming that the KPIs are going to be used in a report whose audience will be the Problem Management team (therefore, quite detailed).

I’ve concluded that we are looking for signs that the Problem Management process is working. Here are some suggestions for you to try.

1. Number of Problems raised.

This is a tricky one – I’d never show this figure without comment. A figure which is low may indicate a situation where Problems are not being adequately identified, as I’ve discussed in this post. You can compare this to the number of Incidents raised over the period, to see if the rising/falling trends are the same.

2. Number of Problems Resolved.

There are a few ways I’d present this. I’d show the number of Problem satisfactorily resolved, and the total number of Incidents linked to these Problems. This is useful because it tells us how many Incidents we’ve finally got to the root cause of.

Then I’d produce a summary listing, so that the detail can be seen. I’d show the Problem Reference number, Priority, a one-line description, and the number of linked Incidents. Doing this allows readers to see how the ‘overall’ figure breaks down.

3. Days open for unresolved Problems.

One of the things that you wish to see in your Problem Management process is that tickets that are logged do (eventually) move to resolution, and so you want to see how long Problems have been on file for. An easy way to express this graphically is to have a ‘days open’ figure along the vertical axis, and then to list each open Problem along the horizontal axis, with its reference number, showing how long it has been open.

I have met customers who have used Service Level Agreements on Problem Management. Generally I don’t approve, partly because SLAs should be for things that a customer sees (like an Incident), but mostly because I don’t think it improves efficiency or promotes best practice. Sometimes Problems can (by their unexplained nature) can take a long time to come to a satisfactory resolution, and the outcome we want is a quality (complete, accurate) resolution. What is important though is that your own procedure make sure that Problems don’t just stall, but continue to be moved forward.

4. Activity since last reporting period, per Problem

I’ve written above how we need to make sure that Problems are being looked at, priorities, managed and assessed by the team – rather than simply gathering dust in your service management tool.

Whilst more of a status report, list each Problem and give a brief (no more than one or two line) summary of what you’ve done since the last reporting period.

So for instance, if you are reporting every fortnight you might say ‘Identified application X as possible cause, currently discussing with vendor support’ for a given Problem ticket. Serio uses would simply create an Action called ‘Progress update’ for this purpose, to be completed by those assigned Problems within the service management teams.

Needless to say, you are looking for signs of life across all or most of your Problem records because without that we won’t move to resolution.

[Edit: I issued an amendment (actually, a little more detail) to this post. Click here to see the post]

[Edit by Blog admin: See also the related Incident Management KPI post

Wednesday, 14 Mar 2007

Customer Nick asks for ideas on data he can use as a KPI for Problem Management.

That’s a really good question, and before answering it I’ll refer to the definition of what a Problem is. However, the definition of a Problem is slightly different to what the goals of Problem Management are, namely (taken from the ITIL Service Support book):

“The goal of Problem Management is to minimise the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure…”

In other words, if you ask ‘why do we bother with Problem Management’ the answer is ‘to try to stop Incidents from happening (thereby avoiding their cost and inconvenience)’. Therefore, any KPI should be targeted toward measuring the effectiveness of the Problem Management process – just as Incident Management KPIs have an element looking at timeliness of resolution.

But hold on a minute, it looks like we’ve just described something very difficult. Our ideal KPI would show how many Incidents had not occurred due to our Problem Management process, but if you can get a report from your Helpdesk or Service Desk software telling you how many Incidents have not been logged then all I can say is wow.

I have seen instances where Problem Managers have shown a declining number of Incidents say over a 3 month period, and concluded this is a direct result of Problem Management. All I can say is maybe. Incidents can decline for all sorts of reason such as

  • Investment in the infrastructure, or technological changes unconnected with Problem Management
  • Less business activity (like after a Christmas rush period)
  • Less business or technological change
  • Fewer new employees joining

…and so on. The converse of the examples above can lead to an increase in Incidents, even if your Problem process is bang on the money. Personally, disentangling all these reasons is so hard and unscientific I don’t think it’s a good avenue to follow for anyone.

Instead, I guess we’ve got to use some common sense. Common sense tells us that if we have an effective process in place then Incidents and downtime costs will reduce. So to me it makes sense to focus on ‘is the Problem Management process working?’.

Having described the challenge at length, Friday’s post will describe some actual Problem Management KPIs you can use.