Serio IT Service Desk & Helpdesk Blog

If you or your colleagues receive work emails through Blackberry handhelds, the chances are your company is using a piece of software called Blackberry Enterprise Server (BES).

BES provides the link between your company’s mail server (e.g. Microsoft Exchange) and the mobile network (T-Mobile, Vodafone, etc.) that actually delivers and receives emails from handhelds (see diagram).

If this link is broken, no-one will be able to send or receive work emails through their Blackberries.

It’s clearly in the interests of Service Delivery managers that the availability of this vital service is continuously monitored, so that Service Desk staff know about any problems before users do. Additionally, if you can report at the end of the month on the exact periods of downtime experienced and the percentage availability achieved, you have valuable information for improving user experience of the service.

The Blackberry Enterprise Server Plugin for Serio IT Service View helps you monitor and report on key indicators of the health and availability of your Blackberry Enterprise Server.

Connection to the SRP Host

In order to send emails out over the mobile network, your Blackberry Enterprise Server periodically connects to something called the SRP Host. You’ll have entered the address of the SRP host when you first set up your Blackberry Enterprise Server. You can see what the SRP Host address is for your country by going to the Blackberry website.

The BES Plugin for Serio IT Service View monitors the ability of your Blackberry Enterprise Server to connect to the SRP Host. Since no connection to the SRP Host effectively means no service, IT Service View changes the BES device status to Red (Unavailable) and, if desired, sends out email notifications.

For users of Serio IT Service View Pro, these periods of downtime will appear on scheduled Downtime and Availability reports sent to managers via email.

Build-up of Undelivered Emails on the Blackberry Server

Another indicator that there may be a problem is a build-up of undelivered emails on the BES. Again, the Plugin can notify you when there are an excessive number of such undelivered emails. As soon as the number rises above a threshold you define, IT Service View will alert you.

Using other Plugins to Monitor BES

Other Plugins for Serio IT Service View can provide valuable information about problems elsewhere that may be affecting your Blackberry Enterprise Server.

For example, use the Exchange Plugin to monitor the health of your Microsoft Exchange Server. Use the Windows 2003/2008 Plugin to monitor the Windows Server on which BES is running, or to check that Blackberry services are running correctly and restart them if not.

Technorati Tags: Monitoring, Blackberry

• Monitoring an (Ubuntu) Linux Server with Serio IT Service View
• Using Serio to obtain Availability Statisics
• Serio IT Service View WMI Troubleshooting Checklist

I’ve spoken to a couple of people today who are planning to take the ITIL V3 Manager Bridge Exam (I blogged about exams back in 2007).

Vinod Agrasala has recently taken (and passed) the exam and has written a few tips for those taking the exam.

Is someone in their 40’s old for the IT industry? Maybe. Whatever the answer to that is, whenever someone says

‘[insert technology here] will revolutionize the way companies use technology and IT departments work’

my immediate response it to yawn and move on to the next article, or switch the TV off. I’ve seen it all before.

Does anyone remember the Network Computer, and if so have you seen one recently? No neither have I.

How about WAP? BT spent over £1M marketing this rubbish as the next wave of mobile internet.

I still think mobile (handheld) Internet is over-hyped as well. Sat in Central Park NYC a couple of weeks ago I tried to find out what exhibitions were on at the nearby Museum of Natural History and failed, and couldn’t get the correct address for Bloomingdales for my wife either. The problem was none of the websites I wanted to visit worked with my Blackberry. They had a ton of Flash and Javascript and were completely inaccessible and unusable with my tiny device (on the other hand, my ASUS eee is a small but perfectly formed piece of usability).

But I didn’t want this to turn into a rant.

What I do want to talk about is ‘Cloud computing‘ and how it is going to affect the IT industry over the next few years. In case you’ve been living in a bunker for the past few years, it is claimed Cloud computing will revolutionize the way companies use technology and IT departments work.

Firstly I’ll try to define what ‘Cloud Computing’ means for business and Helpdesks/Service Desks. Right now you maybe manage an Exchange Server – you provide the server platform, install the software, patch it and install it. With the Cloud paradigm you get another company to most of that for you, delivering just a service, not a server, to you the consumer. Patching, security, Availability Management and Capacity Management, backups, recovery all become the responsibility of the provider of the service. You do a bit of configuration, and that’s it. The Cloud part simply refers to an abstraction of delivery – how the service delivered is opaque to us.

Take another example. Maybe you have an Intranet site – one you bought, or one you home baked. A Cloud solution might be to replace it with a Facebook group (I know a company that have done this and it’s great).

