Serio IT Service Desk & Helpdesk Blog

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.

• Troubleshooting Connection Issues with the Serio Inventory Agent

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.

Technorati Tags: ITSM, ITIL, CMDB

• More on Configuration Items
• Asset and Configuration Management Basics

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.

Technorati Tags: CMDB. ITSM

• Getting started with a CMDB
• Setting-up a SerioWeb Portal for Internet Use
• Service Level Management for Beginners

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.

Technorati Tags: CMDB, ITSM

• Asset Management or Configuration Management?
• What is the Configuration Management Database (CMDB)?
• More on Configuration Items

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

Chat

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.

Ticker-tape

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.

• Key Performance Indicators (KPIs) for Problem Management
• Locating Incident Management KPIs in Serio

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]

Technorati Tags: ITIL, Problem Management, ITSM

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.

Related White Paper: Problem Management Why and How.

Technorati Tags: ITIL, ITSM, Problem Management

• Some Service Level Management (SLM) Key Performance Indicators (KPI)
• Key Performance Indicators (KPI) for Incident Management
• Problem Management KPIs – Amendment

This post is about an often overlooked feature of the Serio CMDB. Risk Assessment is a formal process of identifying and measuring risks posed to organisational Items – for example the risk of a hard disk crash on a key server, the risk of theft of laptops, the risk of hackers stealing customer data, the risk of someone spilling coffee on a computer and so on.

Risk Assessment helps you to decide on Changes that you need to make to your systems to reduce risks (of course, Change Management naturally complements the Risk Assessment process by providing controlled a way to implement such Changes). Naturally Risk Assessment is a proactive activity – trying to stop the costs associated with Incidents before they occur.

A formal Risk Assessment exercise is a key step in gaining BS7799/ ISO17799 certification. BS7799 requires that you should develop a Risk Assessment methodology which takes into account the value of Items to your organisation and the seriousness of threats.

So far so good. Serio adds value to this by providing a framework for storing and reporting on the results of your Risk Assessment exercise which is geared towards the requirements of BS7799.

The Risk Assessment Process

The Risk Assessment process in Serio consists of gathering information about Items and the risks they are exposed to. This information is stored in the Serio Configuration Database for reporting and analysis (if you’ve ever wondered what the Threats and Vulnerability icons were for, this is it).

The following description introduces the main concepts and stages of the Risk Assessment process. Once you have familiarised yourself with this introduction, please see the Risk Assessment Roadmap in the HowTo guide (distributed with Serio products) for a step-by-step guide to implementing the Risk Assessment process using Serio.

1. Identify organisational Items that must be protected from risk. Such Items may include:

Key servers or network equipment
Key applications, such as web or email servers
Information (Virtual) Items, including databases or files containing sensitive information, such as customer records, product specifications, sales data, eMails, etc.
Services, such as heating, lighting, power and telecoms.

2. Use your knowledge and experience of your organisation to assign an Organisational Value to these Items. This is a matter of answering the question, “On a scale of, say, 1 to 5, how important is this Item to our organisation, in terms a loss of availability, confidentiality, or integrity?” A score of 5 indicates the highest Organisational Value.

3. List the Vulnerabilities of these Items. Any aspect of an Item’s location, function, use, or characteristics which puts the Item at risk should be counted as a Vulnerability. Assign a Vulnerability Level, on a scale of 1 to 5, to each Vulnerability. (A score of 5 indicates the highest Vulnerability Level.) For example:

Exposure of web server to the Internet (4)
Mis-configuration of the firewall (3)
Positioned underneath the air conditioning water storage tank (3)

4. List the Threats posed to the Items. Theft, breakages, hacking, website defacement, viruses, worms, media failure, and security violations are all examples of Threats that Items may face.

Note: Relationship between Threats and Vulnerabilities

There is a link between Vulnerabilities and Threats. For example, the fact that a laptop is portable (Vulnerability) exposes it to the possibility of theft and breakage (Threats). If a computer’s operating system is misconfigured (Vulnerability), it may be threatened by viruses, worms, or unauthorised access (Threats).

