Serio Blog

Wednesday, 25 Oct 2006

I’m going to return to the subject of the Configuration Management Data Base (CMDB) for this post, prompted by a customer that invited me to look at their CMDB.

ITIL makes a distinction between Asset Management and Configuration Management (the CMDB is what you get from an effective Configuration Management process). I’ll avoid quoting directly but it defines the two thus:

Asset Management: Accounting for IT assets for accounting or managerial purposes. This might include maintaining a list of items so that you know when warranties expire, or so you can perform some routine upgrade planning.

Configuration Management: Provide a logical model of all the Configuration Items within the organisation, showing how the combine and depend on each other to provide services to users.

In practice, this means that the two are quite different.

Asset Management is typified by lists of computers. These generally are not linked together to show much more than the machine and some peripherals attached (such as a monitor or printer). In an Asset Management system, it is sometimes hard to see server equipment amonst all the desktops, and you don’t see ‘virtual’ items such as web server instances or database server instances.

Configuration Management is typified by diagram rather than lists (though lists do exist of course). This is why Serio expresses the CMDB in graphical terms. The diagram shows a variety of items and shows how they link together and depend upon each other so that, for example, you can see the effects of shutting down a database server. The CMDB will typically have tangible and virtual items on it like I’ve mentioned above, and will show how items combine together to deliver customer services.

I’ll probably post more about this on Friday, but I’ll pose the question: how can you support an IT infrastructure that is not documented?

Friday, 20 Oct 2006

If you are thinking of introducing Change Management to your Service Desk/Helpdesk, it is worth asking the question ‘are we ready’.

It is a good question to ask because Change Management requires a degree of process maturity, and presents those taking up Change Management with all sorts of technical, procedural and cultural issues to overcome.

Assess yourself honestly against the following statements – record if the statement is mainly true or mainly false. As in all things, there are no hard and fast rules – you may have a successful Change Management process implemented successfully with none of these things being true. These are just based on my own experiences and observations.

  • We have a mature and effective Incident Management process. It is written down in a concise and useable form.
  • We have a mature and effective Problem Management process.
  • We have an Incident Manager and Problem Manager. We appreciate the importance of a Configuration Management Data Base (CMDB) in supporting effective Change Management. We are preparing to introduce one shortly after our Change Management process ‘goes live’.
  • We have a shared understanding of the problems we are trying to solve by introducing Change Management. For instance, there are not whole teams resisting the process, or who think that my organisation does not needs a Change Management process.
  • There is widespread support for the introduction of Change Management.
  • The IT function is quite ‘well organised’ within my company. For instance, there is a clear team structure and a clear understanding of responsibilities.
  • Our managers and team leaders are actively supporting the introduction of Change Management.
  • We have identified a person who we wish to act as our first Change Manager.
  • We have identified at least one person who will be our Configuration Manager and who will ‘own’ the CMDB.
  • We don’t have lots of different groups holding lots of important data in different places, such as access databases and spreadsheets. Our supporting data is easy to access and is within the ITSM tool.
  • We’ve picked one aspect of our IT services to be a pilot for Change Management. We want to learn from this experience before trying other aspects of the IT function with CM.
  • We understand that ITIL Change Management is not prescriptive in its approach (it does not tell us exactly what to do), though it gives us sound and sensible advice.

So how did you do?

More than 10 mainly true: You are probably OK to start thinking about your Change Management process – you are likely to succeed.

More than 6, but less than or equal to 10: You may not have sufficient process maturity or ‘buy-in’ from the rest of the organisation to succeed.

Less than 6: Hmmm. If you are still planning to go ahead, then I think you are brave. It might be that you don’t have much process maturity, and have insufficient buy-in. You may be working in a very informal and not customer-service focused environment.

Edit: Verso also have a related post on the subject of 'the people factor'.

Thursday, 19 Oct 2006

In my last post (see below), I began looking at the question of what and how many Service Level Agreements (SLAs) you need with a recap of what an SLA is.

Today, I’ll introduce a real world example, which I will use in the next post to illustrate the sort of decisions involved in designing your own SLAs.