Right now, provision of almost any type of system from word processing to sales order management to warehousing is available this way (though with varying results, have you tried to use the Google word processor recently? It’s pretty poor).

So what does all this mean for the IT department? It’s tempting to ask Can you sack your IT department? as Mary Branscombe asked last month, and whilst I don’t think something so radical is on the cards my opinion is there is real change coming, it will affect us all, and that this is not another case of over-hype.

I’ll follow this post with thoughts and comments next week.

Technorati Tags: IT Service Management, ITSM, Cloud computing

• More on ‘The Cloud’ and what it means for Us

I’m prompted to write by this post by Jeff Dray over at Techrepublic on the subject of getting out and about once in a while – working temporarily in other (end-user) departments and locations.

My own experience is it can be very worthwhile, particularly if relations between the Helpdesk/Service Desk are a bit stained at times.

My own experience of this was after I’d taken over an IT Manager type-role at a Call Centre back in the 1990’s. The sales team (i.e., those people actually taking orders and enquiries from customers, remember there were no Internet online shops back then) hated the IT group of 8 staff with a passion, and were not slow in showing this to anyone and everyone in the company who would listen. The sales order processing system I inherited worked after a fashion, but had a tendency to lose orders – not many, but enough to cause a steady stream of calls from customers saying ‘where’s my stuff?’.

The root of the problem was that they felt that their problems and issues were not taken seriously enough, and dealt with quickly enough. On the IT side, the IT team was constantly struggling to keep-up with a constant stream of new campaigns.

It was the sales team that suggested that members of the Service Desk be seconded onto the phones, and to be honest their mood was such I thought it was better not to say no – regardless of how busy we were.

Over the next few weeks each of us took a 3-day stint as a sales representative working on different campaigns.

As it turned out, the sales team were right – we didn’t take their issues seriously enough, and we were not dealing with them quickly enough. The problem was that customers, not surprisingly, are not prepared to wait, get agitated and angry – and these had to be handled with the sales team, increasing stress levels all round. In many cases attention tomorrow was no use – it had to be today, often ‘right now’.

The interesting thing was that members of IT coming back to their regular jobs invariably said something like ‘we’ve got to do something’ or ‘no wonder they are always on the warpath’, and had a lot of useful suggestions as to how we could improve things until the sales order processing system was replaced at the end of the year.

The extra insight allowed changes in attitude and working that had a quite positive improvement, despite the high pressure nature of the environment.

One of many areas of change and development in ITIL V3 has been the Service Catalogue, something that I’m going to blog about today. This post is targeted at those new to Service Catalogues, and I hope I’ll make the standard text somewhat less abstract.

First a recap on what the Service Catalogue is. It’s a portfolio of services that is offered by the IT Service Management function to the business. It defines the business functions that use these services and how important they are, it defines the costs of these services, who uses them (which can be individual users, departments or companies), and ideally attempts to define some measures about the quality of service that can be expected.

Some of advantages for companies taking up IT Service Management for the 1st time listed below, but I’d single out the change in focus from being a reactive service desk to one whose culture is geared towards service provision.

There are two parts to a Service Catalogue: The Business Service Catalogue, and the Technical Service Catalogue.

Business Service Catalogue (BSC)

Think of this as the strategic view – ‘the what’. It describes the service, the business functions that it supports, and the user groups that use it. This is the part of the Service Catalogue you are most likely to show to customers. You might include in the BSC:

• Cost of the service (to users), and how paid for
• Service Level Agreement Information
• User groups using the service
• Quality measures or KPIs

Technical Service Catalogue

This is the implementation view – ‘the how’. This is where we describe, for each Service listed in the Business Service Catalogue, how the Service is put-together or delivered. Your Technical Service Catalogue might include:

