www.goitil.co.uk/blog.html

A full history of our articles has also been moved to this address

Comments

2) The credit crunch time has arrived. How can we save money on our IT services ?

Comments

1) Application sizing and capacity modeling
2) The expanded incident lifecycle

I am not sure why these are so popular, but in order to continue to fill this niche / requirement, I am quite happy to share my viewpoints and experiences with people. I will certainly look to develop a number of articles about this, but if you have a question or viewpoint you would like to share / discuss, please do not hesitate to email me on:

enquiry@goitil.co.uk

As the heading of this blog states - "Consultancy costs, but advice and viewpoints are free"

Comments

Share and share alike!

A recent client has given me permission to anonymously post a summary of a service management audit on both the blog and the website as a way of sharing how small businesses could benefit from such a review. The client in question was a motor trader who had been in business for several years, running a successful car sales business with a well established reputation in the area. They openly admitted that they were car sales professionals who had cut their teeth in the market but did not really have much of an ideal about IT. The initial consultation came abut as their windows based PC kept throwing up messages about an unlicensed copy of XP and they were thinking about buying a new PC to get rid of it. Within 2 hrs of spending time with them the following points were unearthed:

1) They did not need to buy a new PC. They had picked it up from a computer fair and it was riddled with copied software. The main PC was of a good spec and we were able to source a local PC guy who could rebuild it and price up XP, office and an anti virus product to bring them up to compliance
2) They had no disaster recovery for their two main services (email and autotrader updater) but once again we were able to discuss how these services could be accessed from another PC with a view of installing the auto trader application on a second PC at one of the owners houses as a contingency plan
3) Two key suppliers needed reviewing. Firstly it appeared that their website hosting and delivery to the internet had not been written to current standards and did not capitalise on any Search Engine Optimisation. Secondly their credit card authorisation company had been delivering a poor service for some months, but they did not really know where to go

A report was provided outlining the key points and possible solutions and is currently being reviewed by the client.

If you feel this type of service would benefit your small business and you would like to see a copy of the report (in which the identity of the company has been masked) please feel to contact us on:

enquiry@goitil.co.uk

quoting CustRep01

Comments

For the majority of SME’s, the main IT suppliers may be faceless organisations whose main method of contact is via a website or if you are really lucky a call centre. Just because the supplier does not provide you with a personable account manager, does not discount the fact that you should avoid carrying out a regular service review.

Going back to the principles of good service management, the key objectives are to maintain or improve system uptime, to reduce costs and to drive better value for the companies IT services.

Taking these principles as our guiding light, we can still carryout a service review for our faceless suppliers.

How ?

Well let’s take a few typical suppliers:
1) Voice and Data Telephony supplier
2) Web Hosting Service
3) Main Hardware Procurement Source

What do they all have in common?

Well firstly they provide a service, probably one that can be measured and hopefully with a level service availability. This may not be clearly quoted in your contract documentation or may be implied but with a bit of pushing your supplier may provide a “target” figure
Secondly, they will carry a cost of service and one that could be compared with other like for like suppliers.
Finally a soft measurement of customer service could be established based upon you engagements with them.

So now we have a couple of points of focus but how do we use this information to carryout a service review? Well the first thing that needs to be decided is how often to carryout the review. This may be driven by a renewal date, a regular cycle (eg every 3 months) or may be triggered by an outage or bad customer service experience. Either way, the trigger for the service review needs to be established.

Once you decided to have the review, get any support documents or contracts out and look for information relating to service metrics. You are looking for measurements, service charters, targets, in fact anything which can be measured. If nothing exists, contact your supplier and ask them what their service metrics are (eg if I lost voice capability, how quickly after placing a call should I expect an engineer and then following that how quickly should I get it fixed). Also ask them where they publish their results or if they don’t how you are able to access them.
Next, it would be worth while digging out any commercial documents Get a feel for the cost of the service you are paying for and if possible get a few like for like quotes from other companies. Don’t forget to factor in any exit costs and the cost of moving supplier including any costs in terms of time etc.
Finally write down your thoughts regarding how you feel about your supplier. A good way to do this is to create two simple lists titled “Highs” and “Lows”. Record any good points under the Highs and any bad points under the Lows.

In the next chapter of this subject, we will focus on how to actually carry out the service review.

Comments

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.

Comments

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…

Comments

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!

Comments

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.

Comments

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

Comments

The previous chapter on this topic started to explain how a CMDB (Configuration Management Database) starts to come together and also explained how SME’s have a huge advantage over larger organisations.

But it’s OK having an advantage, but if you are never going to use the information its just a waste of effort. So here are a few ways that a CMDB may assist an SME with managing its IT estate:

1) Inventory Management – The simplest use of the information in your CMDB is to keep tags on your IT inventory. Whether it is to assist with your annual accounts, to provide a financial value of your IT estate or to clearly demonstrate what pieces of IT equipment you need to get back off of people when they leave, linking people and locations to the basic level of CI information gives you immediate control. Add financial value to the CI and suddenly you have a true valuation of your IT equipment.

2) Upgrade strategy – By linking how your pieces of IT equipment are dependent on each other, when you come to upgrade you can clearly see what parts outside of the most obvious considerations may need to be reviewed. It could be that an application currently runs with its data held on a central server. By upgrading the application, it may also mean that you need to upgrade the operating system on your server. But what about all of the other applications that link to this server? Will they operate with the new level of operating system? By reviewing your configuration diagrams, the other considerations of your upgrade will come to light.

3) Upgrade strategy – With most organisations being Microsoft based the ongoing need to upgrade both operating systems and office applications is becoming more regular. By including all of your PC estate as CI’s (Configuration Items) and by recording basic information such as processor speed, size of hard drive and on board RAM, decisions about how much of your estate will take the upgrade and how much needs to have money spent on it bringing up to minimum spec are quite straight forward.

