www.goitil.co.uk - IT Management for SME's

ITIL Topic covered
Service Level Management

So in the first chapter of this topic, we talked about how the purpose of the service review was an opportunity to get together with the supplier to talk about how the service is being delivered and to ensure any contractual measurements are being achieved. Now hopefully, if you have forged a good working relationship with them and everything is going ok, this should be a good positive meeting and the CSIP (or Customer Service Improvement Program) should be about how the service is going to be taken forward. Other items that could go on the CSIP are improvements to the current service (at no added costs) or suggestions to take the service forward where a costing may be required.

The CSIP should not be confused with an “Action Register” which is normally used to log actions that are needed when a supplier is not performing, to bring the service back into line. CSIP’s are positive things that show how the supplier is pro-actively working in your favour and no supplier should try to wrap up and action to sort out a problem with their current service delivery as a “Service Improvement”.

So what sort of things could go on the CSIP?

• For your network support supplier it could be an opportunity to review your network, document the current configuration, ensure any router settings are saved to a separate location and maybe to suggest any technology refreshes
• For your desktop / PC support contract it could be a review of each machine with a view to ensuring all relevant patches are applied
• Other suppliers may take the opportunity to review any recent periods of downtime and provide recommendation of how service uptime could be improved

Either way, the CSIP should be a living, breathing document with the purpose of improving you’re the end service to your users, over and above any contractual obligations.

The CSIP is normally reviewed during the service review with agreements made to either progress, put on hold or remove the CSIP suggestions.

Now for a number of SME’s the suppliers may be the type that you never have direct contact with (eg Orange for a broadband connection). So how do you carryout a service review for these?

A few suggested ways will be discussed in the next chapter of this topic.

ITIL Topic covered
Service Level Management

Dependent on the size of your business, the size of your suppliers and the criticality of your systems, at some point you may want to start to undertake service reviews. Normally these are face to face meetings with the key supplier but based on the factors above you may want to start by holding internal service reviews where you start to “go through the motions” until you are comfortable bringing the supplier into it.

So first of all what are we going to cover in this run of topics?

1) The purpose of the service review
2) The service review life cycle
3) The proposed frequency of service reviews
4) Segregating your supplier based upon importance
5) Performing the service review including key documents

So we will start this chapter off by asking the question “what is the purpose of the service review” ?

Well if we look at the underlying principles of good service management

1) Clearly understood and defined services
2) Continual focus on maintaining and improving service availability
3) Ensuring best value delivery

The service review is really a mixture of the “enabler” and the “reviewer” of these principles.

Lets look at that in a little more detail. Why the enabler? Well suppliers being suppliers, they tend to be passive and the less you see them the more they are getting out of their charges without having to expend any effort. Cynical ? a little maybe but based on a law of averages of my experience a fair statement. A good supplier will engage you with regular reports, maybe a “face” for you to liaise with and a method of meeting up. Unfortunately a larger amount will keep their distance with the only real contact coming from the sales team and not the service team! So by ensuring that a service review takes place you get to talk about your “current” service and to maintain the focus on ensuring what you are paying for is being delivered. This is where the “review” part of it comes in, as a good service review is about understanding what you should be getting and comparing it with what you have received. If its not up to the mark, then actions to bring it in line should be agreed. If it’s OK, then that’s great but what about the “Service Improvement Program”. How is the supplier going to wow you even further to give your business the competitive edge.

Next time we will look at this topic in a little more detail…

ITIL Topic covered
IT Continuity

In the last chapter of this thread, we introduced the concept of risk management and started to look at services by asking three questions
1)What could wrong
2)What would be the impact of it going wrong
3)What is the likelihood of it going wrong

Hopefully from this, you would have developed your hit list of risks and are ready to start to consider what to do about them.

To start you off, ITIL offers the following as some options:

1)Do nothing – I know it sounds both obvious and also somewhat defeatist, but doing nothing is always an option. Why? Because based on the risk, probability and cost of putting contingency in place, sometimes doing nothing is the most logical and cost effective option
2)Manual Workarounds – Most systems (and this is another area where SME’s may have an advantage) can survive a period of downtime with processes being done the “old fasion way”. Manual workaround’s normally include a set of written processes and sometimes paper based backup copies of data that allow the users to continue “in the spirit” of the computer system by mimicking the key processes on paper. Once the system is returned, the backlog is processes from the written records as if it is realtime data processing
3)Reciprocal Arrangements – This concept is a little bit left field but if successful can give you a low cost solution to a major system headache. In simple terms it involves finding another local company running the same software as yourself and entering into an agreement whereby if one of your systems fails, your “reciprocal arrangement” partner lends you their hardware at their site for an agreed period of time to load your data to keep on working whilst yours is fixed. To make it work, it needs regular data backups, the technical resource to implement the switch and a regular test routine but for major systems that are expensive to provide a back-up environment for, it can be a workable option
4)VBF (Vital Business Functionality) – This option is generally used for mid range systems where the nature of the failure means that a level of recovery is possible, but not a full system restoration. Understanding the VBF basically means agreeing with the users what is the “minimum” pieces of functionality are needed to keep the business going. For a supply chain system it may be seeing stock levels and sales so orders could be placed manually or for a finance system it may be the ability to raise purchase orders. All other systems requirements are secondary and not part of the restoration strategy. In the event of a system failure, the focus is purely on restoring the VBF aspects of the system

