Serio Blog

Thursday, 13 Nov 2008

This is a follow up to Are we all going to Disappear in a Cloud?

Some of the factors that will move applications used by SMEs into the Cloud.

+ Cost. For me, the most important factor is cost - if companies can see they'll save money, then more and more services will be Cloud-based... ...

but, I think the issue is complicated by the fact that a large proportion of companies don't actually know how much individual services cost. They can probably obtain a few invoices - for instance, for their Exchange license in the case of an eMail server - but my guess is many won't know the other costs (staff costs, hardware depreciation costs, costs of running a machine in their server room, costs of backups and so on).

So in order for cost to be a motivating factor then the savings must be both obvious and compelling - for instance, less than their annual license cost.

+ Availability. Another factor is the promise of better availability (though with caveats - see this post). High availability is, in theory, something which can be provided much more easily and cheaply by big, consolidated providers - with the understanding you'll need reliable and redundant Internet connections.

+ Skills. Where skills to run a certain service are difficult to obtain or are expensive, or where IT Directors feel they are dependent on a few key employees, this will provide a considerable push to remove that dependency by 'Clouding' the service.

+ ITIL V3.Having gone through a recent refresh, ITIL has reorganised itself to focus on services as we've blogged about here. It would be surprising if this focus, and the resulting demand for improved availability and capacity, did not act as a catalyst for change.

+ Users. Users of services will start to realise they can buy services they need directly from vendors, bypassing the IT department. It presents a huge challenge to the traditional control exercised centrally by the IT function (something we've mentioned before). I'll leave you to decide if this is a Good Thing or not.

But there are some pretty significant factors that will slow down (but not stop) this move as well.

- Trust. You have to

  • trust that your provider isn't going to go bust and is paying their bills
  • trust that they have redundant infrastructure
  • trust that they take regular backups and know how to restore those backups
  • trust that they will look after your data, because they hold it - you don't
  • trust that their security is pretty good

That's a lot of things to take on trust, especially as these are the things that are junked when companies run low on funds. However, I don't see this as something that will stop Cloud-based services - it's more of a cultural thing. Once companies start using these kinds of services and start using them, this will become less and less of an issue as it gets less and less attention.

- Reliance on the Internet. How many SMEs have truly redundant Internet access? Probably not many, but if you move mission-critical applications this is something you're going to have to look at.

- Integration. If you have System A which is integrated in some way with System B, it can be something with will no longer work when you move either or both to the Cloud (the area of integration is something not handled well in my view by Cloud end-user applications, in my view).

- Culture. Possibly the culture of local provision is well established and difficult to change.

So having asked the question 'are we all going to disappear in a cloud' I'll offer my own observations.

I don't think we (IT service and support staff) are going to disappear BUT I think that the role of the Helpdesk/Service Desk is going to change from (primarily) a provider of services to a manager of services - and that this will, at some point, have an impact both on staff headcount and staff skills.

Out: Detailed operating system and configuration skills
Out: Provision of service skills, and a provision of service focus
In: Contingency planning
In: Vendor relationship management (time to read up on those old Supplier Management posts).
In: Network provision and performance, as this is currently how Cloud services are delivered.
In: Monitoring and reporting of end-user experience and availability

Friday, 07 Nov 2008

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.

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}


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