• Links and references to other services which are essential for delivery of this service
• Configuration Items (http://www.seriosoft.com/Blog/?p=14) which will be pieces of equipment, software, servers and so on.
• Startup and Shutdown procedures
• Recovery and fallback information
• Key support contracts and contact points

Example Business Service Catalogue Entry

What follows is a simple, cut-down example of a single entry in the BSC, in the hope of making things less abstract.

In the sales-order system shown below there would be a web component, taking orders directly from customers. In many cases these Services (which really are subsystems) are actually shown as Services in their own right, with their own SLA and BSC entry. One of your jobs in developing the Service Catalogue is to define these boundaries intelligently.

Service Name: Sales Order Processing System (informally known as TOPS).

Description (Overview): Provides functionality to take a small-value order from a customer, typically less than £250, either via telephone or the on-line shopping website, process payment, allow the product to be picked and packed at the warehouse, and sent to the customer.

Special Notes: Outbound calls are not part of this service.

User groups:

Sales Order processing Agents (20 approx).

These Agents handle customer sales enquiries, complaints.
Business function: Processing of high volume, low value orders.
Main user contact: {show name and contact details}

{List the rest of the user groups}

Third Party Support Details:

{ Record details of any 3rd-party supplier contracts, including terms of service and contact telephone numbers}

Service Level Requirements:

• Minimum transaction time, selection of single widget item into sale: 0.5 seconds
• Minimum credit card authority: 5 seconds
• Minimum pick/pack process selection: 10 seconds
• Minimum order commit and confirm: 3 seconds
• Availability requirement: 08:30 to 17:30 Mon-Fri, availability target 99.5%
• { Other elements of your SLA might be included, as you’ve negotiated with the customer}

Cost of Service

{ Describe how the service is funded, either centrally from overheads, directly from the user group, per transaction and so on}

Monitoring

{ If you have established automated or manual monitoring of the Service, then describe them here.}

Reporting Cycle

{ Describe how often reports will be produced, who they will be created for, and what the reports will show. You might want to define Key Performance Indicators for the Service here. }

Benefits of Having a Service Catalogue

• Focuses IT Service Management teams onto deliverable Services for Customers
• Provides a central resource for everyone in the organisation regarding the services delivered, how they are used, their importance for customers and levels of quality expected
• Documents minimum quality and service levels for both the benefit of customers and IT service delivery staff

Hopefully, I’ll follow this with a post on where this information would be stored in Serio.

Technorati Tags: ITIL, Service Catalogue

• The Consumer Future of Business IT

This is a follow-up post to Estimating the Cost of Incidents. I wrote then that if you are going to make such an estimation, you need to look at costs to the business, and the costs of resolving the Incidents (i.e., the cost of the IT function). The previous post dealt with costs to the business, so this post will address something not often mentioned – the cost of the Incident Management and resolution service.

Factors to Consider

Throughput (t) – either the number of Incidents logged or resolved in a month. Take a typical or average figure.
Team composition – The people involved in Incident Management and Resolution.
Time Spent Estimate (p) – Each member of the team might have a percentage to indicate the amount of time they spend on Incident management activities. Some staff will be 100% devoted to this task, others not.
Capital Expenditure (c) – The Incident Management team will have a degree of capital expenditure associated with them – computers, desks, ITSM system and so on. This expenditure will generally depreciate, and you can use this annual depreciation in your calculations. You can usually obtain this information either internally from the Helpdesk/Service Desk itself if you have a functioning Asset Management function, or from your accounts team. Use an annual depreciation figure.
Average Salary (y) – The average salary of those involved in IT management will be needed. Don’t try estimating different worker levels, just use an average figure. If in doubt use your own salary as a guide. Use an annual figure.
Overheads – When employing any group of workers, you have to pay for a bunch of other stuff like office accommodation, training and so on. If you don’t know what figure to choose, make it 30% (this is the figure I’ve used) of your salary, as this is a generally accepted guide. Again, use an annual figure.

Blending all of the above into the mix brings us to a formula you can use as a cost-per-Incident-per-month (CPI) for delivering the Incident resolution service. I’ve broken the formula down into two parts to make it easier to read.

1. Staff Costs, pa

This is easiest if you use a spreadsheet. Make one row per Incident Management employee as follows. The numeric figure is (p) from above – percentage of time spent in Incident management and resolution.

Joe Bloggs b = (y / 100) * 90
John Smith b = (y /100) * 100
Paul Barnes b = (y / 100) *50
…
s = sum of all b. This represents annual staff costs attributable to the process.

2. Cost per Incident

This is the figure we’re after, a cost per Incident

CPI = ( s + (s * 30/100) + c) / (12 * t) )

Odd things thrown up by this formula

1. The cost per Incident will almost certainly go up if you have a quiet month with fewer Incidents, as most of your costs will be fixed or semi-fixed. This may be offset by a reduction in impact costs associated with Incidents, as mentioned out in the previous post. Whether or not you can measure that so directly is difficult to tell.

2. It may be that the cost of Incident impact is dwarfed by the cost of the Incident resolution service. However, no rational person would jump to the conclusion that it is cost effective to close or diminish the Incident management service – would they?