4) System failure – When something goes wrong, a picture really does paint a thousand words! Those decisions made 3 years ago when you were putting the system in added to the changes made 6 months ago are easily understood when viewed as a simple system diagram. You can now start to look at your service and try to work out what may be causing the disruption. This is also useful if a known component eg your broadband line) fails. By reviewing all of the CI’s attached or dependant on this item, the size of your problem can be assessed very quickly

5) Cost reduction program – Whether it is making your known assets work harder, deciding not to buy something because all of a sudden you realise that you have a spare one or carrying out a review of your services to consolidate your supplier’s, the presence of configuration information can lead to cost savings. This is not an easy task as the ground work a developing your CMDB need to be done first BUT once you have your CMDB in place it should be fairly straight forward to review your IT estate an identify where possible cost savings could be made.

Goitil’s consultancy services are designed to help SME’s reduce their costs by implementing the right level of ITIL discipline for their business, without impeding on your day to day operation.

The starting point is our free health check which will allow your consultant to start identifying how your configuration information can increase your service availability and reduce your costs. For more information, please visit us at:

www.goitil.co.uk/Healthchecks.html

Comments

Its been a while since we picked up the thread on Configuration Management and really of all of the ITIL disciplines, this is one where I firmly believe that the SME has a significant advantage over larger organisations. Why is that? Well configuration managements two biggest enemies are scale and people.

I will explain why but firstly lets recap on what Configuration Management is, it purpose and how it differs from Asset Management.

Config’ Management is about understanding you IT estate whilst Asset Management is purely a list of everything you own.

Most IT things that you own can be referred to as CI’s or “Configuration Items”. Common examples are PC’s, printers, network routers, servers etc but it also extends to documents such as user guides, SLA’s and support contracts. Anything that makes up your computer estate and “could” change is part of your CI estate.

Once we have identified what CI’s are important to us (and for every business this is different) we need to record them somewhere. This place is normally referred to as the Configuration Database (or the CMDB ). Now this does not need to be a single database, if fact it can be a mixture of different pots of information in different formats, but in its collective form a CMDB is born.

Finally the CMDB makes links to each CI where they touch. For example a system might be made up of the following:
1) A PC
2) A Printer
3) A connection to the internet via a wireless
4) A set of software
5) A set of user manuals
6) A support contract

Now once again, with our rudimentary CMDB this could a list of manual diagrams or reference tables. The important thing is that everything is connected where possible.

Now we have a good understanding of our estate we can start to use the information for our benefit. Areas such a as system failures, reviewing service and approaching system upgrades all benefit from a good CMDB (and that will be the topic of the next chapter of this blog) but finally let answer my original question.

Why do SME’s have the advantage?

Well as I indicated at the start of this subject it really comes down to two things:

Scale: Let’s take a typical support centre for a large organisation. One main head office (1000 people), a number of satellite offices (4 sites with 30 people in each site) plus a field based sales team (100 people with laptops). This is supported by approx 30 different systems hosted on 25 different servers, 40 support contracts……etc etc etc. Where would you start with your CMDB and would you even want to start with the dependencies?

People: Even if you do get your CMDB in place, this is where it starts to go wrong. Mrs Jones is on maternity leave and Miss Smith thinks that Mrs Jones laptop is better than hers so they agree to swap whilst she is off on maternity leave. Whilst this is going on, Ted in accounts finds a little program that will help him with his tax calculations. He knows someone in the desktop team who installs it without a call to the service desk and now we have an unsupported piece of software which is probably dependent on data help on a central file store. People cause CI information in the CMDB to become corrupted.

Because of the reduced size of the IT estate in SME’s you have such a huge advantage over larger organisation.

If you would like more information about how to approach setting up a CMDB for your company please visit our website and request our free report:

http://www.goitil.co.uk/Freereports.html

Comments

http://www.best-management-practice.com/gempdf/ITIL_Glossary_V3_1_24.pdf

Comments

Although two of the lesser used sub processes of capacity management, these offer great opportunities to prevent system down time as they are forward looking and prepare you for what might happen.

The easiest way to distinguish between them is to thing of Application Sizing as something you do BEFORE implementing a new system whilst Capacity Modelling is something done ONCE the system is in and established.

So lets look as Application Sizing first…..
You decided to buy a new photo editing and storage program. What things do you need to consider?

Well firstly you will need to look at the basic system requirements. This may consider things like operating system level but from a capacity viewpoint will also consider requirements including processor speed, memory requirements and Hard Drive space.

Once we have looked at the basic‘s we could move onto to data transfer. The program may store files in different formats (eg accepting RAW images). This may increase the size of the files and if transferring them via the internet, you may find that your service does not have the required bandwith or your email system may have limits on the size of the file.

Finally, the introduction of new functionality or file types may increase your storage needs. At this point you may need to review your current available space and consider options to increase this (such as external hard drives).

This example illustrates a typical walk through of application sizing and whilst various combinations of application and infrastructure types exist, the principle remains the same. The key aim is to consider all aspects of the introduction of anew application to ensure that capacity issues are addressed prior to implementation.

Capacity Modelling is a process that is based around “what if” scenarios. A real life example from a high street retailer is illustrated as follows:

Following the introduction of Chip And Pin credit cards, the data file sent to the banks now contains additional information. This resulted in the file being 3 times larger. This was not a problem as the system had a 3hr dialing window to contact the bank and transmit the data. At the end of the window the connection terminated whether the data had completed or not. On the final week of Christmas 2005, the dial did not completed and the retailer lost several days interest. Why was this ? Quite simply in the final week of Christmas sales went up which meant more people used credit cards. This meant that the data file was bigger. In previous years their had been no problem getting this information to the bank in the 3 hr window but as Chip and Pin had trebled the size of the file, it failed.

