Serio Blog

Monday, 08 Jan 2007

A Happy New Year to all our blog readers!

This blog may be the first in a series on the subject of Incident Management – a fundamental part of ITSM. I’m going to start with the basics, and then take it from there.

The first thing I need is a definition, of what an Incident is. ‘Best practice for Service Support’ (pub TSO) very kindly gives us a definition as follows:

any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or reduction in, the quality of a service.

Incidents, therefore, cover a multitude of faults, errors and unexpected events users might experience. An Incident can also be taken as a simple user query like ‘how do I do a mail merge?’ or a password reset request.

Having defined Incidents, it’s worth stating the goal of Incident Management: to restore services as quickly as possible to users, thereby reducing the impact of Incidents upon the organisation. This is not to say that is all we do: there are quite a lot more tasks involved, but this is the ‘output’ or primary goal of the Incident Management process (remember that a general goal of IT Service Management is to stop Incident happening in the first place).

The role of the Helpdesk/Service Desk in Incident Management is key – even if specialist teams (such as network operations or database administrators) happen to be assigned to the Incident. This is because the Helpdesk/Service Desk should ‘own’ the total pool of active Incidents, taking action where required to ensure a timely resolution or workaround for the customer. This is why Serio allows you to have both an Assigned Team and Agent, and an Owning Team and Agent for an Incident – so that the actual ownership of this ‘pool’ of unresolved tickets can be split between members of the Helpdesk or Service Desk.

To illustrate this with an example, you might have a Service Desk agent called John who logs an Incident for a database error. John might have to assign this to the specialist Database team for resolution, but still maintain some ownership (distinct from assignment) for the Incident in question. What John actual does with the Incidents he owns will depend upon his companies’ own procedures, but he might:

  • Intervene and review the Incident at some point before a resolution time (SLA) breach
  • He might manage communication with the customer
  • He might be involved with the further escalation of the Incident

I’ll continue to address this subject in later posts.

Friday, 05 Jan 2007

This is a continuation of the post from a few days ago SNMP for Beginners.

At the end of the post I posed a question about interoperability. How do management applications know the data that network devices can provide, or what their capabilities are? This is where the MIB comes in. Think of a MIB as a definition of what the device can provide, or a menu of its capabilities. If you give the MIB to the management application, it can has knowledge of what the device can provide.

MIB stands for Management Information Base. MIB files are human readable – sort of. They use a programming-like language to declare the data that the device can do. The job of management applications, like our own Command Center tool, is to read these MIBs and use them to access the network device in question.

If you wish to see a MIB, please see the attached file.

This poses a number of questions, like ‘where are my MIBs then?’. Generally they are distributed with the product in question (for instance, on the support CD) or from the vendors web site. However, your device might not have its own specific MIBs, it might simply use standard MIBs – of which there are many. Whatever your device of situation, your vendor documentation is the best placer to start looking for MIBs.

Later in the month I hope to follow-up this post with information about some of the standard MIBs, and explain how they can be used.

Tuesday, 02 Jan 2007

This post is about a technology that Serio uses a lot – SNMP. I will write about SNMP in this blog entry and assume that you have no idea what it is.

Those of us here at Serio that write in the blog have some useful guidelines, the first of which is this: ‘define what it is you are talking about in your own words’. So the first thing is to try to define what SNMP is. SNMP: Simple Network Management Protocol. It’s a way of different devices on a network infrastructure exchanging information, typically between a Management application and a Network Device. At it’s simplest level, think of it this way. Imagine you have a device, say a hub, that is down the corridor and handles a lot of important traffic. On the front of this device is a status LED (flashing light!) that tells you that the hub is OK (green LED) or has a problem (red LED). Now imagine you have a Network Management guy called Duncan, who is interested in this status value. Every hour Duncan gets out of his chair and walks down the corridor to look at the LED.

Pretty soon Duncan gets tired of this, and wishes he could ‘read’ the status value from his computer, or better still have some kind of application (a management application) that can read the LED value for him, and let him know when it goes red.

This is where SNMP comes into play. It’s basically a way for the LED value to be transmitted over the network, and defines a common data structure whereby the management application can request the value of the LED, the hub can send it, and the management application can understand what is being sent.

In other words, SNMP is generally concerned with sending small pieces of information like status values and small strings. It isn’t something you would use for regular traffic, like audio or file data. In fact, most network devices impose quite strict limits of the size of SNMP requests and responses – typically less than 2K bytes.

I’ll post more on this subject later this week. In the meantime, consider this problem: how does a management application know what status information a network device can provide, or what the values all mean?

from everyone at Serio, to all of our customers, blog readers and RSS subscribers, wishing you the very best for 2007.

Jackie, blog admin

Friday, 29 Dec 2006

This is a follow-on post on the subject of CTI in Serio (whilst the earlier CTI posts look at CTI more generally).

