Serio IT Service Desk & Helpdesk Blog

This is another in the series of Service Level Management posts I’ve been writing – the last one was on the subject of initial statistics (I’ll pick up more about why the initial statistics are needed in later posts). I’ve also posted about defining the services you deliver.

If you are trying to create a Service Level Agreement (SLA) from scratch, there are a few ways I’ve seen of structuring your document.

Based on Services

You can structure your SLA around services, using the Service Catalog as a start point. To give you ideas, here’s an example based on an Invoicing System:

Definitions:

Major Incident: System down, with no availability to users, or significant business process impact with no workaround.
High Priority Incident: System available, but with some significant business process impact for which a short-term workaround is available
Regular Incident: No significant business process impact, or a small (less than 4) number of users affected

Availability:

System is required from 8:00 to 18:00 Mon-Fri, excluding public holidays

Service Level Targets:

Major Incident: Achieve 90% resolution within 4 working hours
High Priority: Achieve 90% resolution within 8 working hours
Regular Incident: Achieve 90% resolution within 12 working hours

Notice that what I’ve written above is specific to a particular service, defines ‘grades’ of Incident by severity, and sets targets for Incident resolution. If you are preparing a real SLA for a customer, you’ll need more detail than I have created above. Issues such as reporting intervals, type of metrics to be used, escalation and others may need to be taken into account.

The above example does raise a question it is worth stopping for a moment to consider. If our Invoicing System is delivered over the network, and our network fails, is this an Incident affecting the Invoicing System or Network? If the Invoicing business process is affected then the answer is both and the Incident would be classed as a Major Incident.

Serio users taken note: this is exactly when Incidents can be logged against multiple Systems – so that, for reporting purposes, a single Incident can have multiple affects.

Based on Customer Groups

In addition to services, you can use different customer groups – by departments if you are providing support internally, or by company if you support external customers. Here each group is often a budget holder, which allows for negotiation to take place on service and costs.

In a customer-group model, each group has their own specific SLA (which is often broken down again into services). The SLA specifies clearly to which Incidents it will apply, and tries to anticipate any confusion that might arise when a single Incident affects multiple groups.

Technorati Tags: ITSM, Service Level Agreement

• Service Level Agreement Contents – Some Examples
• Service Level Management for Beginners
• Service Level Management Reports in SerioReports

This is another in the series of posts on the subject of Service Level Management – my last post in this thread started the topic of how to develop a Service Level Agreement (SLA) by defining the services you provide to users (more commonly referred to as the Service Catalog).

In this post I’m going to look at some of the data you might need to have before you enter into discussions about an SLA with a customer. I’ll start with the scenario of someone providing support to an internal customer base looking to set-up their first ‘formal’ SLA.

So, what data do you need? Speaking personally, I’d want to know approximately what our position was before any negotiations took place – so we can see if the gulf between what the customer might want, and we can deliver, is too large that we can expect to cross it with efficiency gains alone. Specifically I’d want to know:

- The average of expected number of Incidents and Change requests logged each month
- My average time to resolve Incidents, broken down by Priority. I’m not a big fan of average figures, so if possible I’d want a ‘spread’ graph that shows my the distribution of resolution times. For Serio users, this would mean SLA12.
- I’d probably want a few different ‘slices’ of Incident and Change logging data. For example, I’d like to know which user groups (departments or companies for example) logged Incidents and Changes with us.
- Most importantly, I’d want data on service availability (see our Availability White Paper for more information). I’d want our key service availability expressed as a percentage, and I’d also want some downtime statistics (in hours, per system).
- Information on customer perceptions of service – specifically data gathered from satisfaction surveys.
- Statistics on our callback performance.
- What Service Level Agreements we have, if any, with out most important suppliers.
- A few other miscellaneous statistics such as our first time fix rate, number of major Incidents, number of complaints received.

Ideally, I’d probably want this data over at least a 3-month period as well because availability statistics in particular are subject to ‘bouncing’ due to one-off major Incidents.