Identification of Threats and Vulnerabilities is an iterative process: discovering Threats may lead you to identify Vulnerabilities, and these in turn may reveal further Threats, etc.

5. For each Item, assign a Threat Level, on a scale of 1 to 5, to each of the Threats that you have identified. (A score of 5 indicates the highest level of Threat.)

Two Items may face a Threat at an equal Threat Level. For example, two servers may be equally threatened by hard disk failure. However, where one of the Items is more valuable to your organisation than the other, the Threat to the more valuable Item is clearly more important. To reflect this, Serio calculates the Risk Level associated with a Threat, according to the following formula:

Risk Level of Threat = Organisational Value of Item x Threat Level

For example,

Web Site (Organisational Value = 4)
Defacement Threat (Threat Level = 4)
Risk Level = 4 x 4 = 16.

6. As you gather information about Items, Threats, and Vulnerabilities, you can store it in Serio. You can then use this data you to produce reports or to search for Items which are exposed to unacceptable levels of Risk or Vulnerability. This analysis should help you identify Changes that you need to make to your systems to reduce the risks arising from particular Threats or Vulnerabilities.

Technorati Tags: ITSM, ISO17799

• Introducing Change Management – Some Definitions

I’m going back to the point raised by Peter, as mentioned in this post from last week (specifically Peter has to improve service with a reducing budget, demoralised staff and reducing headcount).

I’ll recap on some of the things I’ve covered:

- The importance of setting yourself specific, real, measurable objectives.
- Avoiding unnecessary complexity.
- How important roles and responsibilities are. This topic is bound up with team structure as well, but I’ll blog about that at a later date.

This blog post will be about shared vision and understanding in IT Service Management, and how important it is that, as a manager, Peter works to achieve this (excuse the term ‘shared vision..’ even though it sounds like something David Brent might bang on about).

Let me start by saying what I would not do. I would not want to be a Moses figure coming down from the managerial mountain with ‘the process’ or with ‘an ITIL vision’ handing out papers, processes and directions. This can engender a feeling of antipathy before you even get started the way that any change imposed in a work setting can do (my experience of working life gathered in the last 25 years is that generally people are resistant to change – even in IT – where technological change is viewed very differently to organisational change). Remember that your staff may think they currently do a great job, even if customers think they do not.

What I would do, and have done in the past, is to persuade that we need to do things better and differently, and to encourage people at all levels to suggest how.

As always though, there is a right way and a wrong way. Don’t ask your staff to write down suggestions and send them to you – the chances are you’ll get almost no response. Many people are intimidated by blank sheets of paper (even me, from time to time).

A better approach is to organise (i.e., chair) workshops where people can suggest improvements. However, organise these after you’ve applied some thought yourself about the problem(s) as you see it, so if the workshop is slow to get started you can prod it into life. Make careful notes during the meeting, and report back promptly afterwards.

At all costs avoid the workshop turning into a festival of moans. The first of these I ever organised did exactly this, with the 1st-line team immediately saying “the network team cherry-pick Incidents leaving behind stuff they don’t like the look of”. As it happened this was true, but with network team members in the room the tone became confrontational.

At the time I handled this badly. What I’d do now would be to re-state the negative in a more neutral way, as in ‘You mean some Incidents you assign to the network team are not being handled as quickly as customers would like’ and try to move onto a more consensual tone.

During these workshops, some people will contribute a lot, others a little or nothing. If you are reorganising and creating new roles (such as an Incident Manager or Service Level Manager) try to reward the most interested and positive with new roles, rather then simply choosing people based on seniority (though I know that can be controversial).

I’ll continue this theme in future posts, looking at some of the specific ITIL disciplines Peter might consider.

Technorati Tags: ITSM, ITIL

• Improving the Chances of Success with a new ITSM Project
• Getting Started with ITSM