Serio Blog

Monday, 02 Oct 2006

On the Verso blog there are a couple of new blog articles by Kirstie Magowan that may be of interest. The first is Making use of your CMDB and the second is Keeping your CMDB data current.

Friday, 29 Sep 2006

I said in my last post ‘Supplier Management – Roundup and Finish’ that the blog would move away from the Supplier Management topic for the time being. However, I am prompted to return to it today due to a conversation I had with a long-time customer yesterday, who is starting out with Supplier Management and has been following the blog.

The question was this: They have set their system up so that, when an assignment is made to a supplier, the internal Service Level Agreement (SLA) is ‘clock stopped’ until the supplier resolution occurs – is this right?

Our customer had some doubts about this, but had set the system up this way because ‘if the Incident is being assigned externally we (the helpdesk) can’t resolve it so it isn’t fair for it to drag down our statistics’.

My experience is that this is quite a common procedure, but I don’t think it is the right approach to take.

My reasoning lies in What an SLA is, and What an SLA is for – but I’ll start by saying what an SLA is not:

An SLA is not there (or should not be used) to remind you when you have to do things by.

An SLA is the minimum level (or acceptable level) of service required by the business, and it many cases is targeted towards Incident resolution and restoration of services after a fault. If this does not help, consider things from the customer’s point of view.

Imagine you have a customer Carole that deals with your organisation’s customers – the customers who pay invoices and keep your company in business. If Carole has an IT problem that stops her doing her job effectively, what matters is the time that it takes the Helpdesk/Service Desk to resolve her problem. She is unlikely to be interested in the fact that you may or may not have had to use a 3rd party supplier – she has customers to deal with.

This is where the SLA comes in. It’s trying to ensure that there is a reasonable and agreed understanding of when Carole’s problem will be resolved. If you choose to use 3-rd party suppliers then that needs to be factored into the design of the SLA that you have – something that this blog may return to later.

Wednesday, 27 Sep 2006

Whilst George is away, I will finish his series of posts on Supplier Management. As indicated in the previous blog entry, this post is going to be about getting started.

I’ll recap on George’s previous posts first, which have covered:

So how do you get started in Serio?

I will outline the major steps here, but for the definitive guide you should see the topic ‘Supplier Management Roadmap’ in the HowTo guide, part of the Serio documentation distributed with the product.

  1. Determine the data you need to effectively monitor supplier performance. Examine the contract or agreement you have, obtain any service levels that the supplier is meant to meet, and consider the data you need from your ITSM tool.
  2. Determine how Incidents will be passed to the supplier. Here you are looking at the key Supplier Management steps, and how they relate to a given supplier. If it helps, draw a map or a flowchart. You are deciding things like ‘do I assign using email or telephone’, ‘what information needs to be contained within assignment emails to the supplier’, ‘when do I get the supplier reference number’ and so on.
  3. Update your Incident Management process accordingly. Ensure that the responsibilities for supplier-assigned Incidents is clearly defined, and that a procedure or guidance exists for handling overdue or problematic Incidents that have been assigned externally. Make sure clear guidance is given to Service Desk/Helpdesk staff.
  4. Now you need to use Serio to start to set some of this up.
  • Start by entering your supplier details (name, address, telephone number and so on.).
  • Enter any new supplier Service Level Agreements (SLA) that you need, and associate them with the suppliers you’ve created.
  • Create Actions that will perform the various assignments, acknowledgements and resolutions you identified in step 2.
  • Make these Actions available to your front line staff.
  • Create Issue Queries for your staff (do this centrally, don’t expect your Helpdesk/Service Desk staff to create them themselves). These Queries should retrieve Incidents that are assigned to suppliers, assigned to a particular supplier and so on.
  • Create Issue Displays (again, do this centrally) that allow those involved with Supplier Management to see key supplier data. Issue Displays control the columns that you see in the Issue Monitor.
  1. At intervals, run management reports from SerioReports to examine supplier performance, drawing the attention of your suppliers to unacceptable performance as required.

