What IT Managers have to look for in an SLA
SLA is a must to any organization but SLA between carriers
and IT Managers has all too often been meaningless to the
end user. Why? Because, invariably, they have been drafted
from the perspective of the network provider, not the customer
and therefore, are unrelated to the real needs of the customer’s
business. Moreover the penalties have been insufficient to
address the issues. Given that service level agreements are
critical features of the ICT landscape- particularly the data
services sector where strict guarantees of network performance
have to be in place.
IT Managers have to be very careful and have a clear understanding
of service level agreements when negotiating for one. A reason
for this emerging trend is that traditional service level
agreements are of the Vanilla variety, only "one-size-fits-all"
conditions are applied to all customers with little way for
customization. SLAs of this nature tend to pay more attention
to the network providers’ core strength (resiliency of
the core backbone network availability), and perhaps latency,
being key components. Although having a network up and running
all the time is crucial, there are some more detailed criteria
that need to be considered.
What to look for in an SLA!
SLA conditions need to be clearly monitored. There should
be a clear understanding of the terms and conditions. The
first thing that IT Managers should look for in an SLA is
when a fault happens there should be a report that details
what was the fault and how it was solved. This provides the
customer with some means of confirming information and has
a mechanism to avoid that fault in future. The second thing
is that of availability and latency.
There are also other issues that IT Managers need to look
at when negotiating for an SLA. The following are some of
them.
- Proactive versus reactive fault resolution
Network providers who can manage the network on behalf of
the customer have the best overall visibility of the network.
They are therefore best positioned to have their problems
solved timorously and thoroughly. Proactive identification
of a problem may sound optimistic but customers can have
the commitment from the network providers.
- Time to fix (not time to site)
This is not simply about fielding a junior employee who
may or may not have the experience to resolve a problem
within time simply in order to tick and keep a promise made
to a customer. The goal should be problem solving not simply
a meaningless olive branch.
- Time to provision
Networks are dynamic that they also need to be fine
tuned as organizational needs change. It is meaningful that
timescales for the implementation of the core network and
any subsequent upgrades are included in the SLA.
- Network Reports
Network reports are so critical as they are a means
of providing visibility of network performance. Although
IT mangers might not look at every detail of the report,
they have to make sure that level regularity is established
as part of the reporting mechanism in case one day the report
will be crucial for decision making.
- Application specific SLAs
Nobody wants a Network for the sake of it. It is there
for business application purposes. An SLA should be business
specific. This should be a conversation that a customer
should have on their network provider.
Another key issue is whether SLAs are truly end-to-end. In
many cases, performances guarantees are only applied across
the network backbone while the last mile of connectivity from
provider’s PoP to the desktop- are often excluded from
the agreement. This can lead to finger pointing exercise with
providers saying ‘its not our fault’
We hope this provides and insight when negotiating SLA agreements.
This will better place customers than ever when entering into
service level agreements that have a meaningful relationship
to their business. In our next issue we will look at why one
should have an SLA.
Click here to visit
our Newsletter Archives
|