The reason I’d want all this is because it does no-one any good to sign-up to SLAs that are unachievable – you’ll simply set unrealistic expectations in the minds of your customers, and demoralise the IT staff that are working to meet the SLA. Of course it might be that your business needs a better service – but sometimes this requires additional investment in staff, training and infrastructure. Your discussions about SLAs should as a matter of course include these as subjects for discussion.

I’ll continue these series of posts later by looking at how we structure our SLA, and who we enter into these discussions with.

Technorati Tags: ITSM, Service Level Management

• Accessing Availability Statistics
• More on Availability Statistics

In today’s post, I’m going to introduce you to Serio’s Contract Management features.

Serio provides for two types of Contract Management:

• Customer Contract Management. Manage the contracts your Helpdesk/Service Desk has with the people it provides support to. Clearly, this applies most to Service or Help desks with external clients.
• Supplier Contract Management. Keep track of support contracts for third party suppliers providing service to you.

I’m going to focus today on the Customer Contract Management features within Serio – we’ll return to Supplier Contract Management in a later post.

Before dealing with a new call, Service Desk staff usually need to know whether the caller has a valid support contract.

Customer Contract Management enables frontline staff to answer basic questions about the Customer’s entitlement to support, such as:

• Has the Customer’s support contract expired?
• Has the Customer reached their quota of calls for this year?
• Does the Customer’s support contract cover the piece of hardware about which they are calling.

Whereas Service Level Agreements (SLAs) define the level of service that customers can expect when they contact you, Customer Contract Management keeps track of who is entitled to support and for what.

Here’s an overview of how to get up an running with Customer Contract Management. If you need more detailed instructions, please refer to the online help for SerioAdmin.

Enabling Contract Management Features
Firstly, you need to make sure that your SerioClient users can see information relating to Customer Contracts through SerioClient. Turn on Contract Management features in SerioClient by ticking the option ‘Enable Contract Management Features in SerioClient’ on the ‘Issue Logging-2′ tab page of the user’s Agent Profile in SerioAdmin.

Creating The Contracts
Next you need to create your Customer Contracts within SerioAdmin.

Open a new Configuration Explorer from the ‘File’ menu, and expand the ‘Customer Contracts’ section. (Note that if you use Serio Helpdesk rather than Serio Service Desk, the presence of Customer Contract Management will depend on the modules you have purchased.)

Customer Contract Types
Customer Contract Types enable you to organise contracts into different categories based on the type of service offered to the customer. You might create Contract Types such as ‘Gold Support’, ‘Silver Support’, ‘10 Call Support Pack’, ‘On-site’, ‘Server’, etc.

Customer Contracts
Start creating your Customer Contracts by selecting ‘Customer Contract Management’ under ‘Customer Contracts’.

First, set the Contract No., Contract Type, the Customer’s Company, and, if necessary, Branch.

Each Contract carries an expiry date – information available from SerioClient when you are logging calls, so that you can instantly see if the Customer has a valid support Contract with you.

Support Pack Contracts
If you switch to the ‘Contract Terms’ tab page of the Customer Contract form, you can choose to make the Contract at Support Pack. This means that the Customer can only raise a limited number of Incidents (say 20) under the Contract. Again, the Incident logger can see automatically in SerioClient whether or not the Customer has any calls left in their Support Pack. Of course, you can also still apply the expiry date to a Support Pack contract.

Support Pack contracts work like this. Each time you resolve an Incident for a Customer at the client’s Company, you specify whether that Incident should be deducted from their Support Pack. This discretion is essential, because you may not want all types of Incidents to count against the the Customer’s Support Pack – for example, if the Customer is raising a complaint.

Items Covered by the Contract
After you save the Contract in SerioAdmin, you will notice that an ‘Items’ tab appears. If you have an Asset or Configuration Management Database (CMDB), you can indicate on the ‘Items’ tab which of the Customer’s Assets are covered by the Customer Contract, so that you may identify when working within SerioClient whether or not the specific piece of hardware for which the Customer is reporting a fault is covered by a Customer Contract.

