SLA requirements for an Outsourced IT Support
When a business decides to outsource its IT function to a managed IT services provider, that decision hands a key business operation to a third party. It brings in its wake a raft of tasks that define the nature and extent of the outsourcing itself, any specific requirements that follow from the nature of the business, and any other measures that are needed to protect the business.
The outcome of these tasks is usually a Service Level Agreement (“SLA”), a formal document signed by both parties.
Traditionally the SLA focussed on the tangibles, the management and maintenance of the hardware and software. Increasingly, they now contain elements relating to softer targets, such as the performance of the managed it services organisation management.
What shouldn’t be forgotten is that the SLA is a mutually agreed instrument that defines a business relationship between two entities. It is not a blueprint for financial advancement of the managed IT services organisation, nor is it a mechanism for the client to unload its costly IT problems. It should define a mutually beneficial business partnership that neither unduly enriches nor penalises either party.
In some environments, it may be beneficial to use IT consultancy services to provide guidance and advice and to remove any adversarial elements from the SLA preparation.
The ownership of hardware and software needs to be clearly defined. If the transfer of ownership to the managed IT services provider is part of the outsourcing deal, then a schedule of the equipment to be included and its appropriate value needs to be included. The schedule should also include a list of retained equipment and if it is covered by the SLA.
This may be tricky with software. Some environments have special pricing which may fall away if the ownership of the software is transferred to the managed IT services provider.
Equipment will need to be replaced from time to time, either following failure, as part of an equipment refresh cycle or a planned upgrade. The SLA needs to set out who will be responsible for the purchase and procedures for reimbursing the managed IT services provider. The refresh cycles for different equipment need to be clearly set out.
On-Site Support – Scope of Work
One of the most common arguments is whether a service is or is not covered by the SLA. What must be included are specifics of all services to be provided and what’s to be excluded. If in doubt write it in.
The SLA must include a definition of each service, a statement of service availability, any differences in service levels, for example between the core and non-core time, and the service levels required:
- The roles and responsibilities of each party in delivering the service need to be clearly set out.
- Some services, for example, business critical services may have non-standard modifiers, for example, escalation procedures or penalties. These must be clearly set out.
- Processes to be followed if the SLA is to operate in a multi-cultural and/or multi-language environment.
On-Site Support – Service Availability Metrics
A common failing in preparing an SLA is to over-engineer the measurement and monitoring. Keep it simple and where possible use standard metrics that can be automatically retrieved. More complex systems will not be effective. Systems needing manual data collection and analysis will soon fall into disrepute.
Typical metrics include:
- Service Availability. This defines the amount of time the service must be available for use, usually expressed as XX.YYYY% The metric may vary according to the criticality of the service.
- Failure Rates. The absolute number or percentage of failures or errors in major deliverables.
- Security. Metrics about anti-virus performance, firewall management and unauthorised access attempts. The number of security incidents.
The management portion of an SLA is equally important. While the Service Components section defines what is to be measured, the Management Section sets out how the SLA is to operate and defines any measurements and penalties.
Inevitably there will be arguments from time to time. The SLA sets out how problems will be resolved or escalated in a controlled manner. The formal contract will also include some legal boilerplate on the matter.
Reporting processes, content and frequency
Over time an SLA becomes part of the furniture and is ignored rather than observed. There must be formal SLA reviews at regular intervals as part of the normal management process and follow‑up of previously noted items.
- Indemnification of the managed services provider against third party liability and consequential loss.
- Change Management of the SLA itself.
The environment in which the SLA operates will change during its lifetime. There must be a defined process through which the SLA keeps up to date.
The SLA is, simply put, a document that protects the interests of both signatories, the business and the managed it services provider, during their joint venture. It should be a symbiotic document that acts in the interests of both parties without enriching or penalising either.