Serio Blog

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.

Friday, 15 Aug 2008

...or put another way, 'How to Survive and Prosper when your Working World is turned upside down'.

I suppose it's possible that some readers of this blog will have had a happy, or at least not unpleasant, experiences whilst working in IT and their company is the subject of a takeover or merger.

I have to say that in my career this hasn't been the case, nor do I know anyone who who hasn't found the experience troubling or stressful. At the root of the problem is a simple fact: your working situation can be changing radically, and you usually have little or no power to influence things.

Survivors Guide

1. Survivors Know Who is Actually Calling the Shots.

In a take-over (your employer is sold to another company) it's obvious - the managers from the purchasing company have control. Mergers are more tricky. Even when mergers are said to be 'of equals' in my experience there is usually one of the pair that is simply absorbing the other. Try to find out which is swallowing the other. You can assess this usually by looking at the Directors and senior managers, - who is keeping their jobs (implies the one doing the swallowing) and who is taking the 'new and exciting roles' (implies the one being swallowed). Other clues might be the change of office (my place or yours) and whose brand survives.

2. Survivors are Cheerful and Stupid.

In a situation where you are maybe feeling stressed or nervous about the future, it's easy to fall into the trap of getting cross easily, viewing the other company as enemies, and being over-sensitive. Being Cheerful and Stupid means simply never assuming the worse, being slow to see insults, and avoiding alienating your new or existing co-workers. Even if your new colleagues do something you don't like, or you feel that undermines your position, ignore it.

True story: Many years ago, the company I worked for was taken over by a large multinational, at a time when I was running the product development team. A guy showed up one day, and without introducing himself to me asked our receptionist for my and my team's CVs. My reaction was to very nearly punch this guy's lights out. This made me feel a little better but served no useful purpose at all. Cheerful and Stupid would have been a better approach: 'certainly Mr Secret Squirrel - here you go!'.

3. Survivors Know that it is Every Man (or Woman!) For Themselves.

It's a bit unseemly, but a merger or takeover can be like a big scramble for the life boats on a sinking ship. Your best policy is to look after yourself - don't expect your boss to do that for you, regardless of how well you know them.

4. Survivors Make Friends.

It's easy for an 'us and them' mentality to develop, and it can be hard to even be civil at times. This attitude though doesn't do you or the company any good so try to make friends, particularly with 'the other side'. Try to connect with their social networks - for example, if they have a sporting team try to join it, if if there is some other social grouping try to become a part of it. If they plan LAN Computer games after work ask if you can be part of it - but remember, be Cheerful and Stupid if they say no.

5. Survivors Don't Take any Holidays for the First Six Months.

I have no hard statistical evidence for this, but a lot of people seem to be fired or made redundant after returning from holiday - it just seems easier to do when you are not around. As the period after a merger is a scramble, it doesn't make any sense for you to not be around as things start to settle down.

6. Survivors Know How Expensive They Are.

It isn't just a merger of cultures and people you get. Sometimes when companies merge or are subject to takeover you get a merger of approaches to salary and remuneration. Try to find out where you stand. If you are paid substantially more than a similar worker in the company that has taken you over, it might be that you'll be shown the door regardless of what you do. In this case, you might be able to negotiate a better severance package - but regardless, it's information you need to know.

A good source of information might be by looking at any recent recruitment advertisements the other company has placed over the last six months. Another tell tale sign is the number of empty vacancies that the other company has - a high number is sometimes indicative of lower than average salaries.

7. Survivors Constrain Their Personal Expenditure.

Part of the deal with mergers is the stress they cause. My view is that most of this comes from people being subjected to sometimes quite radical change in their jobs, and having absolutely no way to influence or control that change. Another source of stress is the more prosaic 'how will I pay my bills if I loose my job?'. A way you can reduce this stress is simply taking an axe to your outgoings (not literally). If you've recently bought a new car, see if you can get rid of it without taking too large a hit, if you were taking a holiday see if you can cancel and get most of all of your money back (see also point 5).