Serio CTI depends upon the capabilities of your telephony system (the ‘switch’) completely. It relies on your switch for data about incoming calls – not just Caller Line Identity (CLI) but for information about when events (like incoming call or hang-up) are happening, and getting this information in good time (remember, caller waiting!). Serio CTI relies on your switch for making calls, and for data on the progress of those calls.

So how does all this work? Well it’s all done with something called TAPI. TAPI is short for Telephony Application Programming Interface, an API (a set of function libraries and tools) for connecting a PC running Windows to telephone services. TAPI was introduced in 1993 as the result of joint development by Microsoft and Intel. TAPI supports connections by individual computers as well as LAN connections serving many computers.

TAPI functionality on your switch is what you need in order to work with Serio. Serio supports TAPI versions 2.1 and 3.0. In particular, you need a Telephony Service Provider (TSP). Telephony hardware manufacturers typically provide the TSPs - Serio do not provide these. With some telephony devices there are one or more additional software layers between the TSP and the hardware's native functionality. These are usually referred to as drivers and are installed as part of the hardware/software installation process.

One of the guidelines I have for this blog is this: avoid the use of jargon, acronyms, buzz words and anything else that detracts from the objective of this blog: to help people in practical ways with IT Service Management. However, re-reading when I’ve written here I’ve introduced TAPI, API and TSP and you may be thinking ‘that sounds tough’. Generally, you are looking to your telephony hardware provider to give you these tools and help you set them up – hopefully their packages are quick to install and configure (frankly though, this is not always the case).

It’s not just software you need also. With CTI, I think you only get the most when your Agents (those dealing with customers) have the right hardware – and that means headsets that work with the TSP. So that if they make an outbound call, Serio can simply connect them to the speaker at the right moment. Similarly for inbound calls we can simply connect without the Agent having to handle the receiver. I use a headset and would recommend them strongly for anyone using a computer whilst dealing with customers.

More info: see the CTI Roadmap in the HowTo Guide, part of the documentation distributed with the product.

Wednesday, 27 Dec 2006

This is a continuation of my last blog Telephony in IT Service Management.

Whilst my last blog entry looked at statistics, this blog entry will look at how Computer-Telephony Integration (CTI) can be used to make the job of the Helpdesk or Service Desk easier by discussing some of the common applications.

I’ll start with computer dialling. This is where you have a button on your ITSM tool that says ‘Dial’. You click it and the ITSM tool takes the number from the customer database and dials the customer for you, connecting you on answer. You may be thinking ‘so what?’ but I’ll say this – it is a really good time saver, and something you can very quickly get used to.

Another application is commonly referred to as ‘screen popping’. Whilst computer dialling is concerned with outbound traffic, screen popping addresses inbound traffic. What happens is this: when a customers calls you, the ITSM tool detects who is calling and then ‘pops’ a screen the tells you information about the caller, such as their name, which company they work for, and ideally shows you their recent Incident history – so they can be greeted with ‘good morning Mr Smith – how can I help you?’.

Screen popping works using a piece of data called CLI (Caller Line Identity). This is where someone calling a number makes their number visible. If you have used a mobile phone and observed the caller’s number being shown on the LCD display of your phone, then you’ve seen CLI in action.

What typically happens is this: your telephone system detects the incoming call, obtains the CLI data, and then passes this to your ITSM tool which scans its own database and identifies the caller – and this allows the ‘screen pop’ to take place with the right data.

If you deal with internal customers only then obtaining CLI information is usually unproblematic. If you deal with external customers, then CLI might not be available to you – some companies ‘hide’ their number when making outbound calls (though this unwelcome practice seems to be less common today than a few years ago). Another problem might be a large company applying the same CLI data to all outbound lines from their company, making it impossible for you to tell the actual individual calling.

If you are a Serio customer, you might be asking what Serio can do with CTI. The answer is that both outbound calling and screen popping are supported, but dependent upon your phone system having the right hardware and software capabilities. I’ll post later about what you need for CTI in terms of system requirements.

Friday, 22 Dec 2006

On behalf of everyone at Serio allow me to wish all blog readers and Serio customers a very happy and peaceful Christmas and New Year.
We are closed on 25th, 26th and Jan 1st. If you need help our support on these days simply email support __at__ seriosoft.com and someone will pick it up. Make sure you put URGENT in the title somewhere.

Jackie, Blog admin

Telephony statistics, and telephony integration, is often overlooked in the IT service management mix. In this blog, I’m going to discuss a few aspects of these and how they can enable you to offer a better service for customers.

Firstly telephony statistics. Does your management reporting look at this kind of data? There are a number of key statistics you might want to look at, as follows:

  • Number of rings before pickup
  • Call abandonment rate
  • Distribution of incoming calls during the day