Example: XYZABCD PLC provide services to the public seven days a week between the hours of 8am and 8pm. This operation is supported by an internal IT Service Desk.

There is no formal SLA between the Service Desk and the business, and the Service Delivery Manager is being pressed to provide one. Internally, however, the Service Desk do operate an informal SLA, and hope to put this on a formal basis.

Staff at the company can log support Incidents with Service Desk by telephone during working hours (8am-8pm Monday to Sunday) and by email or web outside these hours.

In fact, however, the engineers capable of resolving any faults are only at work between 8am and 5pm Monday to Friday. Outside those hours, the Service Desk staff manning the phones are able to resolve certain straightforward types of Incident, such as password resets, and can offer simple workarounds, but must wait until an engineer is in the office to deal with more complex problems.

Service Desk staff prioritise Incidents based on Impact. Non urgent requests or queries are given a low priority and may be dealt with within a couple of days. Faults that are causing inconvenience to user, but not preventing them working, are given a medium priority and must be dealt with the same day if possible. If the user cannot work, this is treated as a high priority and must be dealt with immediately.

Additionally, there are always a duty engineers who may be called in after 5pm when there is a critical fault affecting the company’s ability to provide service to the public (for example the failure a key network component). The Serio Command Center detects and raises alerts about such faults and sends text messages to the duty engineers. Should such an event occur the duty engineers must attend as quickly as possible, day or night. The Service Desk wants to ensure that key services are always available during opening hours.

Friday, 13 Oct 2006

Serio allows you to create multiple Service Level Agreements (SLAs). But how do you know what and how many SLAs you need, and is it a good idea to have multiple SLAs?

Over the next few posts I’ll be looking at these questions by considering a real world situation where an SLA must be designed, and the decisions taken in designing it.

I’ll start with a reminder of what a Service Level Agreement is, and what it is not.

A Service Level Agreement is an agreement with your customers describing the minimum levels of service they can expect from the Helpdesk/Service Desk. As such it may include such things as the times during which the service is available (e.g. 9-5.30 Monday to Friday, or 24/7), target response and resolve times for Incidents of different priorities, and levels of availability of IT services, such as email and key applications.

Key Concept: A Service Level Agreement should make levels of service predictable from a customer’s point of view.

For example, the Service Level Agreement may say things like: “A high priority Incident is an Incident that is preventing you from working, or seriously disrupting your work – for example, if your workstation or an important software application you use is not functioning. We aim to resolve 95% of such Incidents within 2 working hours.”

A Service Level Agreement is not meant as a direct measure of performance of Service Delivery staff and you should not design SLAs to measure Agent performance. (Of course, Helpdesk/Service Desk performance must be measured against the SLA, but the SLA’s main function is enable customers to predict the level of service they will receive, and the latter must the principal consideration in designing your SLA.)

In the next post I’ll introduce a real world situation requiring an SLA to be designed, and in subsequent posts at the decisions involved designing the SLA.

Thursday, 12 Oct 2006

If you took the Helpdesk/Service Desk Metrics Health Check and made a note of your score, here is my take on the scoring bands.

40 or more

Super Hero. Take a bow. You work on a wide breadth of data, and are on top of your management reporting. You probably have days where things go wrong, but on the whole you provide a very professional and effective service to your customers.

39 to 24

Prize fighter. Very good performance, but with room for improvement. You need to expand the range of data that you use somewhat. However, your reporting is still probably above average. Try setting yourself some management objectives (such as improving first-time fix rate) and then seek out the data you need to help you deliver and monitor this.

23 to 8

Mr Average. You use some data, but there is a lot of room for improvement here – you simply are not using as much information as you could be. See the white paper on our website called Service Desk Metrics, and then prepare a project plan for yourself. Using more data will help point out where service improvements are needed and can be most cost-effectively made.

7 or less

Grapecrusher. You have barely got started with IT Service Management, and are either not reporting at all, or run very few reports. Right now you have no data as such to make decisions with. See the white paper on our website called Service Desk Metrics, and then prepare a project plan for yourself – do this as a matter of urgency!

Monday, 09 Oct 2006