Technorati Tags: ITIL, Incident, Helpdesk

• Estimating the Cost of Incidents
• Change Management Scope and Cost Justification
• Supplier Management – Key Steps in the Process

I’m asked by a customer through our support service here at Serio:

How do you estimate how much all of our Incidents cost the business? Any pointers you can give? I’ve been asked this by our IT Director.

I’ll start by saying this is almost impossible to do retrospectively, and I’ll go on to explain why shortly.

It’s worth noting there will be two cost streams in any such calculation: the cost to the business of the Incident itself, and the cost of providing the service to resolve the Incident. Both of these might be very tricky to pin down, particularly the first one – which is the subject of this post.

I’d also counsel against providing ‘junk’ statistics just because someone asked for them.

Cost to the Business of the Incidents we Log

Let’s start with Major Incidents. Because Major Incidents usually

• happen infrequently
• have significant business impact
• and affect groups of users we can more easily identify

it is usually much easier to assess their business cost by assessing lost production hours, loss of profitability, damage to reputation and so on. For a full discussion about this, including formulae you can use, see our Availability White Paper.

Whilst the above can take care of a small handful of Major Incidents, what about the rest of your Incident workpool (which I’ll call Routine Incidents). Routine Incidents in my definition range from tickets affecting a desktop computer to a stuck mouse. How do you assess the financial cost of these to the business?

Retrospectively, I don’t think you can do that easily, if at all. The fact is that some Incidents will have no cost (someone wishing to upgrade to Firefox 3 or get their screen cleaned), some will have a cost, but a cost quite difficult to calculate because it is connected with intangibles such as lost business opportunity. Aside from going through each Incident individually, it’s hard for me to see any system that would deliver meaningful (as opposed to made-up-on-the-spot) statistics.

Going forward, there is something you might be able to do. In the same way that Cause Categories are applied to Incidents when they are closed, you might also apply a cost code which would be a way of approximating the actual cost of the ticket. The person responsible for setting the ticket as resolved could set this value, or it could be an off-line job for the Helpdesk/Service Desk. In either case it’s going to be a value judgement. I can think of about 3 ways of creating and using such a code in Serio.

For example, you might decide upon 5 cost codes

0 – No cost, zero
1 – £0-£5
2 – £5-£20
3 – £20-£50
4 – £50-£100
5 – £100-£200

…and then all you need to do is run a report aggregating these, choosing either the low or upper value from each cost code to come to an actual cost.

I’ll post about calculating the cost of the Incident Resolution process later in the week.

Technorati Tags: ITIL, Incident, Helpdesk

• Estimating the Cost of Incidents – The Incident Management Process
• Change Management Scope and Cost Justification
• Handling Major Incidents

Something two of our customers have started recently, and been kind enough to share with me, has been the placing of Test Calls on a Helpdesk/Service Desk. I’ve used their comments to prepare this Blog post (so thanks!)

By Test Calls, I mean that a number ‘fake’ or ‘manufactured’ calls are placed anonymously and a number of aspects of the call analysed.

For me what is interesting is that I’d not encountered any company that regularly placed Test Calls up until two years ago: since then there has been quite an upswing.

The reason is an increased value being placed on intangibles – stuff you simply can’t measure directly with normal metrics, and a desire to more fully understand the customer experience. You’ll find more about this below, but by intangibles I mean clarity of communication, courtesy, and so on. Whilst at the moment I’m seeing this in the ‘paid support’ world, it probably isn’t long before it crosses over into the in-house support function.

Some Tips for placing Test Calls

1. Announce What You Will be Doing. Make sure everyone knows Test Calls will be made, and from what date they can expect them (but there’s no need to tell them on what days, or announce them beforehand).

2. Keep it Legal. If you are recording the conversation, you will may need to advise staff of this – check the legal situation regarding disclosure of recording in your country. Regardless of the legal requirement, I think you should advise of recording as a courtesy.

3. Set your goals clearly. Make sure you are clear about what ’success’ factors you are looking for in your test call. Success factors might include:

• Courtesy
• Speed of answering (if you don’t have independent statistics from your telephone system)
• Ability of the Service Desk Agent to speak clearly. For instance, did they control the call? If they are using headsets, is the mic correctly positioned? Was there an excess of background noise?
• If you have a script was the script followed?

The closer you can get to a scorecard you complete at the time of the call the better. Try something that allows a simply 1-5 score to be recorded against each call aspect, along with and caller’s notes.

