Serio Blog

Friday, 18 Aug 2006

If the last few posts have convinced you to give Problem Management a try – I’m glad. If not, I reserve my right to nag in future posts.

So how do you get started with your own Problem Management function, and what do you need?

Aside from a basic process, ideally you will have a CMDB (Configuration Management Data Base). I’ve posted about the CMDB here and here. I say ideally, because you can still derive benefits from Problem Management even if you don’t have one yet.

Here’s how you can get started:

  1. Nominate a Problem Manager – this is your most important step. This can be a member of your existing team. It is, of course, a way to add a bit of ‘career progression’ for a member of your staff. More about this here. Make sure that your Problem Manager is 'empowered' - he or she should certainly own the Problem Management process.
  2. Make sure that your Problem Manager is aware of what a Problem is. Ideally, he/she will have been on an ITIL Foundation Course. Failing that, they should at least have a copy of the ITIL Service Delivery and Service Support books. We also have resources here, such as our Introduction to ITIL and Problem Management white papers.
  3. Make sure that they know how to use the software tool. If you are a Serio user, logging a Problem is just as easy as logging an Incident. However, make sure that they know:
  • How to raise a Problem directly from an Incident (see the Help topic ‘Raising a Problem from an Incident in SerioClient’)
  • How to link an Incident to a Problem (the easiest way is simple copy/paste)
  • How to use the 'link count' of linked Incidents in the management process
  1. Make sure that you are entering Cause Categories when you resolve an Incident. Nominate a Cause Category for ‘Unknown’ (or 'Potential Problem') so that your Problem Manager can check for these. Ensure that your Incident Management staff are also aware of what Problems are, and have a mechanism for suggesting/flagging them to the Problem Manager (before you can manage and resolve Problems, you have to identify them).
  2. Depending on the size of your organisation, you may need a Problem Management team. Before you cry 'I've got no budget' consider that the Problem Management team is usually drawn from existing members of staff - that is, we simply add to their service management responsibilities.


Wednesday, 16 Aug 2006

One of the frequent objections I hear about Problem Management is this: our Service Desk does not have the time.

I totally sympathise with this, having acted as both Helpdesk and Service Desk manager in my time. When you are under pressure it's easy to push something like this out to a permanent 'next week'.

The point is though that Problem Management is something that can help to reduce the number of Incidents you are dealing with - helping to take the pressure off... and the payback period can often be quite short. Serio supports Problem Management, helping you by keeping the Problems you log quite separate from Incidents.

If that doesn't convince you - try this: allocate a fixed number of hours each week to Problem Management by a member of your team (who you'll nominate as your Problem Manager). Do this for a couple of months, and at the end of that time see if you've got anything worthwhile from your investment.

I'll follow this post at the end of the week some suggestions as to how you can get started with Problem Management.

Tuesday, 15 Aug 2006

Just a quick post following on from George's post about linking Incidents and Problems. There are quite a few ways that you can do this in the Serio tool, but by far and way the quickest way of linking is simply to use cut and paste.

  1. In the selected Incidents list, click on the Incident you want to link.
  2. Go to the Problem list, select the Problem you want to link to and click Paste. That's it - the two are now linked.

I thought I'd post this week about Problem Management, and pose the question: Do you have a Problem Management function? (And if not, why not?).

