 |
|
|
|
|
 Every time you purchase a new IT product it comes with a warranty. Most of us assume this protects our interests and, if there’s a problem, we can simply send it back to the seller. The reality is quite different – many warranties are limited in both their duration and what they actually deliver.
|
| By relying on a warranty instead of ensuring your technology is backed or still replaced by your support can be costly, and often indicative of a management strategy where quality is sacrificed to time pressures. Instead, by using ITSM (IT Service Management) you can regain that all-important control.
ITSM is not only about how you patch and record, backup or deploy systems. It involves taking a much more detailed level of management and applies to almost every area of your business, be that software, hardware, power, cooling and even utilities.
Many of you reading this will be saying ‘we're covered, this doesn't apply to us’. But if you look at your support contracts you’ll be surprised by what isn't covered. Others may be saying ‘we know what the warranties are and when they expire we add to the support contract’. If you do, congratulations! Now go and check which items are on warranty and which are already covered. Can you pull up a list showing what hardware is no longer underwarranty?
|
|
|
Warranty is not support |
|
|
One of the biggest problems with relying on warranty is that is starts as soon as the equipment is delivered. This means different warranties expire at different times. Still if a customer purchases an entire rack of hardware at the same time there is a second issue – the length of the warranty. This can vary from 30 days to a year or longer.
If that wasn’t complex enough, you also need to factor in what is actually covered by the warranty.
These three problems make it very hard to determine, with any certainty, how protected any given piece of hardware is.
All of this means we should not view warranty as a critical business support policy. For example, when something goes wrong with a piece of hardware we need it fixed today. The pressure on hardware in the datacentre means we need an instant response to get either replacement hardware or an engineer on site.
With blade systems and virtualisation we have begun to build in some protection against failure because we can quickly move workloads around. However this is, at best, a temporary fix. It buys time for the replacement hardware or engineer to fit new parts. It should not be seen as part of any warranty or support mechanism.
When you examine most warranties closely you discover that there are significant limitations in what they provide. If you are really lucky, you might have same day response but that is ‘same working day’ response. Virtually every vendor defines a working day as Monday – Friday, excluding public holidays.
There is also likely to be a clause stating that to get same day support, the call has to be logged by 11am, for example. This further limits what you can expect. A hardware failure at noon on a Friday might mean no engineer on site until sometime on Monday. If you need that hardware over the weekend to run critical jobs or as part of your general computing environment, you are facing a major challenge.
Only because an engineer visits site, does not mean that you will get the hardware fixed. He may not have the part or there may be no replacement available. If he needs to remove the hardware you could discover that you have no right to a loan unit.
When you consider the problems of determining what type of warranty each piece of hardware is covered by, you can see how any reliance on hardware cannot possibly be seen as a viable business support option. |
|
Configuration Management Database |
|
|
There are two steps to fixing this problem. The first is to ensure that any hardware, software or system that you purchase is entered into a Configuration Management Database (CMDB). A CMDB holds detailed on every piece of hardware, software and system you have in a record called the Configuration Item (CI).
One of the three parts of a CI is Ownership. This contains detailed information of when acquired, who owns it, what the warranty terms are, where it is located and when it was put on support. This information is often shared with an Asset database so that a company can account for all purchases.
For every CI, you should run reports to show what is under warranty and the date that warranty expires. This will enable you to see your current level of warranty risk, and more importantly, ensure that when a warranty expires, you can immediately do something about it. Ideally, this should be dealt with sometime before expiry.
|
|
Support not warranty |
|
|
The second step that you can take is to not rely on warranty at all. Instead, hardware should be placed into different categories – critical, important but not required 24x7 and other where you either have spare hardware, can quickly get a replacement or where the cost of support exceeds the value of the hardware.
Part of that determination should also include the impact on other systems. Take the example of a fuse. It's a very low value item, typically a few pence. If it fails, then everything relying on that fuse will also fail. If the cost to the business of any of those systems that rely on that fuse exceeds the cost of the fuse, not having spares immediately available makes no sense at all. The same is true when deciding on what level of support to apply to anything you own.
This is another reason to keep the CI under constant review. It also means that you need to understand how interconnected everything is.
All of this means that you need an effective set of support agreements with your suppliers. Each support agreement should be backed by a proper Service Level Agreement (SLA) that is monitored and enforced. Ensure that you set the SLA at the right level for the business and that is it very clear as to what is covered.
Given the relative importance of different systems, you will find that one support contract does not fit all. This is as much about the cost of the contract as it is the requirements of what you are looking to support.
Regularly reviewing the support agreements and their associated SLA is part of any quality process, ensuring nothing falls between the cracks. |
|
The way forward |
|
|
It’s all too easy to treat hardware as a commodity and not as the essential piece of business equipment that it has become. Relying on a warranty might be perfectly fine when purchasing a vacuum cleaner for home but for your switches, servers, applications software and other IT equipment, it can be a false hope.
Unless you put in place processes that ensure all critical systems, and still a large number of noncritical systems, are properly protected, you can find yourself in serious trouble when things go wrong. Wondering what the point of that warranty really was when systems are crashing and burning is a luxury you cannot afford. |
|
|
|
Author’s Biography |
|
|
|
 Industry observer Ian Murphy has been an IT Journalist for over 24 years. During that time he has written for the vast majority of UK IT titles including Computing, Computer Weekly, IT Pro and International Developer. As well as writing for publications, Ian has been a developer, systems administrator, support manager and trainer covering everything from mainframe technologies to embedded systems. |
|
| |
|
|
|
| "Many of you reading this will be saying 'we're covered, this doesn't apply to us'." |
|
|
|
|
| "Wondering what the point of that warranty really was when systems are crashing and burning is a luxury you cannot afford." |
|
|
Printable version