Monday, 25 Sep 2006

My recent posts have been on the subject of Supplier Management, and as I signalled in my last post I’m going to talk about some additional data that becomes available if you have a Supplier Management process implemented in your ITSM tool. All of the information below is available to Serio users.

Let’s start with status data, which you would probably access on a daily basis:

  • The number & details of Incidents being handled by suppliers (in other words, unresolved by the supplier).
  • The number & details of Incidents being handled by a specific supplier.
  • Those Incidents assigned to suppliers where the assignment has not been acknowledged.
  • Incidents assigned to suppliers where a response is outstanding or overdue.
  • Incidents assigned to suppliers where a supplier resolution is outstanding or overdue.

Let’s look at available supplier performance data (this is on a per-supplier basis)

  • Incidents assigned and resolved on a month-by-month basis.
  • Percentage/number of suppliers responses on time.
  • Percentage/number of supplier resolutions on time.

The above data is very Incident focussed. However, it’s probable that you would expand this with data from other areas, most obviously from disciplines such as Availability Management - as I noted earlier for many suppliers this is likely to be more important than Incident resolution performance.

The final post in this thread will give an overview of how you get started with Supplier Management in Serio (the good news is that it does not take too long).

Friday, 22 Sep 2006

I’ve been looking at Supplier Management in my previous posts. I’ve noted why we need Supplier Management, and I’ve stressed how using the Serio tool to implement a Supplier Management process allows you to increase the data available to you.

I want to look at Supplier Management from an Incident Manager’s perspective (you have an Incident Manager, right?), and to describe the ‘workflow’ or steps we might take with an Incident that has to be handled by a 3rd party. These are the key steps, though you can expand it with others.

Assignment. Much like an assignment between colleagues, this is where you assign the Incident to the supplier. It is still assigned to a member of your Helpdesk/Service Desk team, but now has an additional assignment to the supplier. At this time you would notify the supplier – either by telephone, or by sending an email through your ITSM tool. Serio allows such emails to be specifically configured for individual suppliers. 

Acknowledgement. This is where the supplier says ‘I acknowledge receipt of this Incident’ and normally gives you a reference number. Serio allows you to store this with the Incident, and to search for the Incident with this when the supplier calls. 

Callback. Whereas during the Acknowledgement the Supplier merely acknowledges receipt, during the Callback the Suppliers actually addresses the details of the Issue itself. Depending on the nature of the problem, the Supplier might call to discuss the site visit of an engineer, or the installation or configuration of a particular software system.

Supplier Resolution. This is where the suppliers part of the Incident is complete. It may mean that the Incident is resolved, or that you have additional steps to take.

When you make the Assignment step, Serio will attach an additional ‘external’ Service Level Agreement (SLA) to the Incident. This will then be used to measure the timeliness of both the Callback and the Resolution. I’ll talk more about supplier management information in my next post next week.

In the meantime, you can find more about Supplier Management in the HowTo guide, part of the Serio product documentation – see ‘Supplier Management Roadmap’.

Thursday, 21 Sep 2006

Over at Verso there is an interesting post about ITIL and Management Buy-in (I concur entirely with the post). My own experience before joining Serio was that an improving service was much more likely to attract extra funding.

Wednesday, 20 Sep 2006

I introduced Supplier Management in my last post. What I will do now is talk about Supplier Management within Incident Management.

Anyone who works on any decent-sized Helpdesk or Service Desk knows that you can (normally) only resolve a percentage of Incidents yourself – for some (and it could be a high percentage) you have to pass to a 3rd party organisation, such as your telecoms provider or your hardware services provider. It’s these Incidents that I’m going to focus on.

An Incident normally has someone (an Agent in Serio terms) that is assigned to the Incident – someone involved in IT service delivery that is working to resolve the Incident. You can also supplement this with assignment to a Supplier. There are some significant advantages to doing this:

  • You can say to Serio, or whatever tool you use, ‘show me Incidents that are currently with third party suppliers’ or more specifically ‘show me Incidents that are currently with supplier X’
  • You can attach an additional Service Level Agreement to the Incident, that is set to measure the supplier’s timeliness.
  • You can automate the assignment process, for instance with the use of specially created emails.
  • You get vastly enhanced reporting. For instance, you can access status reports showing how many Incidents are with suppliers, and you can access reports on supplier performance.