So how does this fit in with Capacity Modelling?

Well going into Christmas the variable’s were known as follows:
1) The size of a data file for one transaction
2) The budget for Christmas week
3) The percentage of people that would probably shop via credit card
4) The normal transmitting times / rates

This would give the IS capacity Manager enough data to estimate the size of the data file and also to model that nights transmission to see if it would fit.

That is the basic principle of Capacity Modelling – taking known data, applying it to a set of given circumstances to see if a service breach would occur.

Hopefully the overview of these two processes gives SME’s a few extra tools to use during the day to day management of current systems or things to consider during application upgrades.

Comments

Goitil was specifically set up to offer IT Service Management advice to SME's and based upon the initial press releases, it is probably unlikely that ITILv3 will directly benefit SME's outside of the scope of the current processes outlined in the Service Delivery and Service Support books of V2.

Once the new process books have been launched, we will be reviewing them to understand the benefits to SME's. If and when it is found that v3 does provide a direct benefit to SME's, then the website and the blog will be updated to reflect this, otherwise, Goitil will continue to offer its advice and services based upon the V2 framework.

It is anticipated that this review will take place during the end part of 2007.

Comments

In the first part of this topic I explained the four basic concepts of capacity management, these being:

1) Capacity Management
2) Capacity Planning
3) Application Sizing
4) Capacity Modelling

So how does this fit into an SME? Well it is probably best to take the four processes and pair them as 1 & 2 (essential) and then 3 & 4 (desirable).

Capacity Management and Planning should really be considered essential for any business, as they really are part of the foundation of providing a stable and reliable set of IT services. The two key elements that drive most PC’s are processor utilisation and memory (whether that is RAM or Hard Drive). The purpose of this blog has never aimed to be technical so please forgive me for not delving down into the whys and wherefores of this area. In essence, I would ask you to consider the following questions:

a) Do you know how much hard drive you have, how much space is taken up by your data and how much this changes on a weekly basis
b) Do certain applications take a long time to load or perform poorly when you carryout certain steps
c) What do you do with data that is old and does not need to be used any more
d) What do you do with applications that you no longer need
e) How do you back your data up
f) Is your business likely to change in the foreseeable future

I hope that by asking these questions, you should have a picture of the way your IT is behaving. Now you really need to carryout a few basic tasks

a) When looking at your amount of disk space vs. usage, I have always worked to a threshold of 20% no fly zone. This gives the system enough space to move files around and you as a user enough space if some unplanned data comes along. If you are in the no fly zone, you may need to housekeep or invest in some extra disk.
b) Map your disk usage over several weeks (ideally weekly on the same day for 8 weeks). Plot this as a trend and extend the trend line. Mark on the axis representing size of data, the size of your drive and then draw a line at 80%. See where your trend line crosses these two points and be aware that you will need to take action before these points are met
c) If you are having performance issues, you may have capacity issues with memory usage. Whilst this is less common (certainly with the size of memory issues with PC’s) it may be worthwhile have a system health check carried out by a local IT company. If you are technically savvy you may be able to use some of the basic monitoring tools (such as the task manager in windows to show CPU and memory usage) alternatively you may wish to research monitoring tools (a Google search on “PC Memory Monitoring Software returned several positive leads). The whole purpose of this activity is to know if your system is being over stretched, Good capacity planning would review this not just as a snapshot, but also in set time windows to see how resource demands change during the day and throughout the week.
d) Look at ways of freeing up space. As well as archiving data, you may have old programs that can be un-installed

I hope that the pointers above (which only scrape the surface of capacity management & planning) give you a flavour of this topic and how it affects an SME.

To summarise:
Capacity Management is all about managing the today. For each of the key system resources you should know what you have, what is being used and what threshold you want to work to. If you every breach the threshold you should be considering taking remedial action
Capacity Planning is all about projecting your trend. By taking capacity usage information on a regular basis and projecting a trend line, you should be able to predict when you are going to run out (or breach your thresholds). The purpose of good capacity planning to stop a capacity related outage occurring by knowing when the problem is likely to occur.

We have used the example of disk space and memory utilisation as two examples, but in a similar way, this could relate to network bandwidth or power/ports. Any resourced used by an IT system can come under the scope of capacity management.

In the next part of this topic, we will start to look at Application Sizing and Modelling.

Comments

For the next subject I would like to start looking at capacity management. The normal response when this subject is raised is to automatically start focusing on disk space and data management, but capacity management is much wider than that.

As well as basic capacity management, I hope to cover the following areas:

• Capacity Planning
• Application sizing
• Capacity modelling

So to start off, let’s explain these terms:

Capacity Management: This is the process of making sure that system resources (whether it is disk space, memory requirements, network bandwidth etc) are kept within acceptable limits. When breaches occur, capacity management is responsible to taking remedial action

Capacity Planning: This is the process that ensures future capacity requirements are considered based upon current usage, viewable trends and knowledge of business activity

Application sizing: This process considers any projects or initiatives you may have with regard to introducing new software or services to ensure that they fit on you current infrastructure

Capacity Modelling: A step on from capacity planning, this process is responsible for running the “what if” scenarios to see if risk areas (that may cause you capacity based service breaches) exist

The next entry on this subject will start to explain how this fits in with a SME and introduce some basic questions to review your current situation

Comments

During this article, we are going to look at the two components of the expanded incident lifecycle that you can not directly influence. These are the “response” time and the “repair” time (sometimes called the “fix” time).

Now these are really influenced by your “doer’s” which will probably fall into one of three camps:

1) External Third Parties
2) Internal Technical Resolvers
3) Internal “Mr Fix it’s”

The first one is quite straight forward as these are any technical support providers that lie outside of your organisation. These could be formal contract for a piece of application software negotiated specifically for your organisation or more general contracts such as with your broadband provider which tend to be a “on size fits all” agreement