Reducing your expenditure will make you feel less dependent on your monthly pay check. This will reduce your stress level, and allow you to more easily make friends and be Cheerful and Stupid.

8. Survivors Engage With Customers.

Without customers, most businesses will shrivel up pretty quickly. Being engaged directly with customers, and having a direct and valued relationship with customers, immediately elevates your standing within any company. It doesn't make you indispensable, but it does give you something extra.

If a customer is particularly pleased with something you've done, don't be afraid to solicit the customer sending an email of praise about you to your boss.

9. Survivors Have Their CV Up To Date.

Everyone needs a fall back position, so now is as good a time as any to bring your CV up to date.

In doing so, avoid developing a negative attitude to your employer. See points 2 and 4.

10. Survivors Sell their Office Supplies on Ebay wink

Aside from providing Scott Adam's Dilbert with hundreds of strips, you may find that everyone is too busy focusing on CVs, making friends and watching their backs to notice that the premium envelops keep disappearing (warning: this may not be legal in all jurisdictions).

Monday, 11 Aug 2008

Something two of our customers have started recently, and been kind enough to share with me, has been the placing of Test Calls on a Helpdesk/Service Desk. I've used their comments to prepare this Blog post (so thanks!)

By Test Calls, I mean that a number 'fake' or 'manufactured' calls are placed anonymously and a number of aspects of the call analysed.

For me what is interesting is that I'd not encountered any company that regularly placed Test Calls up until two years ago: since then there has been quite an upswing.

The reason is an increased value being placed on intangibles - stuff you simply can't measure directly with normal metrics, and a desire to more fully understand the customer experience. You'll find more about this below, but by intangibles I mean clarity of communication, courtesy, and so on. Whilst at the moment I'm seeing this in the 'paid support' world, it probably isn't long before it crosses over into the in-house support function.

Some Tips for placing Test Calls