In Conclusion
Customer Contracts provide an invaluable tool for determining whether someone calling the Service Desk/Helpdesk is entitled to the support they are requesting, and of providing differentiated levels of support. If you’re a Serio user with a large number of external clients, you’re bound to be storing this information somewhere already. Why not make life easier for your Service Desk staff and store the information in Serio where they can see it?

This is a follow-up to Wednesday’s post about Service Level Management for Beginners. What I’m going to talk about now is how we might approach the creation of a Service Level Agreement (SLA), again assuming that you are a complete novice.

Please note, this is not the only way you can approach things, or necessarily the best way to approach creating an SLA. I’m trying to suggest ideas which those attempting this can use.

Define the Services you Provide

This is one of those things that sounds easy but often isn’t. Ask yourself what Services you provide to customers/end users, and try to document them. Examples might be:

Email access (local and internet)
Http (web) access
Accounts system

The difficulty in defining a Service is one of perspective. Do we use a customer’s definition – something meaningful that they use – or adopt a provider view where the components of a service is considered a service in its own right? I’ll illustrate by example. Suppose you have an accounts system delivered (say) by Windows Terminal Services. For it to be used you need a working software system on the server and a working network infrastructure. Does that equal one service (‘the accounting system’) or two (‘the accounting system’ and ‘the network’?).

The ITIL Service Delivery book (Pub. by TSO) provides a useful definition: ‘A service is one or more systems that enable a business process’. This puts the emphasis firmly on the user perspective.

Whatever view you take, define the Services you provide. Then add additional information such as:

The departments, customers or companies using the service
Number of concurrent users (just take an average)
Any 3rd-party (supplier) contracts that we have in connection with the service
Typical hours of use
Value of Service

The last one – Value of Service – is sometimes controversial, but something I’ve found valuable. Not all Services are created equal. The disappearance of some Services for a few hours causes inconvenience but nothing more, but failures on other Services cause immediate and widespread disruption to the normal operation of the enterprise. Typically I’ve used Critical, High, and Routine – but of course you can use a numbering scheme 1-5 or any other method.

You can store this in a matrix in something as simple as a spreadsheet. Alternatively, you can usually store this an a CMDB. In Serio, the ‘System’ structure was specifically created to allow you to hold this kind of information within the CMDB – and use it within things like Incident Management.

Those more familiar with ITIL and IT Service Management will recognise this as a Service Catalog.

Whatever comes next in defining our SLA, it’s useful to have information about what ‘the service’ is when we consider the requirements of the business.

I’ll continue this thread next week.

Technorati Tags: ITIL, ITSM, Service Level Management

• ITIL V3 – Now that the dust has settled, what does it deliver?
• Change Management – Defining the Process
• Defining Known Errors

In the next IT-service related blog topics I’m going to post here, I’m going to look at Service Level Management (SLM). I’ll assume that my readers are completely unfamiliar with this topic.

First of all, I’ll start with a definition. Service Level Management is a name given to management processes that include:

Identifying and agreeing the IT service level requirements of the organisation
Monitoring and reporting on actual service levels delivered to the organisation, identifying any weak areas in service levels achieved
Identifying cost-effective ways to improve service levels delivered.

If the above sounds vague I apologise – I’ll be adding some detail to this in later posts when I think it will become clearer. The bottom line is this: what does the business need, what is IT delivering, how can we improve and bridge any gap?

Of course I can’t talk about Service Level Management without mentioning Service Level Agreements (SLA). If you are a novice Service Level Manager, you’ll be wondering how you write an SLA. Well there is no such thing as a standard SLA first of all, any more than there is a standard company. Generally an SLA will have some or all of the following items contained within it:

Identification of services offered to users
Identification of different user groups or communities
Responsibilities of both the service provider and user
Reporting intervals and key IT/business representatives or stakeholders
Definition of service review mechanisms (usually face-to-face meetings)
Underpinning contracts (such as those we have with suppliers)

(I’ll expand on these items in later posts).

If you are reading this, & then looking at your ITSM tool which (like Serio) probably has all sorts of SLA measurement and monitoring features (often based around simple response and resolve targets), you might be tempted into thinking that you have a SLM process or (more prosaically) ‘we do SLAs’. Maybe, but too often when I ask questions…

the SLA targets have not been agreed with all (or in some cases any) of the key business stakeholders,
key services are not identified,
reporting is ad-hoc and unstructured,
no proposals for improvement can be found.

These are all signs of an ineffective or non-existant SLM process.

My point is that SLM is a management process – the role of the ITSM tool is to help you manage your targets and monitor what you are delivering. The good stuff (meeting with business stakeholders and documenting what they need, costing this, documenting what you deliver, getting a statistic from your ITSM tool and interpreting it wisely, suggesting costed improvements) happens outside the tool. It’s the value-added things like this that tell how mature a Service Level Management process is, not how closely you monitor different alerts and warnings from your ITSM software.

What I’m going to do in future posts is expand on these ideas. I’ll be talking about Service Level Agreements to give you an idea of how you’d create one, the service catalog, and some of the benefits arising from SLM. Most of all I’m going to try to deal with specifics and practicalities.

Blog admin’s note: follow-up posts are here, here, here and here as of May 7th 2007.

Technorati Tags: ITSM, ITIL

• Some Service Level Management (SLM) Key Performance Indicators (KPI)
• Service Level Management Reports in SerioReports
• Structuring your Service Level Agreement

This post will talk about SerioScript – the scripting engine that powers, amongst other things, the Serio Command Center. Specifically, I’m going to create a new script and use it to illustrate how you can display property values on the Command Center web pages – so you can see device values read from SNMP directly in your browser.

I’m going to assume that you know how to connect a script to a Device, and already have the web pages set-up.

1. Firstly, create a new Script using the SerioMIB (right-click on ‘Validation Scripts’ and select ‘Add Validation Script’). Call the Script ‘Blogtest’.

I’m going to get the Blogtest script to display the Free Memory (compared against an acceptable value) for a target machine on the Command Center web pages (I’ll call these the CCWeb pages). Please note the standard (Default) script does this anyway, but this simple example will allow me to show you how you display a value on CCWeb.

In doing so, you’ll see how to construct a script, from scratch, with your own Device Properties.

2. Click on the Device Property Definitions tab. Right-click on the page area, and select ‘Add New Device Property Definition’. Use the following values.

Display Name: Minimum Free RAM
Description: Free RAM (Memory) available on the remote machine.
Device Property Type: Scalar

3. In the Symbols window below, right-click and select ‘Add Symbol’. Use these values:

Display Name: Minimum Free RAM (MB)
Property Name: gnMinFreeMem
Description: Minimum Free RAM in Megabytes
Type: Number
Default: 80

4. Click OK to close the Symbol Editor window, and click OK to close the Device Property window, returning you to the Validation Script(Blogtest) window.

5. From the list of MIB variables in the left of the Validation Script window, notice that the top three are underlined? These are special places for you to attach code to. Right-click the one called ‘InitializationSerioScript’ and choose ‘Add Validation Statements’.

6. Add this line of code.

displayPropertyAdd(’gnMinFreeMem’, ‘gnMinFreeMem’, 2, ”, 1);

Don’t worry too much about what the arguments mean right now (you can look them up in the SerioScript Reference). All this function says is that, from a CCWeb perspective, this is a value I want to display).

Click OK to return to the Validation Script window.

7. From the list of variables in the left of the Validation Script window, right click on the variable that hold the current free RAM setting. It is called serioVarFreeMemKB. Right-click this and add these lines of code.

lnFreeRAMMB: number;