With regard to the second two categories, the main differentiation here is whether it is part of the persons day to day job (bullet 2) or whether that have a day job in your organisation and just happen to be know as the person who knows a bit about “system x” (bullet 3).

Regardless of which camp they fall into, the first step is to document the the services they support and make a record of the response and fix times they quote. For your third parties, this may mean getting out support contracts or contacting their helpdesk / customer service line. For your internal resolvers you will probably not have agreements, so your starting point may be to document what is achievable.

You may find yourself in a situation where some services have gaps (ie no information) or the information you are provided with is not acceptable (eg BT may quote a fix time for a residential broadband line as 4 days – for a home based business dependant on email as a sales confirmation tool, this may not be acceptable?)

Now this is where we get into one of those ITIL crossover points as availability management is starting to touch on service level management…..

To shorten your incident lifecycle with your third parties, you may need to review your suppliers or renegotiate you response and fix times. Alternatively you might want to review the recent times you have had to call on their services and review their actual performance against their quoted figures. When renegotiating, you will have to consider the cost vs service factor. You may be able to get the response time down from 4 hr to 30 minutes but at what cost increase?

For your internal resolvers it can be much more simple as the constraint is usually workload priority. You may want to consider a “trial” improvement on the current response / fix times where the new metrics are worked to on a “best endevours” basis but are not binding. Once the impact on their day job is identified, a more formal agreement could be considered.

Comments

We ended the last chapter of this topic by saying that we can help ourselves shorten the downtime by focusing on the following key phases:

1. “Detection elapse time”. This is how long it takes the user to report the fault once they have noticed it
2. “Response time” is how long it takes whoever is fixing it to start working on the problem. For some contract’s this may be a contractual key performance indicator
3. “Repair time” is how long it takes to get the service back into an operational state. Once again, this may be contractual
4. “Recovery time” is how long it takes to get users back onto the system once it has been fixed

So how can an SME with limited or no IT staff help themselves in this area?

Well really we need to focus on 1 & 4 above and this is where good incident and problem management start to come into it. We have already discussed in previous threads, how the service desk is the starting point of good ITIL practices, but most SME’s can not afford an investment in either people or toolsets to deliver this core principle.

But it does not have to be complex and the easiest way to shorten step 1 above is have a nominated IT contact which is publicised to everyone in your organisation. In doing this you may have to consider shift patterns (so a designated deputy may be worthwhile), but either way, your staff need to know who to talk to if they have an IT “issue”.

Once this person in place, a basic call logging tool can be developed to take basic information such as their name, department, contact number and the nature of the problem they are having (not forgetting to also capture the date & time). It is normally good practice to issue them with a call ref number, so a sequential numbering system on an excel spreadsheet would do it.

Now what we have just talked about is the “theory” of ITIL, but what does this really mean to a SME? I would hazard a guess that you culture is not about being a mini IT department, what you want to do is focus on your core business. So let me put another slant on it (not from the ITIL book).

If you really want to reduce the first phase of the incident lifecycle you really need to develop a culture / awareness within your staff to report anything about their IT equipment that does not seem to be normal. It could be as simple as the PC seems to take longer to boot up or the odd pop up message that they get every now and again. Why is this important? Well firstly they will get into the habit of noticing when things are not right and hopefully reporting them (which should help spot future more serious problems and also provide you with the starting point of trend analysis) but more important if people are use to and comfortable reporting the minor problems, when you do have a more serious issue, they will be conformable reporting it and will know who to go to.

Remember the aim here to reduce the total incident duration by looking at each component of the incident lifecycle. The starting point is the lag from the user identifying they have a problem to the point that they report it.

Next we need to look at recovery time. This is the period of time between the service being restored and the users getting back onto the system. Once again, it is worthwhile looking at this from the pure ITIL viewpoint and also how an SME would implement this.

The communication to the user that service has been restored would normally come from the service desk as one of the final parts of the incident management lifecycle. In terms of our “simplified service desk”, this would mean the person who entered the incident onto our spreadsheet, contacting the user and letting them know that everything is OK now. Likewise if it was more of a major incident where multiple users were impacted, it may result in several people being told. Once again, the focus here is on reducing the elapsed time between the service being fixed and the users getting back on.

So what does this mean in reality? Well it will be different for every SME, but it all comes down to efficient communication. You may be a factory operation with a large production floor which has lost its main LAN. Utilising a tannoy system could communicate the service restoration to all users in a matter of seconds. A loss of you ISP (which results in downtime for your email service / internet use) may be best communicated to an office on several floors by having “super-users” in each team who receive the initial message and cascade it out to others.

Hopefully this chapter has been of some use and should give you a couple of pointers in shortening your incident duration. Obviously the ideal step is to look at setting up a simplified “service desk” and call logging process but even as a minimum it may be worth looking at how you would communicate both the failure and restoration of you core systems in a way that suites your organisation.

Next time we will look at the other two steps which involve your engagement with the supplier / fixers.

Comments

So you happen to have a system fail that caused your business an amount of disruption or maybe some loss of sales / profit. It could be that you were fortunate and had a support contract in place that allowed you to restore the service, or possibly no contract was in place and you had to source a supplier quickly?

Once the service is restored we really need to work out the downtime. Why ?

Well for two main reasons:

1) You may have a support contract that has performance metrics in terms of response and fix times
2) We need to understand how the incident breaks down to look at areas where we could shorten the duration

So how do we measure the downtime ? Well every incident follows what ITIL refers to as “The expanded incident lifecycle”. Each incident will go through various stages with some key measurements being established (and used to reduce the downtime if future outages occur).

1) Incident – The point that the user notices the service failure
2) Detection - The point that the service failure is reported
3) Diagnosis – The point at which someone starts working on the issue
4) Repair – The point at which the cause of the incident has been fixed
5) Recovery – The point at which normal service is technically provided
6) Restoration – The point at which the users commence using the service