1. Announce What You Will be Doing. Make sure everyone knows Test Calls will be made, and from what date they can expect them (but there's no need to tell them on what days, or announce them beforehand).

2. Keep it Legal. If you are recording the conversation, you will may need to advise staff of this - check the legal situation regarding disclosure of recording in your country. Regardless of the legal requirement, I think you should advise of recording as a courtesy.

3. Set your goals clearly. Make sure you are clear about what 'success' factors you are looking for in your test call. Success factors might include:

  • Courtesy
  • Speed of answering (if you don't have independent statistics from your telephone system)
  • Ability of the Service Desk Agent to speak clearly. For instance, did they control the call? If they are using headsets, is the mic correctly positioned? Was there an excess of background noise?
  • If you have a script was the script followed?

The closer you can get to a scorecard you complete at the time of the call the better. Try something that allows a simply 1-5 score to be recorded against each call aspect, along with and caller's notes.

4. Keep the call simple. Your best bet is not to make a call that involves something elaborate, but rather something simple - maybe a password reset, or a printer problem - something you might hope would be dealt with well.

5. Make Sure You Explain Why. Be clear about why you are placing the test calls - for quality and training purposes. Be clear that poor results will result in training as opposed to dismissal.

6. Create a Test Call Calendar, so that your Test Calls are placed at different times of day, and at reasonable intervals, and ideally when different members of staff are taking calls.

7. If something unsatisfactory is detected and a follow-up required, make sure you do this within 24 hours of the test call being placed.

Tuesday, 05 Aug 2008

This is a follow-up post on the subject of start-ups and acquisitions, which was posted in the middle of July.

That post looked at what happens of your support operation is suddenly faced with the appearance of a new company (which I called NewCo), and some of the questions you can ask if you are trying to make sense of how this new organisation might affect your IT support service.

This post will address the question

'how do I incorporate them [the new company] into our support system?'

...which is the question our support service gets asked most often in connection with this. So before continuing, you might want to go back to the other article and re-read the questions listed - hopefully they will add a little perspective.

1. Do you need to add the new company at all, or do anything? This might well be the conclusion you draw, so don't feel compelled to make any changes or additions to your ITSM system. It might simply be the case NewCo set's up it's own completely distinct ITSM system, and everything continues as before.

2. Add the new company NewCo as a Service Team. As mentioned in the earlier post, the issue here is one of control. Adding the IT support staff of NewCo as a Service Team (like your existing first line, network or other teams) is perfectly OK but it does imply control within the existing IT management framework, in as much as Incidents can be assigned to them, and they will be subject to the same expectations, SLAs and metrics as other Teams.

There will also be a degree of information sharing, as usually NewCo will usually be able to see shared information like your CMDB, Knowledgebase documents and ticket pools. Usually this kind of information sharing between teams is a good thing, but consider if there are any confidentiality issues to address.

3. Add the new company NewCo as a Supplier, and use Supplier Management (you'll find lots of articles about Supplier Management in this Blog).

Setting the NewCo IT support function up as a Supplier is useful if you have no control over how they operate (in other words, they are like a black box) but you still need to be able to pass Incidents, Service Requests and Changes between the two in a structured way. Setting-up NewCo as a Supplier will also allow you to collate supplier related metrics, like the number of tickets currently assigned, or assigned in the past month. Generally this kind of approach can side-step the politically sensitive issues alluded to in the earlier post. 

Friday, 01 Aug 2008

This post is for anyone who has ever been a bit confused about IP ports. Whilst most people I deal with have no problem understanding what they are and what they do, there have been a few cases recently where it would have been useful for me to refer to a post like this for background.

If you want to read about layered networks or IP in detail there are loads of resources - like here for example. I'm just going to deal with some of the practical aspects folk who work in IT support have to deal with.

TCP/IP is what is referred to as connection-orientated. That basically means it's for connecting computers together...

...except that this is not quite true. It's really for connecting applications running on computers together. And computers have more than one application running, which is one of the reasons that we have Ports.

Starting at the Beginning

You will have seen IP addresses - for example. You also probably know that machines have names, and that names 'resolve' into IP addresses. For example 'ping zephod' might resolve into 'ping' (there is usually a server sitting somewhere on your network that takes names and returns IP addresses by doing a simple look-up from a list).

You are probably also familiar with either using an IP address to 'connect' two applications together. You might do this for example when you set-up your email client software to read your emails at home - one of the things you specify is the Name or IP address of the email server. Get that right, and the chances are you can access your email.

This IP address allows your email client software to 'talk' using TCP to your email server, allowing the two to exchange useful information because the email server is 'listening' for requests from email clients, and returning useful data back.

Ports Connect Applications

But consider this problem. That email server whose IP address you entered doesn't just run an email server. It almost certainly runs a web server as well which is also listening for requests from clients (browsers), it probably also has a database running called MySQL that also is listening for requests, and so on. In fact, if you count all of the different applications listening it may well count over 20, with the possibility of having even more.

So this begs the question: when your email client program wants to send a request to the email server application running at the IP address you specified, how does it avoid sending the data to the web server instead?

The answer is Ports

Imagine a large high-rise building with 120 flats (apartments). The address of the apartment building is 100 High St, Livingston. If you want to send a letter to a Mr Joe Bloggs who lives there, you'll need more than 'Mr Joe Bloggs, 100 High St, Livingston' because the postman won't know which of the 120 mailboxes to put the letter into. The correct address is 'Mr Joe Bloggs, Flat 25, 100 High St, Livingston'. In this example, the 100 High St part of the address is equivalent to the IP address, and 'Flat 25' is the Port number: the final piece of the jigsaw. If you don't specify a flat, or specify the wrong flat number, the chances are your letter will not be delivered.

Why don't I need to specify, or know, the Port number when I enter the IP address into my email client software?

The answer is because of convention. By convention, certain types of programs always use the same Port. So email programs typically know what Port to use. Some common standards are below:

20 FTP
22 Secure Shell
23 Telnet protocol—unencrypted text communications
25 Simple Mail Transfer Protocol (SMTP)
42 nameserver
53 Domain Name System (DNS)
57 MTP, Mail Transfer Protocol
79 Finger
80 Hypertext Transfer Protocol (HTTP)
110 POP3 (Mail)
161 SNMP

What about Ports used for Sending Data?

Ports are also used for sending data, but unlike applications that listen for data (like server applications of all kinds) the send Port is usually not significant. The reason is simple: when you send your request to the server application, you will send both your IP address and the Port you send the data from, meaning it's easy for the server to send a reply using this information.

(Thanks to DuncanD for his help with this)

Tuesday, 29 Jul 2008

In case you are not familiar with it, the Serio Inventory Agent (SIA) is a piece of software that runs on workstations (and sometimes servers).

It's job is twofold: provide network auditing information, and to service the Command Centre product when it wants to get information about a server machine. This post is about the first of these two, when using the Serio Inventory Agent for network auditing purposes. Specifically, what do you do if a particular machine refuses to return any information?

This post will offer a series of steps for you to follow. I'd also remind you that you don't need to use network snapshots at all to gather this data, and could instead use the file based Inventory Agent (see below).

Troubleshooting Steps

I'll call the machine you are trying to get information about (the remote computer) the Target Machine, and the machine you are using to query from your Workstation Machine.

1. Is the machine switched on? From time to time we have people call us reporting that they can't get data from a particular Target Machine, when the Target is either off or otherwise disconnected from the network. Sometimes it's because the IP address that they think the machine has is not the one it actually has, and their test Ping is actually pinging another machine. Regardless, don't overlook this simple check, and remember you can get info when a machine is switched off by using the file based Agent.

2. Is the SIA installed? Is the SIA actually installed on the Target Machine (we've had a number of cases where it isn't, but users were trying to query it anyway). Go to the machine, or use Serio Remote Desktop. Go to Add/Remove Programs (aka Programs and Features for poor souls using Vista) and see if there is an entry for Serio Inventory Agent. If not, install it.

3. Did the SIA install correctly? On the Target Machine, can you see a Service listed in Services (accessible via the Control Panel) called Serio Inventory Agent? If not, de-install and re-install. If it won't install, check the Event Log as described in Step 5.

4. Is the SIA Service running? Using the Services control panel applet, check the status of the Serio Inventory Agent Service on the Target. It should say 'Running'. Then check the Task Manager in windows to see if something called 'SerioAgent.exe' is running as a task (they are the same thing). If either of these is not shown, re-start the SIA Service, and then proceed to Step 5.

5. Is there any information in the Event Log on the Target Machine? Normal Windows applications can just display a dialog box when something goes wrong. However, for Services it's a little more tricky - Windows doesn't allow Services to do this. Instead, error messages and status information is written to the Event Log. To read these messages open the Control Panel, click on 'Administrative Tools' and then double-click the Event Viewer. You'll find messages from the SIA (Source - Serio Inventory Agent) grouped under 'Application' (Vista users: Windows Logs/Application). You should see messages like this from when the SIA was last started:

Serio Inventory Agent startup data: Port=17070, MultiHomedIPAddress=.

This message means that the SIA is listening for requests on Port 17070 (yours may say something different, like 161) and that no multi-homed IP address is set (that's usually fine, as most computers don't have multiple network cards). Make a note somewhere of the Port Number you are using.

"Serio Inventory Agent" started successfully.

This means that all startup and initialisation finished without error, and the SIA is ready. If you don't see such messages, you will probably see error messages instead. If you see one that says

The requested port is in use - is there another SNMP agent application running on this machine? means that you have what is called a Port Conflict, and nothing is going to work until you resolve it. Almost all the problems we see with installs are Port Conflicts. If you see this message skip to Resolving Port Conflicts below.

6. If everything checks out OK on the Target Machine, let's run a few checks on the Workstation Machine. Run the Serio Workstation Explorer (SerioWe.exe, you'll find it in your Serio directory). From the Edit menu, select 'Edit Advanced Settings'.

Grouped under Network Options you'll see two numbers:

IP Port used for sending requests

IP Port to send requests to on remote machines

The key value is the second one: IP Port to send requests to on remote machines. This value should match the Port Number noted in step 5. If it doesn't, then change it and click OK.

Then try to connect to the Target Machine using the Workstation Explorer. If it works then the SIA is functioning just fine and answering requests, else skip to step 7.

7. If you get this far, and you've faithfully checked all the things listed, it might be time to place a support call - but be warned, this is exactly the stuff we'll check all over again.

Resolving Port Conflicts

If you get here, it's because the SIA is stuck on a Port Conflict. I won't go into the background of TCP/IP Ports, except to say this: IP Ports are like toothbrushes, and are not designed for sharing. You can do only one of two things to resolve a Port Conflict:

1. Stop the other Application.

Stop the application that is running on the Target Machine that is using the Port you noted in Step 5. If you are not using this application and it was installed by default, stopping or de-installing is usually the easiest thing to do. Finding out the identity of that application can be tricky, but if the Port in question is 161 there is a good chance it is the Microsoft SNMP Service that is using it.

2. Change the Port number that Serio Inventory Agent uses.

Tip: Only do this if you can do it for all machines - otherwise, having machines using different Ports will cause you an administrative migraine.

To change the Port used on the Target Machine, you can either de-install and re-install, or you can simply edit this registry key:



and set it to the DWORD value you require (17070 is usually a good value, make sure you set it in decimal). The value is applied when the SIA on the Target Machine is next restarted.

Having changed the Port Number, go back to the Serio Workstation Explorer and edit the 'IP Port to send requests to on remote machines' value, and then try re-querying the Target Machine.

Friday, 18 Jul 2008

I'm asked to write about how Group Companies are incorporated into overall IT Service Management. Specifically, what happens if your own company either buys another company or starts another company that will be run as a separate entity (with it's own capital, directors, and premises)?

Of course, I can't answer the question for you - but what I can do is consider some of the issues you might have to work through. Some are conceptual, some practical.

Sometimes we at Serio are asked 'how should we incorporate them into Serio?' when the real question is 'How do they fit-in in terms of IT Service Management'.

I'll refer to the newly acquired company, or the new start-up company, as 'NewCo'.

What is the 'Strategic Vision' for IT in the whole Group?

There may be a Strategic Vision that outlines the approach you take - these usually originate at group Director level. It may be that this will guide you on what you need to do (for instance, many companies centralise IT services, others have a horror of 'Head Office' services and want everything as close to the business and customers as possible). If you are lucky there will be such a guidance, but there is every possibility there won't - at least in my experience.

Will NewCo Management want control over their IT?

The directors of NewCo will be focussed on creating or developing their business, and may see IT as a critical component of their strategy. If so, any suggestion of incorporation of their IT service delivery into existing ITSM services might be unwelcome. Remember that it isn't necessary for them to be tightly integrated in terms of IT to be able to send and receive emails, and share files, with the rest of the group - you can set-up web portals specifically for this purpose.

Will NewCo have its own IT Service Management function?

First of all, is there any NewCo IT Helpdesk or Service Desk? What you are trying to assess is if there is any local function to integrate in the first place. The important thing is how such a service is perceived by the directors of NewCo.

How much interaction between your existing IT service management function and NewCo will there be?

...or phrased another way, 'how much will NewCo use group services'. Try and imagine how many support tickets might need to be passed between the two groups - but be realistic. How much will NewCo and your own ITSM group need to work together (be realistic, and resist the urge to over-estimate).

What are the politics of the situation?

This is most poisonous aspect, particularly in cases where NewCo is an acquired company rather than a start-up. As soon as anyone mentions 'incorporation' or 'merger' of IT services people see their jobs and (most importantly) their prestige to be under threat, any hope of co-operation can go out of the window. People start firing-off their CV's, attitudes become negative, it gets harder to achieve any kind of consensus. Alternatively, you might find two groups of people whose skills complement each other.