I'll start by giving a definition of what a Problem is: It's simply something that affects IT services where we do not understand the cause. An example I always give is this: suppose that your main database server fails (let's say with the Blue Screen of Death). You raise an Incident, reboot the server, and resolve the Incident once normal service is restored. You don't know why the server failed.

Is that the end of the matter for your Helpdesk/Service Desk? Do you have any mechanism for investigating the fault - or do you wait until it happens again?

It's Problem Management that fills that gap, and provides a separate framework to understand and resolve these kinds of issues.

I'll post more about Problem Management later in the week.

Friday, 11 Aug 2006

One thing I ought to add to my post below is that different web development environments are supported fine - .ASP and .NET as examples.

The new functionality includes full cookie and session management (including the big viewstate cookie).

With a new Command Center release due very soon, I thought I'd post on one of the new features which interest me most.

The Command Center now has revised HTTP web monitoring functionality. This is more than just pulling off web server statistics though.

Instead, you can now login to web applications, test the pages of the web application, and then log off again. In doing so, you can test for page not found errors, time out errors and so on.

It's a way for Service Desk and Helpdesk staff to probe web applications pro-actively, by performing actions that users perform, and measuring the user experience. Logging the results to disk is easy, an can include things such as

  • Time taken to log in
  • Time taken to return pages from the post operation
  • Is the content of the pages as expected?

You can perform test operations as often as you want - 15 seconds, 30 seconds, 5 minutes - it's up to you. The statistics produced can be very useful in Capacity and Availability Management!

Monday, 07 Aug 2006

If you are a Serio customer, the chances are that you have a support agreement with us that includes technical support by telephone, email and the Serio support website, and that we also issue upgrades.

On the technical support side, we are not just there to help you when things don’t work the way you expect – we want to help you to get the most from the tools you have purchased.

One of the things we can do is to form a Serio Focus Group to help you do more. We’ve prepared a FAQ (shown below) which explains more about the Focus Group.

- What is a Serio Focus Group?

A forum in which Serio customers (usually the Helpdesk & Service Desk staff) can talk about any subject relating to the Serio product and ITSM. A Serio Focus Group provides a structured way for us to help our customers and provide value to them.

- Who joins it?

You need at least one member - your Serio Administrator. You can add a further 3 members if you so wish - these are normally staff from the Service Desk/Helpdesk. Whoever is responsible for Service Delivery should be present. From the Serio side, your Account Manager is a member. Keeping the numbers at 5 or below helps keep things manageable.

- How do we meet?

Normally by telephone on a conference call. Serio has screen sharing technology we can use, so it's a 'virtual' meeting where both voice and computer screens are shared. We can use Skype if you so wish.

- How often do we meet?

Typically once a month, with meetings taking about an hour.

- Who is the chairperson?

Serio will normally chair the first meeting. After that, the Focus Group members take turns.

- What do I, the customer, need to produce?

An agenda *must* be produced and circulated 4 working days before each Serio Focus Group meeting. This tells us what you want to cover and helps Serio to be properly prepared. No agenda = no meeting! Ideally the entire Service Desk can contribute to the agenda. At the end of the meeting, Action points are agreed both by the Customer and by Serio. Progress against these are reviewed at the next meeting.

- Does it cost anything?

If you have a valid support contract, then no.

- I'm kind of lost, and don't know where to start. Can you help?

Yes. Firstly, form the group and inform Serio of your intentions. Then prepare your first agenda, which might be simply 'review where we are, how do we move forward?'.

Friday, 04 Aug 2006

(or why do you need one?)

Well this is subject I’ll probably come back to a lot!

If you work on a Service Desk/Helpdesk, what is it you do? Hopefully you’ve not answered ‘we fix things’ but have said something like ‘we provide the IT infrastructure and IT services on which our business depends to operate efficiently’.

Here’s a question then: where is the IT infrastructure you have to provide documented? If it isn’t documented, how do you assess the impact of Changes you wish to perform? If it isn’t documented, how do you assess the effect of Incidents on the business?

This is the role of the CMDB: to document the IT infrastructure to the benefit of the Service Desk/Helpdesk. It’s job is to provide a logical picture of how the infrastructure fits together, the interdependencies between Configuration Items (CIs), the services that we offer to users and how those services are provided.

This means (of course) that the entries in the CMDB (Configuration Items) are not machine generated (though you can kick start your CMDB that way). Instead, CIs and the information in the Configuration Database are maintained by people, as part of Configuration Management.

I’ll continue this subject in my next post.

Wednesday, 02 Aug 2006

[Posted by site admin in George's absense, filled by email] My previous post on Monday referred to what should be in the CMDB, and in particular I mentioned virtual Configuration Items.

When starting with a CMDB, a lot of Service Desk/Helpdesk professionals seem to focus on ‘tangibles’ – server hardware, network devices such as routers, and network links such as ADSL and MPSL. Whilst worthy, these may only tell half the story.

Suppose that you have a server computer called ‘ROMA’ on your network that runs a SQL Server database and a web server running a .NET application. This computer ROMA is recorded in the CMDB – namely, you record what type of machine it is, how much memory is has, it’s maintenance details and so on. However, you need to address in a structured way the question ‘what does this machine do’ or ‘what is it’s business role’.

All too often, this is recorded in comments. A better approach, particularly with ITSM systems like Serio that display the CMDB graphically, is to create virtual Configuration Items (I’ll post a definition of the CMDB shortly). These are Configuration Items that you can’t touch, but do exist and add business value.

In the case of ROMA, you might create 3 new Configuration Items (CIs).

CI for the SQL Server database instance

CI for the Web Server

CI for the .NET application

What you would then do is link these together (the quickest way to do this in Serio is via copy & paste). The SQL Server CI is linked to ROMA, the Web Server CI is linked to ROMA, and the .NET application is linked to the Web Server. Of course, you can add additional links and dependencies onto the CMDB if that is how you perceive the interdependencies.

Doing this adds real value to the CMDB in many ways. For instance, looking at ROMA you can now see information about the components in provides into wider IT systems, and your new virtual CIs can themselves carry richer information such as recovery procedures.

Monday, 31 Jul 2006

Well I though I would start my first blog entry with a question – what should go into your Configuration Management Data Base? (I’ll leave the question of why the Service Desk needs a CMDB for another time.)

There are lots of valid ways of approaching this for Service Desks/Helpdesks using ITIL. One of the best ways of approaching this is to say:

Q: What is a Configuration Item (CI)?

A: It’s something that we may wish to subject to Change Control.

So, what do you want to subject to Change Control procedures? It’s almost certainly going to be enterprise level entities – servers, network switches and so on. It does of course imply that you have some leeway in terms of desktops and desktop level equipment. I always like to remind people that ITIL is not prescriptive its approach, and the real skill in implementation is to fit it correctly to your own business.

You can take this to mean that, in my view, it is sometimes OK to exclude some or all desktop equipment from the CMDB.

Considering the CMDB in this way also leads us to consider the fact that not all CIs need to be physical – virtual CIs can also be included (personally, I would always advise that they should be). Virtual CIs might include web servers, database servers, or even entire systems.

I’m going to post more about the CMDB later in the week, and will come back to this question then.