So how can we help ourselves shorten the downtime ? Well these are the key measurements:

a) “Detection elapse time” is the difference between 2 & 1. This is how long it takes the user to report the fault once they have noticed it
b) “Response time” is the difference between 3 & 2. This is how long it takes whoever is fixing it to start working on the problem. For some contract’s this may be a contractual key performance indicator
c) “Repair time” is the difference between 5 & 3. This is how long it takes to get the service back into an operational state. Once again, this may be contractual
d) “Recovery time” is the difference between 6 & 5. This is how long it takes to get users back onto the system once it has been fixed

So really when looking at the time a service is down, you can analyse the “incident lifecycle” in two ways:

A & D focus on your operation, as these are under your control. The more efficient you are at reporting the incident and communicating to your users that the service is back, the shorter your incident downtime

B & C focus on the technical resource and how they work on your incident (including contractual obligations).

In the next chapter of this topic we will drill down into these points in a little more detail

Comments

If ITIL was a car, Service Delivery would document just how that car is to be used. It would also represent your strategy to ensure that in 5 years time when it needs to be replaced you have the funds availability, or if your circumstances changed you would have a plan ready to decide how to get from A to B with your new requirement in mind.

They are broken down as follows:

Service Level Management - This process focuses on documenting the level of service expected from suppliers to the end users and then managing this chain to ensure the company is getting the best availability for its money. The key outputs from the Service Level Management process are the following:

1) Service Catalogue - A simple list of every IT service used by your end users (e.g. E-Mail). More complex catalogues can show how multiple systems link together to provide that service (e.g. Email = PC + Network + ISP + Outlook Client)

2) Service Level Agreements - A document that describes the service, when it should be available and what %age of the time. Agreements with suppliers may also include information about other tasks that are performed such as back-up's, administration, upgrades and agreed maintenance windows.

3) Supplier Reviews and Availability Reporting - Once Service Level Agreements are in place, suppliers can be managed to ensure the service you are paying for is being delivered. Information provided from the Problem Manager will show when systems have failed and this can be turned into availability figures. If suppliers have not achieved quoted availability, a well negotiated contract could have "Service Credits" incorporated to a percentage of the contract value. If you have a number of internal departments their is no reason why internal service reviews can not be created to report back just how well the availability of IT systems are running.

4) Service Improvement Program - normally driven from the service reviews, the Service Improvement Program (or SIP) is used to drive IT services forward. It could be a request for a system upgrade or a change in the way of working. All of these are logged on the SIP and a cost investigated. If the return on investment is justified, the service improvement can be moved forward.

Capacity Management - hopefully you are in the situation where your business is growing but your computing power has enough slack to accommodate your medium term plans. But what about seasonal influences? What would happen if you took on another 10 staff and they all needed space on your server? Can your network cope with a new service you access over the internet?

Capacity Management answers all of these questions by monitoring current usage, planning the future based on trends and business knowledge and modelling changes based on known factors.

Availability Management - just how much downtime can you afford or are you prepared to accept? If your email was down for 4hrs would it be an issue? Availability Managements role is to ensure that:

1) Systems are designed with Availability in mind. Whether this is "recoverability" i.e. the ability to get a system back up after a failure, or "reliability" by designing redundant components, clustering or failover mechanisms into the design, the availability management process ensures that by balancing cost against required uptime, the best solution is purchased

2) Availability Plan - Where weaknesses in design are identified, the recommended solution is recorded onto the Availability Plan. This document describes the solution, the expected increase in uptime and the cost, allowing key budget managers to shape the future availability improvements.

Financial Management - Not all companies want to cross charge departments for their IT services but the final point of Financial Management for IT Services develops the concepts of a charging model. Preceding this is the basic financial disciplines of creating an IT budget and then carrying out periodic reporting as spend is made against this budget.

IT Service Continuity Management - Depending on the size of your business, like configuration management this can either be a simple process to implement or it can make you feel like you are painting the Severn Bridge. This process aims at supporting the business continuity plans by having the means to provide a minimum amount of functionality in the event of a critical failure. This could be the loss of your main premises for a week due to an industrial accident near by or the failure of you accounts system preventing you from making and receiving payments.

Comments

If ITIL was a car, Service Support would represent your annual service, MOT, the odd running repair and keeping all of those bits of paper together just in case you ever get pulled over!

They are broken down as follows:

Service Desk - this is the only ITIL "component" that is not a process but an actual function. The Service Desk should be the single point of contact for all users in the event of them raising a concern or request around IT service. Normally, the service desk would be in possession of a call logging tool and every call would be given a unique reference number. This is then used to trace the progress of the request. The tool would allow information about the issue to be captured and basic reporting about how long the call has been open should be available. For small companies, the Service Desk could be as simple as a nominated person (or group of people) who have access to a simple database or spread sheet allowing you a single point of contact and the ability to have visibility of your IT issues.

Incident Management - the process that the Service Desk follows when getting a call from a user about their IT systems. Incident Management has a simple focus - get the users working as quickly as possible! This may be through the use of a documented workaround or known procedures. If these don’t exist, the Incident Management process ensures that the callers issue is chased on a regular basis. This is particularly important if you have agreed service levels with your suppliers!

Problem Management - sometimes it goes wrong in a big way! That’s where problem management comes in. Complimenting Incident Management, the problem manager carries out 3 distinct roles:

1) Major Incident Management - this means ensuring that all of the fixers are working together and that they are aware of any deadlines that need to be met. If it looks like they wont, the problem manager is responsible for driving out the ideas for contingency plans. Sometimes this means leaving the system down longer than needed so the real root cause can be found (and hopefully the method to prevent it happening again can be identified).