// Convert free RAM to MB.
lnFreeRAMMB := serioVarFreeMemKB / 1024;

// Check it against our expected value, and update the web pages accordingly
if lnFreeRAMMB < gnMinFreeMem then
begin
displayPropertySet('gnMinFreeMem', numToString(lnFreeRAMMB,1)+' <=== Error!');
end else
begin
displayPropertySet('gnMinFreeMem', numToString(lnFreeRAMMB,1));
end;

// Display a print value as well on the console
Print("Free RAM in MB for "+serioVarDeviceName+" = "+numToString(lnFreeRAMMB, 1));

8. Now attach the script to a Device, and Go Online.

You’ll see your target minimum free memory figure displayed against the current figure. When the observed value drops below the minimum for the Device (by default 80MB) you’ll get a little ‘error chevron displayed as well.

• More on our Command Center changes
• ITIL V3, End User Experience Monitoring and the Command Center

This post has been requested as a follow-up to my earlier ‘difficult customers’ post which seems to have been well received judging by the email feedback I’ve had. For those that don’t have it my email address is georger _at_ seriosoft _dot_ com – or of course post your comments below.

Whilst the role play seems like everyone to be a good idea, it seems it might be worthwhile going over some possible scenarios for your role play exercises, and more detail on how they should be conducted.

Starting off, I’d want to identify who should take part in our difficult IT support customer role-play. Emailer Rob asks if all staff who deal with customers (like engineers) should be involved, or just the service desk? My own preference is just the helpdesk/service desk – your central point of contact. This is the group we expect to excel in customer contact, and on whom suitable training will have the best results. Others can be included of course, depending upon the level of customer interaction you expect them to perform.

As an aside, emailer Karen objects to the use of the word ‘difficult’. Instead she suggests the terms ‘frustrated’, ‘angry’ or ‘concerned’ (or presumably all three at once – a FAC customer?). Despite Karen’s objection, I’ll stick with Difficult as a shorthand for all three as I can’t think of a better single word to describe what I’m writing about.

Make sure that is understood clearly by all those participating is that the role-play is not a test – it’s a training exercise. Make sure that your staff realise that they can’t ‘fail’ and that there will be no penalty if they find it tough.

If your staff are those fielding the test calls, you next need to decide who will play the role of the difficult customer or user. My preference would be for a peer-group exercise if at all possible – pick one of your more articulate, experienced and outgoing staffers to play the customer.

The environment should be private – with just the helpdesk/service desk staff participating in the exercise. My preference would be to complete the role-plays as a group, with each team member able to hear the others efforts. Calls should be played-out over the telephone, with the person playing the customer in another room. At the end of the exercise, when all have had a turn, have a group discussion where people review what they’ve learned.

Give your staff no warning about the calls, just brief them on the scenarios below.

1. Customer Bert calls to ask why the accounting system is down.

Scenario – Accounting system. The accounting system, used by 15 customers, is down having crashed in the mid-afternoon on a Monday. It’s the third such Incident in a 15-day period. You have no time estimate for when the system will be restored. Your manager has taken the afternoon off to play golf.

Key points: Demands to know when the system will be back. Attitude is somewhat aggressive. He wants to know what is being done. Wants to know why it keeps happening. Repeats that it ‘just isn’t good enough, some of us have work to do’. Asks ‘will any of your staff be here to help when I have to work late’. Refuses to put the phone down until satisfactory answers are given. Resorts to mild swearing.

2. Customer Kath calls.
Use scenario from 1.

Key points. Kath is calm – could be described as passive aggressive. Asks to know how many other such Incidents there have been recently. Asks the opinion of the person taken the call on the quality of service, she asks ‘it’s unprofessional isn’t it’?. Demands the service is restored immediately. Then asks to speak to a ‘supervisor’.

3. Customer Arthur calls.

Scenario – Monitors. A colleague has replaced a monitor of a VIP who complained the original was fuzzy.

