Serio Blog

Friday, 07 Nov 2008

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.

Wednesday, 29 Oct 2008

Ever wondered how you can print colour on a Black & White printer, the dailywtf explains how...

Monday, 27 Oct 2008

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.

Monday, 13 Oct 2008

In case you haven't noticed, laptop computers have been getting ever more powerful, with bigger and more impressive screens, and ever bigger discs. The laptop used quite commonly here at Serio are variants of the Toshiba Satellite Pro.

Whilst it's OK, it is not any more portable that the old Compaq portables I had over 5 years ago. In fact, I suspect it's a bit heavier and for certain, the battery doesn't last as long.

Asus eee 901That's where ASUS have came in with their EEE PC. Whereas laptop computers have typically sacrificed weight and battery life for features, ASUS have decided to try to create something that is literally not a pain in the neck by going for portability and battery life. My new 901 weighs 1Kg and is about slightly larger than a paperback novel, as shown in Figure 1. 

Early versions of the ASUS suffered from poor connectivity, and were fiddly to use. With the EEE 901, most of these niggles are resolved.

To help users on the move, it doesn't have a conventional hard disc - ie, a mechanical one with a disc that spins. Instead it has a virtual 12GB (20GB on Linux) hard disc that is actually implemented in Solid State RAM, called a Solid State Shockproof Drive. It's something useful if you use the computer in environments where jolts are commonplace, like the Stansted Airport to Liverpool St Stansted Express I travelled on last week. The chance of a jolt damaging the disc is practically nil.

The screen is about 8 inches across and the resolution is 1024 x 600. It's readable, and you'll find yourself able to read most web pages and emails, but it does feel small. However, as the only alternative is a physically larger device, I'll have it the way it is.

The keyboard is, for me, the worst aspect. Maybe you just have to get used to it, but every sentence I type has a typo (nothing new there then), and the all important number pad keys like home and end are difficult to use. The feel of the keys is also not good, one just seems to merge in with the next.

There are two versions of the EEE 901. One machine comes installed with Linux, and one with Windows XP. The linux version has had some issues with connecting to wireless networks but the XP version seems OK.

The battery life is a claimed 8 hours. I'm not sure what you have to do to get that, but certainly 5 hours can be expected (way ahead of most laptops).

On the whole, I think it's great. When you are carrying it it's like you've forgotten your computer it is so light, and because the battery life is so good you don't need to carry the power supply around so much.

An alternative take on the ASUS eee is here (the earlier 701).

Wednesday, 08 Oct 2008

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 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. 

Tuesday, 30 Sep 2008

If you are a Serio user, at some point you are almost certainly going to want to exchange emails with another support system. There are generally two cases that we see being met:

  • You have a supplier you wish to exchange information with via email as part of Supplier Management
  • You are a company that deals with external customers, and one or more of your customers has their own support system.

By exchanging emails, I mean that when you send them an email from Serio it is added to the correct ticket and processed efficiently, and likewise when the supplier or customer sends you an email from their system that Serio picks it up and places it with the right ticket.

Things like this usually work seamlessly, and I'll explain how they work. Most support services use something called a Reply Reference (in Serio's case), or a ticket id, or an email reference code. It's something that

  • uniquely identifies the originating ticket
  • is unlikely to come-up in normal email exchanges by accident

The main thing to understand is that there is short text string that can be used to identify the best ticket to add the email to.

If you are just using Serio, all you need to worry about is that the Reply Reference is quoted, which normally means putting it in all outgoing emails, so that when customers or suppliers reply it is automatically quoted back, and the email is handled correctly.

When you start to deal with an external system, all of a sudden have 2 Reply References to consider; your own, which you are familiar with, and theirs - your supplier or customer. I'll call this the 3rd Party Reference.

Here's what you need to do to make this work.

Logging an Incident for a Customer who has their own support system

In this case, you might be acting as a support supplier or 2nd line support service.