2) Reactive Problem Management - when problems happen, the problem manager is responsible for documenting the root cause, identifying process and system failures and then creating and managing an actions list to prevent it from happening again.

3) Proactive Problem Management - this element focuses on stopping problems happening before they have chance to get a hold. Predominantly this includes reviewing all of the incidents from the Incident Management process and looking for trends. Once these are identified, actions are recommended to stop them reoccurring or escalating to an unmanageable level.

Change Management - One of the biggest causes of IT system failures is change. Upgrading an operating system (including Microsoft patches!), loading a new program, adding a piece of hardware or changing your business process is all guaranteed at some point to stop your computer systems from behaving normally. The more complex and inter-dependent you services are, the bigger the influence of change on your availability.

Change Management bring’s control into this minefield by introducing some basic principles:

1) Approval - all changes must be approved by an agreed group of people who have the ability to say NO if it is deemed as to risky.

2) Testing - the change process drives awareness of testing. It is incredible how many changes are implemented without them ever being tested but by asking the question and insisting on a clear demonstration of the testing, the approval process becomes much easier.

3) Back out - If you can change it, you can normally back it out if it goes wrong. But is it just as easy as that? Does old data need to be restored? Was a backup taken before the change took place and how long will the back out actually take? The approval cycle once again requests clear back out instructions as part of its process.

Configuration Management - knowing what PC's you have is asset management. Configuration Management goes one step further and identifies how IT systems are dependent on each other. Each component is captured with additional information including dependencies to other components. Now if your main server fails you know exactly what department need it and what hours they work.

This sounds easy? Very few large organisations have Configuration Management in place because it is just too big a subject to tackle once you have services distributed over many sites and linked into multiple services and network points. The benefit for small companies is the fact that the smaller scale makes this discipline so much easier to implement.

Release Management - when do you upgrade? That’s where release management comes in. One of the most simplest of the processes, this is all about having a clear strategy for your IT services. At a simplistic level each service would have a "Release Plan". This would normally state things such as:

1) how frequent upgrades will be considered (e.g. Windows every 4 years and always once version behind the latest)
2) how the release will be implemented (on its own or as part of other releases such as an upgrade of the hardware)
3) how it will be budgeted for
4) how it will be tested and rolled out

Comments

One of the great features of ITIL is that being in the public domain; it can be adopted by any organisation. Like PRINCE2 for project management, ITIL has become the standard in IT Service Management.

ITIL is split into two distinct subjects:

Service Delivery
Service Support
Each of these subjects are split into a number of processes and whilst these are designed to interact with each other, some processes can be omitted whilst others can be implemented as single elements. That really sums up the flexibility ITIL!

As well as being a method of providing good Service Management, the following qualifications can be achieved:

ITIL Foundation: The starting point for all Service Management professionals. After a few days of training by an accredited training provider, the candidate will sit a multi-choice exam designed to demonstrate a good understanding of all of the processes.

ITIL Practitioner: Once the foundation exam is achieved, individuals may wish to specialise in a specific field. Once again a number of days training are compulsory (again with an accredited training provider) then a closed book written exam ensures that they have an in-depth understanding of their chosen field.

ITIL Managers Certificate: Not for the faint hearted, this exam involves 2 weeks of in-depth class work (one week for delivery and one for support) then normally about 3 months of solid revision. The final qualification is achieved after sitting 2 x 3hr exams which are all closed book. Five essay questions in each exam (of which 60% are based on a case study you only see 10 days before) ensures that those that pass really know their stuff!

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office

Comments

Financial Management

Comments

In the first instalment of this topic we started to build up a picture of our IT budget by identifying all of our IT services and getting a starting point of our costs. The aim going forward is to start planning a cost reduction program.

The risk here (and as with most things when you are running your own business) is the fact that “unexpected” items come up and catch you out. You then find that you have to find the money to deal with them. In this thread I would like to give some guidance on projecting forward from year 1 to create a 3 year plan (as the basis of our cost reduction exercise).

So hopefully by now we have a spreadsheet with all of our identified IT items and cost for a single year.

Step 1: add a new column for year 2 and year 3 and copy the year 1 cost plus 3%. There are lots of measurements that different organisation quote (inflation, CEL, CP etc) but the majority tend to put their annual inflation index at between 2.5 and 3%

Step 2: Take a good look at al of your hardware (printers, PC’s screens, keyboard, mice etc) and ask yourself the question “am I going to need to upgrade this in the next 3 year?”. If so create a new line on your budget for “procurement” and against each item you think you are going to need, research an indicative figure and against the year you are going to need to replace it, pace a value

Step 3: Look at all of your software and ask a similar question. Consider the fact that Vista comes out soon or you may want to upgrade to Norton 2008? We are starting to touch on release management now, but for present take an honest look at all of your applications and in a similar way if you think you are going to replace it, research the current cost and predict when you are going to replace it

Step 4: Think about your business strategy? Are you planning to expand? Are you going to emerge into new areas? Are you consolidating your operation releasing spare assets? All of this should be fed into your 3 year plan.

Now we have a more accurate view of your IT spend over the 3 year period. You may want to put some totals in place and compare this as a percentage of your turnover / profit?

So what’s next? Well really we want to look at opportunities to reduce this spend. Really this can be achieved in one of 3 ways:

1) Reduce the level of service (therefore reducing support costs)
2) Look for opportunities to move services / procurement to a supplier which offers better terms / value
3) Re-evaluate the need for the spend

The next thread will start to look at how we can define the service we have and what we want to start planning our cost reduction program.

Comments

The basic principles of ITIL service management are based around two key objectives:

1) Increase system stability and availability
2) Reduce the cost of IT services

For most of these blogs, I have been focused on the first objective, but it is probably worth starting to explore the second in more detail.