Key points. He says his ‘new’ monitor is worse, and is fuming because your colleague closed the call without asking him if he was happy. He demands you get up from your desk immediately to return his old monitor. Asks ‘do you like working here?’, and asks, of your boss, ‘is this the level of service he is happy with’ asking you to comment on your boss.

4. Customer Bill calls.

Scenario – CRM. Bill manages the CRM system and can’t access a particular report.

Key point. We need to know the error message listed in the Event Log on the computer, but Bill will not co-operate or follow the instructions of the first-line technician he has called. He repeats ‘this is a problem with the upgrade you did, don’t waste my time’ and every suggestion is rejected. Bill will not co-operate to get his problem fixed.

I hope you enjoy the role-plays, & have a great weekend!

Technorati Tags: ITSM, CRM, helpdesk, service desk

• Handling Difficult Helpdesk/Service Desk Customers
• New Service Desk Staff – Training for Facing your Customers

This is a follow-up to my earlier ‘Introducing the Serio CMDB’ post – this time I’m going to talk about some of the other data attributes and something new we’ve added. I’ve posted more generally about the Configuration Management Data Base (CMDB) here.

My earlier post discussed three attributes on an Item – Item Type, Product Type and Customer. There is other important data you can add, as follows.

Network Name. This is used mainly for computers, but can also be used for other types of network-connected devices such as routers and hubs. It’s simply the DNS name of the device if trying to connect to it over the network. This is because in some organisations, the ‘Asset Tag’ or sticker with a unique ID physically attached to the device is sometimes different to how the device is identified on a network. This attribute is used by Serio’s network audit and monitoring software to connect to remote devices and obtain data. Personally, I think like is a lot less complicated if the network name and the sticker on the side of the box are the same.

Status. The use of Status is not immediately obvious. Typical values might be ‘Deployed’, ‘In warehouse’, ‘Awaiting repair’, ‘On loan’. It’s simply there to tell you how an Item is being used, or to which ‘pool’ of equipment something belongs. In my post from April 2nd about difficult customers I mentioned that my employer at that time kept a significant inventory of spare, new kit ready to be deployed at a moments notice. Using that article as an example, the fuzzy monitor might have a status initially of ‘Deployed’, which is then changed to ‘Awaiting repair’ as it is taken away. The replacement might have a status of ‘Ready to deploy’ initially, quickly changed to ‘Deployed’ as it is swapped to a user’s desk. If we think about this for a second, it means I could have queried the system for all ‘Monitors’ (Item Type) that are ‘Ready to deploy’ and seen the spare sitting in stock.

SLA and Supplier SLA. You can attach two different SLAs to an Item. The first (your Service Desk or Helpdesk SLA) is used on Incidents when you use the Item to log an Incident (on other words, it override the Default SLA and any SLA Selection Rules you have). If you then assign that Incident to a Supplier (search this blog for Supplier Management) then the Supplier SLA from the Item is used to gauge supplier performance.

Something new has been added to Serio. It’s called Item Schedules – basically a diary system for booking Items in an out on loan. You can record the booking out of Items to customers between different dates, with the system telling you about ‘double booking’ of any item. It’s a nice feature for anyone running an equipment library.

• Introducing the Serio CMDB
• Item Attributes

My post today is on the subject of ‘the big rollout’ – when a new or upgraded application is rolled-out to end users.

My experience of this over my career is mixed to say the least. It varies between someone calling and saying ‘I’ve got a problem with this new application WidgetSkillz’ and me saying ‘Oh what’s that?’ at one end of the scale, whilst at the other, I had an employer plan meticulously for 1000 ‘rollout’ Incidents in the first week and receive only 20 or so.

Firstly, I’ll risk being a master of the obvious and state why new rollouts cause problems

- The new application of service might be buggy or have errors in its configuration
- Users may be unfamiliar with the application
- If the rollout involves deployment to desktop machines, you can usually be sure that some of these will fail (or at least not be 100%)
- Some users don’t like change, and need someone to vent their frustrations on (often the Helpdesk and Service Desk staff).