One of the things I help customers with a lot is reporting. In essence, helping people choose what ITSM statistics to examine, and then helping them interpret the data and use it to make management decisions with – something that sounds rather easier than it is for those getting started with ITSM.

I’ve prepared a somewhat light-hearted survey for you to take below to assess the quality of your own reporting. Simply read the statement and then make a note of the score for the best response available for you.

‘I run reports and then frame a text summary of the data available which explains my own conclusions and future actions’

  • I just print them and send them direct to customers (score 1)
  • I sometime do this (score 2)
  • There are reports? (score 0)
  • Yes, I do this every week or month (score 5)

‘My reports focus mainly on Incidents logged and resolved, broken down in different ways’

  • Yes that is true (score 2)
  • I use this data and quite a few other streams as well (score 5)
  • I don’t report on Incidents logged at all (Score 0)

‘I report on the number of first-time fixes made by my Helpdesk/Service Desk’

  • Yes (score 6)
  • What is a first-time fix? (Score 0)

‘I report on responsiveness – how soon we contact customers after reporting a fault’

  • Yes (Score 5)
  • I just report on resolution performance with respect to my SLA (Score 2)
  • I ignore SLA data, my customers don’t care about that (Score 0)

‘My reporting uses Causes for Incidents that we resolve.’

  • No, I’ve never got round to defining any Cause data (score 0)
  • Yes I run reports using Cause data (score 4)
  • Yes, I run reports using Cause data & I use this data to reduce Incidents (score 5)
  • Causes are for wimps - I have a Proactive Problem Management framework in place (score 6)

‘I run reports that produce statistics for both Team and Agent performance. I use this info to see how Incidents move through to resolution.’

  • No my customers are not interested in this (score 0)
  • Sometimes, when I think I have a problem (score 2)
  • Yes always (score 5)

‘My statistics include telephone stats such as call abandonment and number of rings before pickup’

  • Yes (score 5)
  • If we pick up the phone too quickly customers phone too often (score -1)
  • No I never thought about this & don't report on it (score 0)

‘My reports include a section on Major Incidents where I report what Major Incidents occurred, and what we have learned from them’

  • We are too busy fixing the Major Incident to record it and report it (score 0)
  • If I report on Major Incidents we will look bad (score 0)
  • Yes always (score 5)

I’ll write on what you can conclude from your scores in my next post. In the meantime, add up your score.

Edit by admin: You can rate your scores here. We also have a white paper entitled 'Service Desk/Helpdesk Metrics - Getting Started' you can read here.

Friday, 06 Oct 2006

Ever wished you could highlight High Priority Incidents red? Or Hardware faults blue? Here's how you do it.

  1. Go to your list of Incidents, Problems or Changes.

Serio Incident List

    ​Figure 1 - Incident List

  1. Alt-Click the data item you wish to highlight by. In this example, I want to highlight by Priority, so I Alt-Click Priority.This will bring up the row highlighter dialog.

Data Highlighter

Use the highlighter to specify your colours and styles. I will choose a red background.

 

 

 

Figure 2 - Data Highlighter

 

  1. When you click 'OK' this is what you see. 

Highlighted High Priority Incidents (in red)Figure 3 - Highlighted High Priority Incidents (in red)

 

  1. You can set multiple highlighting options - Serio evalutates them in the order you leave them in the list.
  2. Lots of screens in Serio can be customised like this - just try Alt-Click.

This will (hopefully) wrap-up my previous Callback posts.

Recall that I have covered how you can use display columns in Serio to view if a Callback is outstanding on an Incident? One thing that I should have added is that you can also query for Incidents with Callbacks that are due, and you can use the SLA Performance Dashboard (2nd dial) as well.

Placing Callbacks

Serio Agents: When you take this Action you’ll see your Callback Calendar (below). Simply use this to book your upcoming Callbacks by clicking a square.Callback Calendar

Figure 1 - Callback Calendar

Setting the system so that you can Book Callbacks, and then Flag the Callback as Taken

Experienced Serio users will probably guess that it is all done through Actions – and you’d be right.

