SLA - Service Level Agreement
SLAs define the formal relationship between IT and business-unit customers. Without an SLA, the customer (or business unit) does not have any boundaries for demanding resolution to something they may be a problem or perceived as a problem.
How many times have we dealt with our business partners and the demands for solving minor to major applications issues? Everyone wants it now but what we often fail to have in place is a Service Level Agreement to identify terms for solving our business unit customer issues.
To be effective, a Service Level Agreement must incorporate two sets of elements: service elements and management elements. The service elements clarify services by communicating such things as the services provided, conditions of service availability, service standards- such as time frames within which services will be provided, the responsibilities of both parties, costs versus service tradeoffs, and last, escalation procedures.
SLA, some of the terms that should be specified include:
-- What percentage of the overall time services will be available
-- The number of users that can be served
-- Specific performance benchmarks to which actual performance will be periodically compared
-- The schedule for notification in advance of network changes that may affect users
-- Support response time for various issues
I have found that sometimes the business unit wants to create an SLA to suppress complaints; however, attempting to establish an SLA with complaining customers usually backfires because the IT organization will see it as just one more thing to complain about. Before engaging in SLA efforts, the IT organization should obtain customer feedback, seek to understand the complaints, and take some small, but visible, steps to resolve the complaints. The timing may then be better to establish an SLA.