This post is all about how some of the things I’d so for the front-line team – your Helpdesk or Service Desk.

1. Pick the roll-out time carefully. This is a tough one, because often there is some business driver (like a new contract) that gives you the start date. However, often you can influence the date even if you bring it forwards a little. Dates are important because there is often a ‘cyclic’ nature to IT support, with periods of greater activity coinciding with greater user activity and stress at certain times. At least consider this carefully, use reports (like the 26 week-by-week report in SerioClient) to spot any such cyclic activity and consult widely to see what other things are happening in the business.

2. Make sure your Service Desk/Helpdesk team leader (or your Incident Manager) is part of the project team. This is not always the case, particularly when you’ve got an in-house team writing or upgrading the new application. My experience has almost always been that developers focus solely on the code and delivering a stable application at the expense of issues like training and documentation.

3. Make sure a late, stable version of the application is available for your front-line support team to learn about. Make sure they have time to use it and understand it’s key functions. But please, don’t ‘give it to them to play with.’ I’ve seen this so many times and it always ends the same – the people who need to know how to use the application know nothing.

Instead, give them (the front-line team) a suite of exercises to perform, usually involving a couple of business processes, and ask them questions at the end. Make sure their time is structured and not wasted.

4. If you can, run a pilot. A pilot roll-out to a select band of users.

5. Using the pilot, try to develop a Frequently Asked Questions (FAQ) list, or collection of knowledgebase documents, to help get over any rise in calls coinciding with the rollout.

6. Finally, look at your leave rosta carefully. You wouldn’t be the first manager to plan a big rollout for a day when a large number of staff were on holiday.

For those of you on holiday over Easter have a great time, for those of our readers working (and there are quite a few) you have my commiserations.

Technorati Tags: ITSM, Software Rollout

• Handling Front-line Staff Shortages

I’ve been posting previously about getting your own CMDB (Configuration Management Data Base) off the ground. This post is about some of the specifics of the Serio CMDB.

First of all, a question I’m often asked is this: ‘Can I convert data from the Serio discovery tools to CMDB data?’. The answer is yes, you can. However, you should remember that this does not mean you have a CMDB (as I’ve discussed here). Configuration Databases contain business knowledge – things like how many concurrent users use a particular service, where the equipment is physically located, who maintains it – and this type information cannot be obtained by a mere network scan (though I’ve known vendors [not Serio, I hasten to add] who claim they can auto-generate a CMDB).

Data created in this way (from a network scan) does however offer a reasonable start point for you, but resist the urge to view it as anything more than that.

So let’s look at some of the specifics. Firstly, categorisation. An individual Configuration Item (referred to as Item in Serio for short) has two main types of categorisation: Item Type and Product Type.

Item Type: This is best used as a generic classification, and is hierarchical – having both an Item Type Category and Item Type. By generic, I mean it’s a less specific way of considering an Item. An example might be a category of Computer, with Item Type values underneath it of Desktop, Laptop, and Server.

Product Type: This is a much more specific categorisation. Like Item Type, this is a hierarchical data value but with 3 levels – Product Type Category, Product Type, and Product Version (the Version is optional). Generally if follows the manufacturers designation of an Item, with many users putting the manufacturer into the category part, with the Product designation underneath.

Having these two values means you can combine them to allow you to work on different subgroups – for things like upgrade planning.

Aside from these two, one of the other most important values you can store against the Item is the Customer. This is normally the main user of an Item, and as you would expect applies more to desktop equipment than server equipment. Setting this value is useful during Incident logging in the following ways.

- If you select the customer for an Incident, Serio will automatically load the Item into the logging form for you.
- If you log the Incident by selecting the Item first, then Serio will automatically load the customer.

I’ll continue this thread of topic over the new few weeks.

• More on Serio CMDB Attributes
• What should be in the CMDB?
• Getting started with a CMDB