Serio Administrators: At the very least if you want to start using Callbacks you need an Action called ‘Book Callback’ and one called ‘Callback Taken’. When you set-up the Actions, look at the possible Action Extensions available: amongst the options you’ll see

  • Book Callback
  • Flag Callback as Taken

Use these as appropriate for the two Actions you are creating.

Setting the system so that eMails can be counted as Callbacks

Serio Administrators: It’s very easy. Simply edit your ‘Send eMail’ Action so that it has the ‘Flag Callback as Taken’ Extension. It’s probably best to make this conditional – use the ‘Ask the Agent’ option, and use this question: ‘There’s a Callback outstanding – do you want to flag this Callback as being made by this email?’.

Getting Callback Notifications

As the time to make a Callback approaches, and the Callback has not been made, Serio will automatically send a reminder to the Agent currently assigned to the Incident. You can also configure the Serio Escalation Engine to send you emails, text messages and Serio Messages as a time of your choosing before the Callback is due.

Wednesday, 04 Oct 2006

This is a follow-on from my last post ‘I’ll call you…later

The problem I’m addressing is making sure that we call our customers back when they are expecting it, which means

  • After they have reported an Incident to us (Serio calls this the Primary Callback)
  • Calling back when we say we will, or when the customer asks (Serio calls these Secondary Callbacks)

I’m often asked if emails count as Callbacks. The answer is Yes, provided they are written by a human and are not ‘automated’.

I mentioned in Mondays post that the Helpdesk/Service Desk needs to get some help from the ITSM tool, so what follows aims to give you an overview of Callbacks within Serio. Most of what follows applies to Incidents, but it’s just as easy to apply to Problems and Changes.

Seeing what Callbacks are booked, and whether-or-not they are overdue

You do this through choosing the right columns when viewing Incidents in your ‘Selected Incidents’ list (you knew you could change the columns you see, right?). Specifically, you need to add these columns:

  • Callback Outstanding (Any)
  • Callback Reason
  • Callback Due Date/Time

Serio Query - Selecting the right columns

Figure 1 - Setup picture

​[Callback Outstanding (Any) is an interesting one, it shows blue for Callbacks we’ve booked, and red for Callbacks that are late.

When you use these columns, here is what they look like Serio query result

 

In figure 2, Incident 2081 has an overdue (late) Callback shown by the red tick. Incident 2096 has a Callback booked for 10th October which is not due yet. The other Incidents have no Callbacks set.

 

 

 

 

 

 

 

Figure 2 - How the columns show when used

I’ll post on Friday how you can actually set and manage your own Callbacks. If you are impatient, look for the following book in the Serio HowTo guide (Administrator How-To/Managing Issues/Callback) – this tells you in some depth what you need to do.

Monday, 02 Oct 2006

‘I’ll call you tomorrow to let you know how we are getting on’.

It’s easily said to a customer reporting a problem, and if the number of Incidents that you staff are dealing with is small (and the environment no overly hectic) it’s not so difficult to do.

However… once the number of Incidents active for each member of the Service Desk/Helpdesk rises (say above 20), the likelihood of that callback being made starts to dip alarmingly. If Incidents are being re-assigned to specialist teams in the meantime, the likelihood drops to ‘not very likely at all’.

Let’s ask ourselves this: does it matter? After all, our Service Level Agreement (SLA) measures the timeliness of the initial response. However, that is just the initial response – what about Incidents that take longer to resolve? My experience is simple: regular communication with customers is vital, and too important to be left to chance.

I’ve posted before that good SLA metrics don’t necessarily mean happy customers, and I think this is another instance. For the most part customers remember if you’ve promised to give a callback and will look forward to the call. If it does not arrive, you’ve tarnished your Helpdesk/Service Desk’s reputation, with many customer’s drawing a conclusion that you’ve ‘forgotten’ about their Incident and are not working on it which is often not the case.

So, what do we do? This is an area where you have to rely on your ITSM tool to help you, and my next post will cover this for Serio users.

If you are a Service Delivery or Service Level Manager you should consider what statistics you have available for monitoring callback performance. If you have none, I would suggest this is something you need to address as a matter of urgency.

Pages