If your Helpdesk/Service Desk does not use any kind of formal Supplier Management then none of the benefits I’ve listed above will be available to you.

I’ll take a look at the major events within Incident Management when we are handling suppliers in my next post.

Monday, 18 Sep 2006

My subject for the coming week, whilst here in sunny Camps Bay, South Africa :-), is going to be Supplier Management. It’s an important topic, and I want to start with some of the basics and explain how you can get started.

As I always do when starting such blog threads, I’ll try a definition – and a short one at that.


Supplier Management aims to ensure that suppliers meet the business’s needs and objectives.

Expanding on this definition a little gives:

  • To ensure that service quality is measured formally
  • To provide a solid base on which supplier charges can be assessed
  • To ensure that agreements in contracts held with suppliers are adhered to and not replaced with what the supplier deems as acceptable

Getting Started with Supplier Management

As always I try to approach things from a practical viewpoint, so what follows are hopefully practical tips you can follow.

You first task should be to identify what data you need to capture – as it will be different for different suppliers and different service contracts. I’ve listed some examples below to illustrate my point:

Example 1. The contract is for the provision of an Internet cable line. You are paying for a service and the contract states that the service will be available 99.9% of the time measure month-to-month. Naturally your focus here is going to be downtime and availability, with the aim to produce a monthly report showing availability achieved, and all Incidents affecting availability.

Example 2. The contract is for desktop PC repair for a wide range of equipment. You are paying for a 4 hour response and resolution of repairs/provision of replacements within 2 days. Here the focus is going to be on Incident performance from the supplier, focusing on the timeliness of their response and their resolution.

I’m going to return to Supplier Management in coming posts this week.

Friday, 15 Sep 2006

RobE asks about using Active Directory Replication when you have a mix of internal and external customers.

You can still use replication in these circumstances, and have two choices.

The first thing to understand is that if you switch on replication and then create a customer record using SerioClient, you can still use that customer - for Incident logging. When replication kicks in records like this will remain untouched. So that means your customer database can be a mix of both replicated (internal) and non-replicated (external) customers.

Your other option is to store your external customers as Contacts (yes, Active Directory has such a data storage concept). Serio will replication from your Contacts, even though Contacts are not domain users.

(This is a follow on blog from Wednesday’s article about Active Directory Replication)

Thank you to the anonymous emailer who pointed out that having employee data held within Active Directory offered the prospect of lots of 3rd party applications (like payroll or facilities management) using the same consistent data source ('enterprise wide employee data').

Thank you also to my colleagues here who pointed out that using replication from Active Directory also allows NT Domain logins to be used with SerioWeb (another advantage I missed).

If you are a Serio user that is not using Active Directory Replication, you are probably wondering how you start using it. I’ll use this blog to discuss the main challenges you face, but please remember that the process is documented in the HowTo guide which is part of your product documentation (search for Serio Directory Replication Roadmap) and you should read that as the definitive guide.

Here are your main challenges:

  1. Create Active Directory data. Easily said, but for most organisations probably quite challenging! You need rich data – not just a list of names. You need name, phone number, email address at the very least. You also need what Active Directory called Organisational Units. This is data about what companies or departments people work in, and where they are normally based. In effect, Active Directory organises data in a tree form, and you need branches for Companies, Departments and Users.
  2. The structure of the data is quite important, as is its quality. We provide you with tools to help, including an application to ‘preview’ your data.
  3. You then need to perform a reconciliation. This is where you link up your existing Serio customer database with the data you’ve created in Active Directory. This is so that Serio knows that the J. Smith you have in the Serio database is Mr James Smith in Active Directory, and that updates can be applied correctly. You perform a reconciliation just once.