Extended Data Updates

We've added an Extended Data Editor with new functionality within Actions and Change Plans.

Adding Extended Data to your Actions List

This will allow you to embed the capture of Extended Data into the Actions you take, and the workflow you use.

Viewing and adding Extended Data to Tasks in Change Plans

You can now capture and view Extended Data in a much simpler way. We've added the ability to create an Action that captures Extended Data, and then use that Extended Data in Tasks in your Change Plan.

Estimating the Cost of Incidents - The Incident Management Process

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

Estimating the Cost of Incidents

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.

New in Serio Release 5 - Service Explorer

One of my favourite new features in Serio Release 5 is the Service Explorer. It takes all the data you have in Incidents, Service Requests, Problems, Changes, Items and so on and presents the whole lot in a collapsible tree form.

The best thing is to show you a few pictures. Service Explorer 1

Incident Manager Weekly Checklist

I recently contacted a customer – an Incident Manager – whom I'd spent some time helping with his Incident Management procedures. He told me that things were going fine, but that some staff were not calling customers back within the 1 hour target of logging Incidents set down in the SLA (or not recording they had done so), and so he'd needed to sent a couple of emails.

I was strangely pleased to hear this, as it meant he was acting as an Incident Manager should – using the weekly checklist we'd drawn up to monitor that procedures are followed and following up where they aren't.

Incidents and Changes, and differentiating between the Two

Customer Steve asks: ‘I know it’s a basic question, but could you write something about Incidents and Changes, this is now my responsibility and we have Changes logged as Incidents. Are there any advantages of doing it this way? Also, what about SLA target times with Changes?’ Time for a few definitions first. An Incident…

Escalation and the Serio Escalation Engine

This post will be all about Escalation in Serio, the role that the Escalation Engine plays, and a personal perspective on ‘good practice’.

First of all, let’s define Escalation as it means different things to different people. Back in January I posted about Escalation in Incident Management, and that post defines both Function and Hierarchical Escalation. You’ll be pleased to hear that the Escalation Engine can handle both.

Incident Resolution and Quality

Emailer and sometime commentator Jim asks about quality and his service teams. Specifically, he has second and third line support teams that both have what Jim calls an alarming tendency to mark Incidents as ‘resolved’ when they are not resolved at all. Jim asks if I have any practical suggestions, other than just shouting at people.

Firstly, remember I’ve blogged quite a bit recently about Incident Management.

Classifying Incidents, Problems and Changes

One of the tasks that many Serio Administrators can find a little daunting is preparing categorisations for Incidents, Problems and Changes. What I’m referring to us populating the data fields that help us to manage tickets.

I’m going to list some tips to help those setting about this for the first time, or those reviewing their categories.

Incident Management, and some good habits

Over the past two weeks or so I have been blogging about Incident Management, and in particular how it is described in the ITIL Service Support book. At a later date I’ll draw these posts together, but for now I’ll explain why I started this thread.

Incident Management