Managed services has been a bit of a misnomer in the telecommunications services market, they have tended to mean no more than the provision of access to connectivity and to bandwidth. Service level agreements were supposed to dictate the delivery of such services, however these have been widely misunderstood and have not been successfully measured or managed. This is particularly worrying since we are entering a world where the delivery of applications and true managed services will need governing by SLAs. As has already been demonstrated if service providers are unable to measure and deliver SLAs, for so called managed services of the past, then the deployment of IP VPN and ASP services to enterprise markets will continue to be held back and trust will be the only thing enterprises will have to rely on their service provider to deliver the service they are subscribed to. As VPNs appear to increase in ascendancy SLAs will become more important and both enterprises and service providers must work together to develop definitive SLAs.

Enterprises must take on-board the responsibility to ensure that the SLAs they agree to with service providers are the right ones for their business. Enterprises must realise that SLAs are still new territories for service providers and they are only now being properly measured and adhered too. SLAs will also need to develop further as application delivery becomes more important rather than the simple delivery of connectivity and bandwidth. If this is the case then service providers will need to better understand how enterprises will use applications and which of them will be most important, this will determine what SLAs will be measured against, however service providers may not always be in the best position to do this, so they will have to asses their own needs and requirements to help determine the make-up of the SLAs. If however enterprises are unable to take onboard this task then they will need to enlist third party assessment to fulfil this task.

SLAs have to go back to basics and service providers need to be able to formulate and measure SLAs for the simplest of services, such as connection and bandwidth availability. What we also have to understand is that the telecom industry has very little to compare themselves with the creation of and adhesion to SLAs in other industries. The few examples exist include:

Federal Express - the next day delivery of parcels, before 10.30 am, otherwise a penalty takes place.

Kodak processing stores - 1 hour processing guaranteed.

The SLAs of these two examples are easy to define since the benefit to the customer is easy to establish, measure and understand. In fact these companies set the SLAs that customer now demand, they previously did not exist and now customers’ of other companies demand the same level of service. There are other examples where we may expect there to be SLAs to exist but they do not; when we pick up the phone we expect there to be a dial-tone and we do not need an SLA to guarantee this, it is just accepted. When we purchase a car we do not have an SLA between the car manufacturer and us to ensure that the kilometres per litre travelled meets defined boundaries, we trust the car to deliver. So service providers are at a disadvantage to not only create and measure SLAs, and define what they are, but also what penalties must exist should they not be met since there are very few like for like examples in any market. The enterprises need to direct the deployment and delivery of SLAs.

Given the history of SLAs, enterprises need to learn from what has gone before and the fact that one SLA does not fit all. The advice to enterprises consists of a number of simple questions, but with though provoking consequences:

- Is your service provider able to deliver SLAs for simple bandwidth and connectivity?

- Is your service provider able to measure these SLAs?

- Will your service provider provide these measurement and data to you?

- Does the service provider have proper and easily understandable penalties in place should

   SLAs not be met?

- Are the SLAs tailored to your business environment and requirements?

- How does your business rely on the provision of the service providers’ network and the

  services it delivers? Do these relate in any way to the SLAs in place?

- Are your SLAs flexible? Do they change depending on amendments to your business

  circumstances or changes and development of the services delivered to you? Can your service

  provider evolve and develop your SLAs in the future?

- Are the SLAs delivered easy to understand?

In addition to these questions above, enterprises must also consider the variety of SLAs that must be put in place. SLAs should cover performance, procedures and reporting.

 

Performance

This is a traditional SLA to define, allegedly it is the easiest to manage but few have been able to meet their own targets. This includes availability and needs to be as close to fives 9s as possible and guarantee to the amount of bandwidth. Latency also needs to be included and is important with the delivery of applications, so this needs to be within the limits of 70 to 100ms latency, with packet loss of less than one percent. Generally service providers have tended to throw bandwidth at such problems, but this does not optimise network efficiency and just postpones the inevitable where major network overhaul is required.

The delivery of applications is based on the performance of the network, however there are measurables, SLAs that can be specified for applications used by you as a customer. This could include the number of users that can be supported simultaneously, application features and upgrading of application features.

Performance criteria must be specific to each enterprise that adopts a 'managed' service.

Procedures

Lack of procedures within a service provider can lead to massive customer dissatisfaction. Enterprises must ensure that the procedures that govern response to customer support and concerns are also covered with-in SLAs. Measurable’s that could be covered by such SLAs include how complaints are dealt with, queries dealt with, speed of response, when applications should be upgraded, who deals with the enterprise should the account manager be away on holiday, the addition of new users and applications. The who, what, where, when and how, of resolving problems and issues that may occur as a result of using a service, must be put in place to address all eventualities that you as an enterprise may encounter and your service provider must have SLAs covering these procedural requirements. Procedures will become more important as the complexity of services and applications increases.

Reporting

SLAs will also need to be established to ensure that information delivered to you concerning performance and procedure SLAs adhere to certain requirements. The rate at which this information is received depends on the rate at which it can realistically be measured, assessed and reacted to. However, the most optimised solution would be an automatic one where a software solution is able to do the relevant calculations in real-time and flag up any major recurring problems and have the service provider react to them.

As an enterprise you must take more control over the deployment of SLAs, you are in the best position to determine what is important to your business and how your business relies on the services, a service provider proposes to deliver to you. You must not rely on the service provider to develop the SLAs for you, we have provided some of the questions you will need to ask of your service provider and some of the less obvious SLAs that must be taken into account. Once you have decided what is important to your business it will be easier to develop SLAs that are relevant and critical to your needs.

Ref: TP0042A02V01