4. Keep the call simple. Your best bet is not to make a call that involves something elaborate, but rather something simple – maybe a password reset, or a printer problem – something you might hope would be dealt with well.

5. Make Sure You Explain Why. Be clear about why you are placing the test calls – for quality and training purposes. Be clear that poor results will result in training as opposed to dismissal.

6. Create a Test Call Calendar, so that your Test Calls are placed at different times of day, and at reasonable intervals, and ideally when different members of staff are taking calls.

7. If something unsatisfactory is detected and a follow-up required, make sure you do this within 24 hours of the test call being placed.

Technorati Tags: ITSM, IT Service Management, Customer Service

• Incident Management – how good are you at taking calls?
• Incident Management – how good are you at taking calls? (cont)

I’m asked to write about how Group Companies are incorporated into overall IT Service Management. Specifically, what happens if your own company either buys another company or starts another company that will be run as a separate entity (with it’s own capital, directors, and premises)?

Of course, I can’t answer the question for you – but what I can do is consider some of the issues you might have to work through. Some are conceptual, some practical.

Sometimes we at Serio are asked ‘how should we incorporate them into Serio?’ when the real question is ‘How do they fit-in in terms of IT Service Management’.

I’ll refer to the newly acquired company, or the new start-up company, as ‘NewCo’.

What is the ‘Strategic Vision’ for IT in the whole Group?

There may be a Strategic Vision that outlines the approach you take – these usually originate at group Director level. It may be that this will guide you on what you need to do (for instance, many companies centralise IT services, others have a horror of ‘Head Office’ services and want everything as close to the business and customers as possible). If you are lucky there will be such a guidance, but there is every possibility there won’t – at least in my experience.

Will NewCo Management want control over their IT?

The directors of NewCo will be focussed on creating or developing their business, and may see IT as a critical component of their strategy. If so, any suggestion of incorporation of their IT service delivery into existing ITSM services might be unwelcome. Remember that it isn’t necessary for them to be tightly integrated in terms of IT to be able to send and receive emails, and share files, with the rest of the group – you can set-up web portals specifically for this purpose.

Will NewCo have its own IT Service Management function?

First of all, is there any NewCo IT Helpdesk or Service Desk? What you are trying to assess is if there is any local function to integrate in the first place. The important thing is how such a service is perceived by the directors of NewCo.

How much interaction between your existing IT service management function and NewCo will there be?

…or phrased another way, ‘how much will NewCo use group services’. Try and imagine how many support tickets might need to be passed between the two groups – but be realistic. How much will NewCo and your own ITSM group need to work together (be realistic, and resist the urge to over-estimate).

What are the politics of the situation?

This is most poisonous aspect, particularly in cases where NewCo is an acquired company rather than a start-up. As soon as anyone mentions ‘incorporation’ or ‘merger’ of IT services people see their jobs and (most importantly) their prestige to be under threat, any hope of co-operation can go out of the window. People start firing-off their CV’s, attitudes become negative, it gets harder to achieve any kind of consensus. Alternatively, you might find two groups of people whose skills complement each other.

Technorati Tags: IT Service Management, ITSM

• Start-ups, Acquisitions, and your ITSM System
• Making a Start with ITSM Reporting
• First SLA? Some Statistics to start with

This is a follow from the post last week, continuing the topic of Team and Agent metrics.

Quality of Completion – An interesting an often overlooked figure connected with Incident Management. How many tickets are re-opened after closure? Whilst it might be that there are legitimate reasons for re-opening a closed ticket, a high number might suggest issues with quality control (closure before it’s really closed).

First Time Fix Rate (FTFR) – For call-handling teams, you can look at this figure both by Team and by Agent – either with examining actual results achieved, or by looking at a 3 month trend.

Speed of Resolution – For Helpdesks and Service Desks you might have underpinning contracts and might want to examine performance from a time perspective – either resolution against target or response against target. These can often reveal more insight into why your overall service targets are hit or missed.

Backlog or Assignment Status – Something you should probably be looking at at least weekly (and ideally daily) is a status report that shows you where tickets are currently assigned – both by Team and by Agent (you’ll find such a graph under performance in SerioClient). If you see relatively large numbers against a single Agent or Team, you can take action by re-distributing or allocating other staff to the Team.

Technorati Tags: ITSM, Metrics, Reporting, Service Desk

• Measuring the Performance of Helpdesk/Service Desk Teams and Agents
• More Simple Helpdesk/Service Desk Metrics and Reports
• Service Desk/Helpdesk Metrics Health Check