Now you could say its easy to reduce the costs of IT services – remove any services that you have not used for a while or don’t think you need. Example’s could be network support costs or the application support for a service that you have paid each year for the last 3 years but have never actually used. These could be good decisions, but before we get to that decision making process we need to understand a few basic things:

1) What do we spend on IT services at the moment
2) What is our projected spend for the future (including planned upgrades etc)
3) What services do we need to keep our business going
4) What suppliers and costs are available to deliver this level of service

Once we have these four pieces of information available, we can then start planning with a view to reducing our IT costs.

So lets focus on part 1

What do we spend on IT services at the moment?

I am going to hazard a guess that this is not going to be an easy question to answer. Unless you are running some form of finance package or keep detailed accounts you may wish to work off of some generic groups. ITIL proposes that IT costs come from the following areas:
Hardware costs - physical IT hardware assets
Software costs - physical IT software assets
People costs – cost of people who manage or administer IT services
Accommodation costs – cost of any “environmental requirements, could include power, light etc
External Service costs – cost of any third party involvement including support contracts, license fees, subscriptions
Transfer costs – the cost of any other goods or services used for the provision of IT services which are generate internally within the company
The starting point would be to list all of these as a column on a spread sheet and then over a period of time (and referencing any documents, ledgers or receipts you have), expand on the area showing the service name, the frequency and the cost. In effect you are creating the starting point of an IT budget.
If you would like more information on creating a budget as a starting point for you IT cost reduction program please visit us at

http://www.goitil.co.uk/17.html

and request our free report “FM1 – Creating an IT budget”

The next step (to be covered in the next blog) will be to expand this budget into a 3 year plan including any proposed upgrades and procurement requirements

Comments

The last blog about Availability Management looked at four key areas:
1) How service levels are driven by availability figures
2) The five key components that should be considered is the system design phase (ARMSS) – can you remember what they are?
3) The extended incident lifecycle
4) The creation of an availability plan

I promised that as part of the next instalment of this topic I would start to introduce this in the context of a small business and think that the ARMSS section is probably the best place to start as it scales to SME’s quite nicely.

Let’s consider two projects that could be encountered by a number of companies:

Project 1 – A sole trader with the introduction of a new laptop PC to be the only machine that will be used for the business

Project 2 – A small office with 5 PC’s. They are going to be networked with a basic file server and a networked printer

If we recap on the ARMSS aspect of availability management:

Availability – How the system is designed to keep it available (e.g. can it be remotely managed by the support teams, does it have two servers which are clustered)
Reliability – How much resilience is there in the components (e.g. does it run RAID 5 of the disks, does it have due power suppliers from different feeds etc)
Maintainability – How old are the components so if they fail, new ones can be purchased easily. Also is the service easy to access?
Serviceability - The type of support provided by the suppliers / support contracts
Security – The confidentiality, integrity and availability of the data

Looking at our two projects, a small business may wish to consider the following:

Project 1 (Laptop PC – single user)

Availability – Very little that can be done here. The unit is a single standalone and unless some form of managed service is thrown in as part of the deal, you are really constrained to the capability of the machine. Availability could be broken down to an application and data level (e.g. if the basic data is backed up to CD or external hard drive on a regular basis and the laptop does fail, the data could be accessed by any machine running the same set of desktop tools.

Reliability – Once again, for a single unit, reliability at a component level is difficult. You don’t tend to get resilience at this level on a desktop asset so if the PSU goes or the hard drive fail’s generally the unit has had it. Manufacturers don’t tend to shout about failure rates so identifying “the most reliable” laptop is difficult

Maintainability – Now here is the first point we can influence…..Maintainability is about IF it goes wrong, how easy is it to fix. You need to consider two things
1) Availability of parts – things like batteries, Power Supplier, Motherboards, Hard drives and plastics. Normally a quick Google for these keywords and the model number of the machine you are thinking about buying will give you an indication of how easy and or expensive they are to track down
2) Can the problem be fixed by you or does it need an IT specialist or worse case, the manufacturer. Understanding how your laptop can be fixed will give you an idea of how long you could be without it

Serviceability – Really leading on from maintainability, but looking at the specific support contracts that are available for your new laptop (e.g. is it a one or three year warranty, is it return to supplier, do you have to pay the shipping costs, do you have the option of a loan machine etc)

Security – What levels of security exist around the operating system if you had it stolen? E.g. does it rely on a password to log-on and how secure is this.

Project 2 – New network

Availability – A network for a small office is probably a simplistic affair and the introduction of remote management tools to get onto the routers may be over design, but you should ask the question of how the network is going to be managed if a fault occurs. You will probably find that it will involve someone visiting your site

Reliability – A simple network is made up of 2 key components. A number of routers / ports and cable linking them together. So if a router or port fails or you have an DIY man drill through a cable you may lose your network. When you are talking to your supplier about the network design you might want to ask about “redundancy” and wheter a primary and secondary network leg can be designed. This means that if you have a leg of your network fail, either manually or automatically a new leg can be implemented. (Think of it like a spider’s web – if you put your finger through part of it, the spider still has lots of routes to get to the other side)

Maintainability – Hopefully a new network should be built with new components. With the cost of CAT 5 cable and the other components such as routers being relatively low, a good network installation should last you for at least 10 years. You will need to expect a level of failure during this time and therefore your network should be designed to be maintained using commonly available components as opposed to bespoke items. If possible try to make the designed non vendor specific. When locating the components, think about access in the event of a service call being needed. It will be a trade off between covered access and having them where someone could easily switch them off by accident. This is especially relevant for power supplier for wireless router’s etc where it is all to common to have a network failure, only to have found that the cleaner has taken the plug out to do the vacuuming that morning !

Servicability – Dependent on who designed and installed the network, you will need to look at how it is supported. Options include yourself of a member of your staff, a local PC company, a business contact who knows a bit about networks or a specific network support company. Either way, if the networking capability of you PC’s is an important and critical part of your business, it would be worthwhile spending some time getting this support contract right (and tying it up with a good Service Level Agreement)

