Serio Blog

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. 

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.