The four options listed above should be considered alongside any other creative idea’s that are generated by your continuity team. When tackling your hit list. Once completed, you will have the starting point of an IS Continuity strategy!

ITIL Topic covered
IT Continuity

It has been a long time since we talked about IT Continuity. In fact this blog has only had one entry on this topic, so I thought I would start with a little story about a problem my team had to deal with last month.

The service in question was what is known as a “data warehouse”. In simple terms this is a big stack of disk where data such as sales, customer and stock information is dumped each day in a set of predefined tables. Tools are then used to query the data so the company can make informed decisions very quickly.

A great service and one that has become very critical. Critical to the business, but not so much that when the Service Delivery Manager and the service owner has said to the business “you need to spend money to get the level of resilience you want”, the business has gone “yeh OK, maybe next year…”

So, the service is ticking along quick nicely when a key component (the system board) goes bang. Now this service has broken most of the rules of good service management as follows:

1) The server had been taken off support as a project to replace it was under way. Unfortunately the new server was delayed and no one had pushed the decision to put the old server back onto support
2) The old server was that old that spares were not available. Worse still it was bespoke hardware and operating system so an off the shelf box could not replace it
3) All of the data that was needed for the new server (which was about ½ days work to get it ready) was on the old server. It had been copied 6 months ago but all of the changes had not been recorded and were not saved anywhere

So here we were with a chassis that won’t power up but a set of disks that we think are OK AND have the data that we required but cant be read. Finally we have a server ready to accept the data.

So where is this story going? Well two directions really. The first part is to introduce one of the concepts of availability management, and then following that I will tell you how we got the service back………..

So what’s the concept?

Well availability management is really broke into two parts, these being understanding the risk and the probability of it happening and the second part having a set of actions of how to deal with it. So reflecting back on our SME with a number of desktop computers, a central server to store the data, a broadband or ISDN internet connection and a single critical application which sits on a separate server which all of the PC’s connect to. For each of these services we have got to ask three questions
1) What could wrong
2) What would be the impact of it going wrong
3) What is the likelihood of it going wrong

By reviewing your services this way you will get a feel for what is both critical and likely. From this you will quickly identify your risk areas.

If you would like to see an example of a risk review to give you a starting point, please email us at:

enquiry@goitil.co.uk

quoting “Availability Management Risk Review Example”
In the next chapter of this topic we will start to explore how these risks can be mitigated or removed.

ITIL Topic covered
Release Management

The first chapter of this topic introduced the basic concept of releases and how ITIL defines 3 different approaches. So what we now have is the method, but to make Release Management a useable process we need something that binds it all together.

Now I run the risk of switching some readers off, as I am going to talk about something called a “Release Policy” and anything with the word policy in it can cause a feeling of “loosing control” or “limiting our flexibility”. This can be especially so around SME’s who need to be able to react to market forces and direct competition.

So what is a Release Policy? Well the best way to think of it is as a document that outlines your roadmap to ongoing upgrades and allows you to manage the future of your IT services by having a point of reference of your ideal approach.

Now it can be viewed two ways; firstly as a binding agreement that dictates your upgrade path and allows you to consider the wider picture such as budget and hardware requirements in plenty of time. Alternatively it can be viewed as a strategy document that is reviewed on a regular basis and is used as a “hand on the tiller” but not always implemented exactly as the timelines dictate.

So what could be in a Release Policy for a SME ? Headings could include:

• The name of the system / application
• How your are going to refer to it (eg internal naming convention or vendors given name)
• A statement that define when the release will be implemented (eg first quarter of year, 6 months after vendor public release etc)
• Times to avoid (may be different for each application)
• Approach towards testing and backout
• Number of back releases that will be held and for how long

A short example for your main desktop operating system could be as follows:

Release Policy: John Peters Trailers

Backout statement: Following successful compatibility testing, all issues to be resolved without backout. This may result in secondary applications being upgraded. If the problem can not be resolved within 2 working weeks, then regression to the previous desktop machines will be allowed

If you would like to see a full example of a release plan, please contact us via

enquiry@goitil.co.uk

Quoting “Release Plan example” in the subject heading