- If the customer has telephoned you, ask them for the 3rd Party Reference (remember though, they'll call it something different). Enter this value into the Customer Reference field.
- Change your eDocs to include the Customer Reference, if they don't already. Make sure that at the very least it is included on the confirmation email, and on emails you send during the life of a ticket.
 
- If the Incident comes to you by email, make sure that your Customer has included their 3rd Party Reference.
- Just log the ticket as usual, and change your eDocs to quote the Incident description (but most of you will find it is already quoted). There is usually nothing else to do.
 

- In either case, ask your customer to quote your own Replay Reference on all subsequent emails they send.

Assigning an Incident to a Supplier

In this case, you are logging the ticket and assigning to a Supplier.

- Log the ticket as normal.
- Use Supplier Management to assign the ticket to the Supplier.
- Use Supplier Management Actions (Supplier Acknowledgment) to record the 3rd Party Reference from your Supplier.
- Make sure that you include this on all of your outgoing Supplier emails by amending your eDocs to include it.

Friday, 05 Sep 2008

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?

Monday, 01 Sep 2008

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.

Friday, 15 Aug 2008

...or put another way, 'How to Survive and Prosper when your Working World is turned upside down'.

I suppose it's possible that some readers of this blog will have had a happy, or at least not unpleasant, experiences whilst working in IT and their company is the subject of a takeover or merger.

I have to say that in my career this hasn't been the case, nor do I know anyone who who hasn't found the experience troubling or stressful. At the root of the problem is a simple fact: your working situation can be changing radically, and you usually have little or no power to influence things.

Survivors Guide

1. Survivors Know Who is Actually Calling the Shots.

In a take-over (your employer is sold to another company) it's obvious - the managers from the purchasing company have control. Mergers are more tricky. Even when mergers are said to be 'of equals' in my experience there is usually one of the pair that is simply absorbing the other. Try to find out which is swallowing the other. You can assess this usually by looking at the Directors and senior managers, - who is keeping their jobs (implies the one doing the swallowing) and who is taking the 'new and exciting roles' (implies the one being swallowed). Other clues might be the change of office (my place or yours) and whose brand survives.

2. Survivors are Cheerful and Stupid.

In a situation where you are maybe feeling stressed or nervous about the future, it's easy to fall into the trap of getting cross easily, viewing the other company as enemies, and being over-sensitive. Being Cheerful and Stupid means simply never assuming the worse, being slow to see insults, and avoiding alienating your new or existing co-workers. Even if your new colleagues do something you don't like, or you feel that undermines your position, ignore it.

True story: Many years ago, the company I worked for was taken over by a large multinational, at a time when I was running the product development team. A guy showed up one day, and without introducing himself to me asked our receptionist for my and my team's CVs. My reaction was to very nearly punch this guy's lights out. This made me feel a little better but served no useful purpose at all. Cheerful and Stupid would have been a better approach: 'certainly Mr Secret Squirrel - here you go!'.

3. Survivors Know that it is Every Man (or Woman!) For Themselves.

It's a bit unseemly, but a merger or takeover can be like a big scramble for the life boats on a sinking ship. Your best policy is to look after yourself - don't expect your boss to do that for you, regardless of how well you know them.

4. Survivors Make Friends.

It's easy for an 'us and them' mentality to develop, and it can be hard to even be civil at times. This attitude though doesn't do you or the company any good so try to make friends, particularly with 'the other side'. Try to connect with their social networks - for example, if they have a sporting team try to join it, if if there is some other social grouping try to become a part of it. If they plan LAN Computer games after work ask if you can be part of it - but remember, be Cheerful and Stupid if they say no.

5. Survivors Don't Take any Holidays for the First Six Months.

I have no hard statistical evidence for this, but a lot of people seem to be fired or made redundant after returning from holiday - it just seems easier to do when you are not around. As the period after a merger is a scramble, it doesn't make any sense for you to not be around as things start to settle down.

6. Survivors Know How Expensive They Are.

It isn't just a merger of cultures and people you get. Sometimes when companies merge or are subject to takeover you get a merger of approaches to salary and remuneration. Try to find out where you stand. If you are paid substantially more than a similar worker in the company that has taken you over, it might be that you'll be shown the door regardless of what you do. In this case, you might be able to negotiate a better severance package - but regardless, it's information you need to know.

A good source of information might be by looking at any recent recruitment advertisements the other company has placed over the last six months. Another tell tale sign is the number of empty vacancies that the other company has - a high number is sometimes indicative of lower than average salaries.

7. Survivors Constrain Their Personal Expenditure.

Part of the deal with mergers is the stress they cause. My view is that most of this comes from people being subjected to sometimes quite radical change in their jobs, and having absolutely no way to influence or control that change. Another source of stress is the more prosaic 'how will I pay my bills if I loose my job?'. A way you can reduce this stress is simply taking an axe to your outgoings (not literally). If you've recently bought a new car, see if you can get rid of it without taking too large a hit, if you were taking a holiday see if you can cancel and get most of all of your money back (see also point 5).

Reducing your expenditure will make you feel less dependent on your monthly pay check. This will reduce your stress level, and allow you to more easily make friends and be Cheerful and Stupid.

8. Survivors Engage With Customers.

Without customers, most businesses will shrivel up pretty quickly. Being engaged directly with customers, and having a direct and valued relationship with customers, immediately elevates your standing within any company. It doesn't make you indispensable, but it does give you something extra.

If a customer is particularly pleased with something you've done, don't be afraid to solicit the customer sending an email of praise about you to your boss.

9. Survivors Have Their CV Up To Date.

Everyone needs a fall back position, so now is as good a time as any to bring your CV up to date.

In doing so, avoid developing a negative attitude to your employer. See points 2 and 4.

10. Survivors Sell their Office Supplies on Ebay wink

Aside from providing Scott Adam's Dilbert with hundreds of strips, you may find that everyone is too busy focusing on CVs, making friends and watching their backs to notice that the premium envelops keep disappearing (warning: this may not be legal in all jurisdictions).

Monday, 11 Aug 2008

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.

Pages