Number of rings before pickup. This how long does it take to get an answer when someone calls, and needs to be handled with a little care. An average number of rings figure is good to have, but you need to take into account ‘spikes’ that might be short-lived but point to unacceptable levels of service. For this kind of analysis it is sometimes useful to express this figure as a simply X-Y plot over time, or expressed with statistical measures such as standard deviation or max/min measures. You’ll typically get this from your ACD system.

Call abandonment rate. This is the number of times a caller gives up and puts down the phone. Apart from an actual count, it’s good to have this figure represented as a time-based graph so you can see if there are problems related to a particular time of day or shift pattern. Again this will come from your ACD system.

Distribution of incoming calls. This is a useful figure to have, as it tells you when your Helpdesk/Service Desk faces its highest volumes. In many cases you’ll see a smoothed day-by-day graph, a ‘twin bell’ shape, with a surge in the early to mid morning period, and again in the early to mid afternoon period. You often have two sources of information for this data – your can use your ITSM tool (Serio users see report IL14 ‘Daily Activity’) or your ACD system. My preference is the ACD system, as this captures all calls, even those made to discuss last night’s football results.

Telephony doesn’t just provide us with management data, useful though that is. You can also integrate your phone switch with your ITSM tool – something Serio has supported for some time. It’s called CTI (Computer Telephony Integration) and I’ll post later about the kind of things CTI can do for you.

In the meantime, have a happy Christmas and pie-filled New Year!

Wednesday, 20 Dec 2006

This post is for a customer fresh from an ITIL foundation course, looking for guidance or help with getting started with a Configuration Management Database (CMDB).

I’ll start with a reminder of what the CMDB is. It is a documentation for your IT infrastructure, describing how various parts (called Configuration Items, CIs) fit together to deliver services to customers. It typically shows dependencies between CIs, and carries a lot of business-related information in addition to the technical data you would expect.

It is an important underpinning resource, used in Change Management for example for performing important tasks such as impact assessment.

There is another discipline sometimes confused with this – Asset Management. This is where you keep lists of computers for reasons such as accounting purposes. In Asset Management you have lists of equipment, but these are typically not linked together – so you can’t use this data to understand how services are delivered to users.

Having given that definition, let’s come back to the subject of this which is getting started with a CMDB.

I’ll write in the form of Do’s and Don’t.

Do: Create your CMDB as part of a wider IT service management programme. In other words, what is your level of IT service management process maturity? Do you have an effective Incident Management process for example?

Do: Think very carefully how you will keep the data up-to-date. This may be your biggest challenge. The answer is to use Change Management to ensure that the data you are spending so much time to create is as accurate now as in six months.

Don’t: Necessarily start with desktop data. One thing we’ve noticed is a tendency for desktop equipment to be the first data entered into the CMDB, but you should ask yourself, particularly at the start ‘is this right?’. I’m not saying this is wrong, but just to stop and ask the question ‘what do I want to be in the CMDB and what is the best place to start’. I’ve blogged about this before in ‘What should be in the CMDB’ but you may want to start with your server infrastructure, particularly if the most important services you deliver to customers are server-based.

Do: Create your data in phases. If you are creating data for a complex infrastructure, one technique I’ve used is to isolate different systems and infrastructure (I’ll call these sub-domains), and to then concentrate on creating a representative model in the CMDB for each sub-domain. Doing this gives you a series of deliverable milestones, and allows you to perform checks and validation on each sub-domain as it completes. You can create sub-domains based in services offered to users, or physical location – whatever makes sense to you.

Don’t: Start before agreeing with interested parties what data will be held. For example, are you going to store warranty information (usually yes)?

Do: Be clear about who owns the data. Usually this will be your Configuration Manager, but it is important that the data has an ‘owner’ who will be responsible for it’s integrity and quality.

Don’t: Leave the ownership of the data to a group or to ‘the team’.

Don't: Limit what is in the CMDB to hardware Items. Instead, remember that CIs can be virtual, representing important entities such as database server instances, software firewalls and web servers.

Monday, 18 Dec 2006

This post is about a really useful feature of Serio – Reminders.

As you might expect, Reminders are there to remind you to do things. You might set them on an Incident to remind you to call a supplier about an Incident they are handling for you, or to remind you about a customer meeting. You can set as many Reminders as you want on any given Incident, Problem or Change (and cancel them independently also).

When Reminders become due, you can be notified in the following ways:

  • An entry in the Serio Journal
  • A Serio Message
  • A Text Message
  • An EMail

Reminders have a number of nice little touches. One of these is that by default, if an Incident on which outstanding Reminders is resolved, the reminders are cleared (there is a setting to change this however).

You can also place Reminders independently of Incidents. All you need to do is click the ‘Reminders’ chapter – this also shows you all the Reminders you have pending.

You set and cancel Reminders by taking Actions. To set a Reminder, your Serio Administrator needs to have done a little set-up beforehand. He or she should have created some standard Reminder Types, and then created two Actions for you – one to add a Reminder, the other to allow you to cancel it later, if you change your mind.

Pages