Security – More important if you are going wireless (although you should discuss the possibility of visitors having access to a hardwired network and the security methods that are employed). I am amazed when out driving in my car with my PDA switched in wireless mode, how many unsecured wireless networks I pick up.

These two project examples are typical of the types of IT decisions having to be made by SME’s every day. Hopefully by using the consideration of the ARMSS aspect of Availability management some of your decisions will drive a higher level of availability and less down time that originally planned

Comments

Anyway, the new site is still at:

www.goitil.co.uk

I would appreciate you taking the time to visit it and email me with your thoughts / comments

Anyway back to the blogging now......Availabilty Management

Comments

I noticed my first blog on this topic was a bit of a “here’s my experience” but did not really cover the full ITIL ground of what Availability Management is all about so hopefully this one will address that. Having re-read the materials it is quite a difficult subject to scale down to the small / medium sized business but if you can bear with this information lesson, I hope to address that in the next chapter of this subject…

So what is availability management? Well in previous blogs we have talked about SLA’s or “Service Level Agreements”, documents that are agreed with the end users that outline the level of service they should expect. Well those numbers have got to come from some where and it is the role of the Availability Manager to define what that should be. But where does it come from ? How can someone say “This service should be available 99.25% of the time”?

Well the first part is down to system design and review. When designing a system the following aspects should be taken into consideration:

Availability – How the system is designed to keep it available (eg can it be remotely managed by the support teams, does it have two servers which are clustered)
Reliability – How much resilience is there in the components (eg does it run RAID 5 of the disks, does it have due power suppliers from differe tn feeds etc)
Maintainability – How old are the components so if they fail, new ones can be purchased easiliy. Also is the service easy to access ?
Servicability - The type of support provided by the suppliers / support contracts
Security – The confidentiality, integrity and availability of the data

Secondly comes historical information. ITIL talks about the “expanded incident life cycle”. This is about understanding when a service fail’s, how the different elements of the downtime is made up (a subject for another blog!). Either way, their will be a history of uptime that can be mapped against the service to give a true representation of what is expected.

Prior to this, the Availability manager would have been responsible for reviewing the system design to ensure the correct levels of Availability have been built into the system. As always this is trade off between cost and service (ie how much you want to spend to get to the level of availability you perceive to be important).

Finally, the availability manager is the custodian of the “Availability Plan”. This document list’s all of the possible improvements that are required (normally proposed as a result of an outage and specified by the problem manager) to improve system availability along with the benefit and the indicative cost.

The next chapter of this blog will try to put this in context of a small to medium business….

Comments

So you have got the service back.Well done and dependant of how bad it was it time to either thank the techies or if they were useless, thank your problem manager!

But the job is not over. Now problem management move into the investigation phase which normally takes one of two courses, but before we go into those I want to talk about the output – the Major Problem Report (MPR)

The purpose of the MPR is to fulfil the following requirements:
1. Describe what went wrong
2. Describe what was done to fix it (normally a chronology of events)
3. Describe the reason for the fault
4. Illustrate the impact
5. Review the way the service breach was managed
6. Provide a list of recommendations to stop it happening again

The MPR is normally distributed to anyone who was involved with the outage and can also be sent to any other party with a vested interest including any person who has an acton allocated to them. Within my team, we operate a policy of a review period. We normally commit to having the MPR created and distributed within 2 working days of the service restoration and then allow people 3 working days from the point we publish it to ask any questions, query the contents or challenge any of the recommendations (especially if they are allocated to them!)

So what are the two courses we talked about earlier ? Well dependent on the size of the problem it can either be a straight forward creation of the MPR from the notes taken during the outage or a more formal Major Problem Review.

MPR created from notes:
Hopefully during the management of the outage, the problem manager would have taken loads of notes including the majority of his emotional outburst, rants and general comments about members of the resolver team’s who have got on his nerves. It should be clearly noted that these should not be included in the MPR. What is inclides is al of the good stuff incuding the chronology and the creation of the MPR can sometimes be as simple as lifting all of these note and putting them into a single report. You tend to find that as you are re-writing these notes out the action section starts to form itself as the actions jump out of the page and hit you clearly between the eyes. I usually finish the report with a final read through to see if an new actions spring to mind

MPR created via a Major Problem Review:
If the outage has been particularly disruptive or it was difficult to get to a service restoration, it is sometimes beneficial to pull together a Major Problem review. In its simplest terms it is a meeting AFTER the restoration which is facilitated by the problem manager. The notes and chronology of the outage are walked thru in great detail to ensure they are a true representation, but also to get down to a lower level of investigation that was possible during the incident. These events are usually needed when you have had to deal with a number of suppliers / resolvers that have not worked well together so expect fireworks! The benefit of getting such a group together after the event is that in the cold light of day when you play back the chronology some of the obvious mistakes jump out straight away whilst others take a bit of teasing. I have never not gained benefit from a Major Problem Review and when used correctly can be a great use of time and resource.

Throughout this topic I have referred to Major Problem Reports and Major Problem Reviews etc. You may find whilst trawling other ITIL sites that these are sometimes cited as “Major Incident Reports” and Major Incident Reviews. Don’t worry, they are one and the same. It is quite a debate when you get a group of ITIL people together as an Incident is normally related to a low impact/single user breach of service and therefore using them for major outages does not seem right……..anyway, it gives us something to talk about !!

If you would like to see a template of a MPR or a completed version please contact us via

enquiry@goitil.co.uk

In the next edition of the problem management thread I would like to cover the area of pro-active problem reviews – these normally take place when an service is indicating it has a problem or has maybe had a few small disruptions and needs someone to drive it forward before it turns into a big issue

Comments