HDI - Implementing Service Level Management
8.1 Overview
8.1.1 Description
| "Service Level Management is the strategy of defining, achieving and maintaining required levels of IT service to the business user population within the organization. " |
Service Level Management is effective because it focuses on the needs of the business user as the primary driver for the development of the IT infrastructure. Rather than arbitrarily deploying computers and networks of various capabilities and capacities, an effective Service Level Management strategy takes into consideration the needs of the user population for any given application area when designing and implementing that portion of the IT infrastructure. The by-products of this activity are threefold:
- a higher return on investment in IT expenditures. By using the needs of the IT customer to specify the capabilities and behavior of the IT infrastructure, costs are understood early in the cycle. Excess capacities can be avoided; proper on-going management activities are understood, can be planned for and staffed. Capital and personnel costs can be better understood and controlled.
- fewer failures through proper expectation setting. By working with the business user during requirements and planning activities, their needs are known and IT analysts can help them understand if their expectations can be met within the fiscal constraints of the IT department. They also feel their input was considered from the beginning and they are `part of the solution', rather than `part of the problem'.
- Service Level Management can be used when initially developing a distributed IT infrastructure, it can be used to gain control over resources that may have been deployed in a more `ad hoc' manner. However, in both cases, Service Level Management should be adopted as a key strategy to be applied rigorously within the IT organization.
Service Level Management (SLM) is not new. The concept of setting a customer's expectations up front, then measuring performance to make sure the expectations are met is a necessary insurance policy in an industry where the stakes are often the continuation of internal business or outsourced to an outside vendor. However, SLM is not something that can be developed on paper. It has to be carried out with every customer of IT, both internal and external, through every support interaction, between all parties involved in 'meeting a customer's needs'. IT departments are increasingly looked upon as strategic partners in achieving an organization's overall success. This trend is driving IT to measure its responsiveness, system availability and performance in terms of the business' objectives. While IT has long provided service-level agreements (SLAs), these agreements have traditionally been defined, managed and reported solely within the IT organization, with visibility to component/element/system performance, not to service performance. Terms typically found in objective statements in this area include `timely', `consistent', `quality', `productivity' and `value'. Service Level Management is a concept that is of great importance to CIOs, CFOs, and Strategic Planners within the organization.
Service Level Agreements (SLAs) are the driving force behind Service Level Management (SLM). Operational Level Agreements (OLAs) are written agreements between the different support groups within the IT department; Underpinning Contracts (UCs) are written contracts with external vendors and supplier that support both OLAs and SLAs. SLAs are written agreements between the entire support department and the customer base. They should clearly define service goals, and prerequisites required to meet those goals. OLAs/SLAs should be flexible and fluid, to adjust for a rapidly changing technology environment and the changing needs of the customer.
Service Level Management (SLM) is the planning, coordinating, drafting, agreeing, monitoring and reporting on OLAs/SLAs. It is also concerned with the ongoing review of service achievements. This ensures that the customers' needs and requirements are fulfilled at a cost acceptable to both the customer and the IT department and that the required service quality is maintained and gradually improved. SLM involves both the customer and the IT service provider(s). Together they define, negotiate, agree and monitor service levels. This continuous communication provides a stronger relationship between IT Service Management and its customers. SLM communication focuses on continuous improvement and reaching agreement - not by holding one side or the other ransom. When done successfully, mutual relationships of respect are a by-product of SLM.
A critical requirement for SLM is for IT to establish Service Level Agreements (SLAs). Service Level Agreements are flexible, adaptable measurements that are directly aligned with business goals. Without SLAs in place, you are effectively telling your customers that you will provide support to them any time, under any conditions, without any limitations to the systems and services they have.
Service Level Agreements, and the processes associated with them, provide a methodology for introducing and implementing reasonable expectations between you and the customers you support. They establish a two-way accountability for service, which is negotiated and mutually agreed upon. SLAs can go far toward building credibility for your service organization, because they show how serious you are about providing support. SLAs can be the basis for evaluation and improving service levels on an on-going basis, and they become the standard for communicating service expectations throughout your organization.
Service Level Agreements are not enough to ensure the timely delivery of service as needed by the business. Operational Level Agreements (OLAs) need to be put in place between all IT groups to unify service delivery throughout IT before executing customer SLAs.
Operational Level Agreements establish specific technical, informational, and timeframe requirements needed for each IT group to provide the services that will be delivered to the customer. For example, the security administrator might require specific information, as well as a 48-hour span of time to create access to a specific service for a new employee. This needs to be documented and agreed between IT groups before the Support Center establishes an SLA with the customer.
Without OLAs in place, Service Level Agreements will frequently promise services that are impractical at best or impossible at worst. Clearly defined OLAs will prevent unmet promises to customers. Additionally, OLAs will present (and even create) a more united IT department to the customer. Ultimately, OLAs will hold each group accountable for their service, and also build understanding of each group's contribution to the overall delivery of service.
Key performance objectives and internal incentives need to be associated with OLA compliance throughout the entire IT department. Since the goal of IT is to service the business, well-defined OLAs should provide a template of objectives that show managers those activities that are most appropriate to monitor, report and reward. Lastly, OLAs need to serve as a benchmark whenever Service Level Agreements need to change to meet business requirements. If a specific service is required faster or differently by a business unit, the OLAs will show exactly which groups need to be consulted, and which services provided by those groups will ultimately affect the delivery of the desired service. If the providing group can agree to change how their service is delivered, then the SLA can be changed and the OLA will be altered accordingly.
Effective SLM has three continuous aims:
- Reducing service disruptions
- Improving the quality of service especially responsiveness, resolution time, availability and reliability
- Understanding the true cost of doing business
|
8.1.2 - Relationship with Other Processes
When SLM is working efficiently (and in a fully integrated way with other processes such as Incident, Problem, Configuration and Change Management) end-user and customer satisfaction ratings increase significantly. Workflow disruptions decrease as a result for change process, recurring incidents decrease through Problem Management and IT customers have a clear understanding of how the Support Center will meet their needs through Service Level Agreements.
Relationship with the Support Center
The Support Center is the initial point of contact for users. Through Incident Management it aims to provide recovery to the agreed upon service levels for responsiveness and resolution or route work to the most appropriate internal support group as soon as possible in the event of an error.
Relationship with Availability Management
Availability Management is responsible for realizing and optimizing the accessibility of the services. SLM provides Availability Management with input about the required availability and accessibility of the IT services, whereas Availability Management provides information about the actual availability of the services being provided to Service Level Management.
Relationship with Capacity Management
Capacity Management supports SLM by providing information about the impact of a new service or extension of an existing service on the overall capacity. SLM provides information to Capacity Management about the expected current and future use of those services.
Relationship with Incident Management and Problem Management
Incident Management and Problem Management are good indicators of the effectiveness in implementing the OLA/SLA agreements.
Resolving incidents and problems is essential to providing a high quality service. SLM uses information from SLM compliance reports provided by these processes when reporting to the customer.
Relationship with Change Management
The SLA can define the changes that can be requested by the customer organization, and the agreements for responding to these changes (whom to address the changes to, cycle time, costs, informing the organization etc.). A change may also affect the service levels that have been agreed. Any changes to a service and the associated SLA are controlled by Change Management.
Relationship with Release Management
Release Management monitors the agreements made by SLM regarding the provision of hardware and software and general production releases. SLM reports on the quality of the IT service on the basis of information from Release Management reports.
Relationship with IT Service Continuity Management
IT Service Continuity Management is concerned with the rapid recovery of IT services in the event of a disruption to service, and monitors the appropriate measures and procedures. Agreements about the nature of service continuity with the customer are made in the SLM process. The measures and costs are then included in the SLA. It may be agreed that in the event of a disaster, certain service levels no longer apply or are temporarily reduced/suspended.
Relationship with Security Management
The security ensures associated with the IT service can also be essential to effective Service Level Management. Both the IT organization and the customer will have certain security requirements. The corresponding responsibilities and agreements are defined in the SLA. Security Management ensures that the agreed security measures are implemented, monitored, and reported to Service Level Management.
Relationship with Configuration Management
Configuration Management is responsible for entering details of the components (Configuration Items - CIs) and documentation (OLA/SLA) related to a service in the Configuration Management Database (CMDB), and providing information from this database. Hence, the creation or modification of a service or OLA/SLA will affect the CMDB. The Support Center uses the CMDB to determine the impact of an error on the services, and to check the agreements about the response and solution times. The CMDB is also used to report about the quality of the CIs, so as to enable SLM to report about the quality of the service provided.
Relationship with Financial Management
Cost incurred by IT is the provision of services (as defined in the SLA) that may be charged to customers as stipulated in the SLA. These may be one-time charges, or charges for special or additional services. Financial Management provides SLM with information about the costs associated with providing a service. It also provides information about charging methods and the rate to be charged to cover the costs of a service.
8.1.3 Key inputs and outputs to the process
Inputs
- Incident - When an incident is submitted to Level 1, or when it is operationally escalated to a Level 2 or Tier 3 support group
- System Faults / System Monitoring - With the use of system monitoring tools to help conduct on-going system health check and in the event a check should fail - auto open a ticket in the incident management system.
- Provision Request - IMAC Adds, moves, changes
- SLA - Service Level Agreements with customers
- OLA - Operating Level Agreements with internal Service Partners
- UC - Underpinning Contracts - Underpinning Contracts with third party service providers
- Service Catalog - Products and Services Provided
Outputs
- SLM Compliance Reporting - This is the assembly of all SLM inputs into meaningful real-time, static and decision support management reports. These reports validate the success or failure of the SLM process.
- Customer Satisfaction Survey - Management & Feedback Reports
- Incident Response (Acknowledgement) Time - When an incident is submitted to Level 1, or when it is operationally escalated to a Level 2 or
Tier 3 support group, this is the time from the incident submission to contacting the customer in
response to an incident, is the acknowledgement time.
- Incident Resolution Time - Resolution time is the lapsed time from initial submission of the incident by the customer to Level 1, to the final resolution of the problem or request.
The provider will resolve problems within a predefined time frame based on the priority level (P1, P2, P3, P4) of reporting.
-
Samples
SLA
Expiration
Service Hours
Target
Response Times
Exceptions
- Network Based Metrics - What percentage of the time will services be available?
The number of users that can be served simultaneously.
Specific performance benchmark to which actual performance will be periodically compared. The schedule for notification in advance of network changes that may affect users. Help desk response time for various classes of problems. Dial-in access availability.
Usage statistics that will be provided.
- System/Service Performance - Performance metrics are generally characterized in terms of response time and throughput. Service/System Response time. This metric defines the maximum time for a service to respond to user requests. Response time
- Throughput - This metric defines the rate at which data is delivered to the customer.
- Utilization - This metric defines the maximum usage of a service during which the service will perform within guaranteed response times and throughput. For example, this metric could specify the maximum number of simultaneous users: The system will support 100 simultaneous users during the peak hours, where peak hours are between
8 a.m. and 3 p.m.
- Reliability - Reliability metrics consist of availability guarantees over a period of time.
For example: Unscheduled network downtime will not exceed one hour over the course of a year;
The Web server will be available 90 percent of the time it is accessed over a period of a year. Charge Back If desired - SLM provides a definitive cost per service
- Charge Back - If desired - SLM provieds a definitive cost per service.
Elements of Operational Level Agreements and Service Level Agreements
- Definition of products/services covered
- Definition of responsibilities for products/services
- Time commitments on Service Level Events
- Severity classifications for break/fix and for requests
- Defined, measurable events, tracked through automation, with notification to responsible parties
- SLA compliance tied to performance measurement
Components of Service Level Management
- Responsiveness by severity code
- Resolution by severity code Availability
- Transaction response time
- Measurement/reporting
- Escalation procedures Penalties
- Duration
- Roles and responsibilities
- Performance Security
- Defined Service Support procedures
- Operational Level Agreements
- Service Level Agreements
- Service rates
Guidelines for the components of SLM
- Must be challenging but attainable with clear statement of the end result expected
- Must be cost effective
- Must meet business needs
- Must be supported by negotiated OLAs/SLAs
- Must be measurable/reportable - with those responsible for the performance, involved in the development of the metric
- Must be monitored continuously
- Must be agreed by all parties
Possible positive outcomes from SLM
8.1.4 - Possible problems and issues
- OLAs/SLAs too lengthy and intricate - IT organizations tend to want to use
OLAs/SLAs as a defensive strategy; hence, they tend to include information that is not necessary to a functional OLA/SLA. Specific components that are essential to a good SLA include service descriptions, service standards, SLA duration, roles and responsibilities and evaluation criteria. However, including the right elements is only the first step. When drafting the SLA, it is easy to think of it as a contract rather than what it really is - an agreement. It may be simple to stipulate the terms of the service and to specify the exclusions and other specifics. But if the SLA is difficult to read or contains too much legal jargon, both parties will be hard pressed to follow or understand the terms. If an SLA becomes too long and complex, representatives will be less likely to refer to it - much less follow the terms specified.
Critical elements for OLA/SLA
- Service Descriptions: define the exact service the Service Provider will deliver.
- Service Standards: define when the service will be available; include scheduled outages and response times. Service Rates: setup fees, where applicable. Monthly minimums and service rates.
- Escalations Procedure: who to call when a service fails during normal business hours and after hours.
- Penalties: credits received if the vendor does not provide services as promised.
- Duration: how long the SLA terms apply to you and the vendor.
- Roles and responsibilities
- Customer representative: who represents your organization in negotiations and implementation coordination.
- Service Level Manager: who ensures that your organization receives the level of service it has been promised.
- Service representative: who to call with questions about your account, for answers to service concerns, or unresolved issues.
- Contact information: how to contact representatives for each organization.
- Evaluation criteria: the metrics that your organization will track to ensure it receives the quality or service it has been promised.
|
- Ineffective technology - Tools and technology cannot track and report timed service
events, baseline system or networks performance, or
monitor established service metrics
- IT staff are over committed to other priorities - IT staff are too busy focusing on other efforts to give the
SLM program the time needed to change organizational
culture and buy-in.
- Inadequate staffing - Senior management frequently believes SLM can be done in
the margins of time. In order for SLM to be successful, it
must have dedicated resources appropriate for the size of the
organization, reporting to senior management, providing an
objective view of service delivery throughout IT.
- Not all levels of IT management have bought in to SLM - Not all levels of IT management have bought in to the
SLM program, and therefore are not managing staff
consistently.
- Goals are too aggressive - This happens when there is no baseline period. This can have
negative consequences to staff morale if they at not
meeting the target goals.
- Implementing customer SLAs before establishing internal agreements - If SLAs are executed first without first going through the
OLA process, service levels could be inadvertently promised
to customers that your IT group will never be able to meet.
- Monitoring actual achievements - This is a difficult problem. It must be addressed first as it
affects the next three points. The following are important
considerations in ensuring that targets are achievable before
agreement:
- ensure that targets are achievable before committing to them
- verify the targets before agreement
- base SLAs on achievable targets rather than what the customer wants.
- Insufficient supporting agreements - SLAs may not be supported by adequate OLAs or
underpinning agreements. When a service is defined within
the SLA that is supported by another group, work with
them to create an OLA and roll it into the SLA.
- IT based rather than business aligned - SLAs might be IT based rather than business aligned; or
may be lengthy, inconsistent and, not focused. In addition,
SLM in commercial organizations is usually not a
chargeable service, but an overhead; it can be viewed as a
burden.
- OLAs/SLAs not adequately communicated - Responsibilities of each party are not completely defined,
creating a danger that some processes will become the
responsibility of neither or the blame of both.
![[To top of Page]](../images/up.gif)
8.2 - Implementation
8.2.1 The implementation process
 \
| Service Level Management requires a commitment at the highest levels of management. Service levels, acceptable outage periods, committed thresholds, and corresponding penalties should all be clearly stated in measurable terms. If it cannot be measured, you cannot enforce it, so be sure metrics are easily identified and tracked. At the start of the SLM process, these metrics should be reviewed on a daily basis among the service delivery team and weekly with the customer. When a successful pattern has been established and everyone is happy with the progress of SLM, then it can be reviewed on a monthly basis. Call vendors with questions when they arise, rather than waiting long periods to address them. Respond quickly to service providers' questions, to ensure that they receive the data and information they require to make rapid adjustments and correct failures.
|
|
Without OLAs in place, IT departments are working as individual providers directly with the customer - typically working in `silos'.
|
|
With OLAs in place, IT departments are better equipped to work together as a team with the customer through an SPOC, which ultimately provides. |
Responsibilities and activities
The SLM process must be `owned' in order to be effective and achieve successfully the benefits of implementation. Ideally it is a dedicated function that provides an objective assessment and observation of Service Level Management throughout the organization. It should report directly to the CIO or CTO of an organization. Like any set of key management processes, successful Service Level Management requires a commitment at the highest levels of management in order to reach its' full potential.
Deliverables
- Creates and maintains a catalog of existing services offered by the IT department
- Formulates, agrees and maintains an appropriate SLM structure for the organization, to include
- Operational Level Agreements (OLAs) within the IT provider organization
- Service Level Agreement (SLA) structure (e.g. service based, customer based or multi-level)
- Third Party Supplier/Contract Management relationships to the SLM process
- Accommodates any existing Service Improvement Plans/Programs within the SLM process
- Negotiates, agrees and maintains the Service Level Agreements with the customer
- Negotiates, agrees and maintains the Operational Level Agreements with the IT provider
- Negotiates and agrees with both the customer and IT provider any Service Level Requirements for any proposed new/developing services
- Analyzes and reviews service performance against the SLA and OLA
- Produces regular compliance reports on service performance and achievement to the customer as well as the IT support groups at an appropriate level
Organizes and maintains the regular Service Level review process with both the IT customer and IT provider that covers:
- reviewing outstanding actions from previous reviews
- current performance
- reviewing Service Levels and targets (where necessary)
- reviewing underpinning agreements and OLAs as necessary
- agreeing appropriate actions to maintain/improve service levels
- initiating any actions required to maintain or improve service levels
- conducting annual (as appropriate) reviews of the entire Service Level Management process and negotiates, agrees and controls any amendments necessary
- acting as co-ordination point for any temporary changes to service levels required (e.g. extra support hours required by the customer, reduced levels of service over a period of maintenance required by the IT provider etc.).
Competencies/key skills
The Service Level Manager must have strong relationship management skills, which include:
- a good understanding of the IT providers' services and qualifying factors in order to understand how customer requirements will affect delivery
- understanding of the customer's business and how IT contributes to the delivery of that product or service
- excellent communication and negotiation skills
- patience, tolerance and resilience
- knowledge and experience of contract and/or supplier management roles
- good people management and administrative skills
- good understanding of statistical and analytical principles and processes
- good presentational skills
- reasonable numeric skills
- ability to interact successfully with all levels of the customer and IT provider organizations
- reasonable technical understanding and an ability to translate technical requirements and specifications into easily understood business concepts and vice versa
- innovative in respect of service quality and ways in which it can be improved within the
bounds of the organization's limits (resource, budgetary, legal etc.)
- good listener with the ability to apply the knowledge gained effectively
- even-handed and fair in dealings with other parties.
Key performance indicators (KPIs)
- Number or percentage of services that are covered by SLAs
- Percentage of Underpinning Contracts and OLAs in place for all SLAs
- OLAs/SLAs monitored continuously and regular SLM reports are produced in a timely
manner
- Daily SLM review meetings being conducted on time and action items documented for follow-up
- The currency of SLAs, OLAs and UCs and percentage that are in need of review and update
- SLM compliance of defined service targets and the number and severity of service breaches by severity classification
Effective follow-up of all service breaches
- Evidence that service level achievements are continuously improving
- Evidence that customer satisfaction statistics are improving
- Evidence that IT costs are decreasing for services with stable service level achievements
SLM activities include (but are not limited to):
- forming clear alignment within the IT organization via OLAs understanding where organization currently is understanding what the organization aspires to be dealing with challenges
- capitalizing on opportunities
- aligning with and influencing the thinking of senior management establishing function to support the SLM activities implementing the SLM process
- managing the ongoing SLM process
- conducting periodic reviews with all stakeholders
|
Implementing SLM should follow a cycle of defining, confirming, agreeing, monitoring, reporting and reviewing. Consider the following checklist/processes when getting started.
SLA/OLA negotiations:
- Before entering into negotiations or making commitments to providers, customers should conduct a service assessment. This assessment entails gathering information from as many service recipients as feasible and as many sources of service data as possible, so as to answer such questions as:
- what services are you currently receiving?
- what aspects of these services are confusing or unclear?
- what services are you not currently receiving that would be beneficial? in what ways has service delivery been measured? in what ways has it fallen short?
- what aspects of the service need improvement?
- what changes in service delivery would be desirable? Confirm that you are comparing like-to-like.
Insist on quantifiable and verifiable performance metrics. Determine how downtime credit will be calculated and paid.
The information gleaned from this assessment helps customers enter the SLA effort knowledgeably and better prepared.
|
Service Catalog
- Service Portfolio - A Service Portfolio should be a marketing document outlining at the highest level the services on offer of services. It does not need to focus on the detail of metrics and costs.
- Service Catalog - A Service Catalog should be a more detailed breakdown of the services provided and often will include the infrastructure, the software and even the people that deliver the service. A Service Catalog could be defined as a list of services, applications, process, and hardware and support groups / people That will support the services provided.
Once the Service Catalog is defined, the pilot area should be interviewed, workshops/meetings conduct d, and other discovery exercises (such as incident and change request reports) to learn which services are being consumed. Record only relevant information related to each service. I hi, record of services should help provide a baseline to build on.
Information that will be valuable may include:
- priority of tasks
- systems used
- Hardware Inventory (servers, desktops etc.)
- effect on employees
- number of users
- service components used in the delivery of the service
- any third-parry supplier or support contracts.
The information recorded in the service catalog can then be used as a reference in the implementation of the other processes for Service Level Management. This record is essential to the other processes because it documents the services that will be managed by the providers of the Service Level Agreement.
Implementing key process activities
- Establish a customer service culture
- Gain executive support Obtain adequate staffing
- Build appropriate mission and vision statements vision
- purpose
- objectives
- Clearly define Service Catalogs Identify key stakeholders
- Develop OLAs with internal support groups and UCs Develop workflows and processes Implement enabling technologies Define reporting requirements Define SLA/OLA/UC review/update process Establish an internal baseline period for all OLAs
- Develop Service Level Agreements (SLAs) with customer organizations
|
What should the SLA cover?
- Introduction and purpose
- Service to be delivered
- Performance, tracking and reporting
- Problem management
- Fees and expenses
- Customer duties and responsibilities
|
8.2.2 - Planning for implementation
Steps to take
- Form clear alignment within the IT organization via OLAs.
- Understand where the organization is currently and understand where it aspires to be.
- Align with and influence the thinking of senior management.
- Establish a function to support the SLM activities.
- Implement the SLM process.
- Manage the ongoing SLM process.
- Support groups draft an OLA.
- Review, modify and finalize the OLA.
- Ensure workflow, processes, reporting and technology are all in place.
- Conduct a baseline of internal IT performance to develop an understanding of current run rate of service levels.
- Consult with the customer to understand and address all aspects of service delivery
- Review, modify and finalize the SLA.
- Conduct periodic reviews with all stakeholders.
Groups to contact
- Service Partner Organizations - OLAs: (to name a few)
- Support Center
- Network Management
- Systems Development
- Desktop Support
- Computer Operations
- Vendor Support
- Finance or Purchasing
- Customer - SLAs
Necessary resources and relationships
Successful SLM requires that the organization is properly structured to support it. Workflows and procedures must be clearly defined and documented that identify how the entire organization will work together. There must also be SLM compliance reporting and technology in place before rollout.
OLA/SLA elements
- Overview
- Scope
- Involved parties
- Environment
- Key contacts
- Terms and conditions
- Agreement period
- Review
- Hours of coverage
- Service goals,; based on severity '
- Response an I resolution times
- Escalation frequency
- Supported services and charges
- Services provided
- Hardware and software supported
- Charges
Cost elements for implementation
- staff costs (salaries, training, recruitment costs, consultancy - if needed), both initial and ongoing
- development time to assemble Service Catalog
- development time to assemble workflows, business rules and processes
- support tools (monitoring and reporting, plus some element of integrated Service Level Management tools)
- hardware on which to run these tools
- marketing costs (e.g. communications strategies and production of Service Catalog)
These costs should be seen as an investment and added value rather than a cost.
8.2.3 - Hints and tips
What to implement first
Operational Level Agreements (OLAs) and Underpinning Contracts (UCs) should be developed, in parallel with customer SLA discussions. This gives IT and SLM Management a clear understanding of the IT department's capabilities while negotiating SLAs with customers.
During this process, the SLM team should clearly define the levels of service that can be achieved by the various IT support groups and third party vendors. They should also know which teams support or enable each service definition, and their capabilities for delivering those services.
Elements of Operational Level Agreements
- Definition of products/services covered
- Definition of responsibilities for products/services
- Time commitments on incidents by severity for responsiveness and resolution
- Severity classifications for break/fix and non-development work requests
- Defined, measurable events, tracked through automation, with notification to responsible parties
- OLA compliance linked to performance measurement
Things that always work
- Obtain senior management buy-in; this guarantees success for your SLM initiative.
- Review the SLM process and demonstrate how the SLM measurements are monitored and reported from beginning to end. Then show how the process is aligned with the business goals and the value IT is providing to the company.
Little things that deliver big returns
- Definition of the product and services to be provided (Service Catalog)
- Establishing quality standards to be achieved and clearly communicate them to all service partners
- Establishing measurement criteria and performance standards. These metrics should cover everything from availability (when the service is to be operational), reliability (Service Uptime) and responsiveness and resolution times.
- Establishing effective reporting criteria. As part of the effort to ensure quantifiable, verifiable performance metrics are tracked, the SLA should also state the reports (and their frequency) that the service provider will provide, the specific elements the reports will include and track, and when those reports will be provided to the customer.
- Negotiating and determining the cost of delivery per service
- Communicate, communicate, communicate!
- Candidly discuss the questions and myths about service level management (see below )
Questions and myths about Service Level Management
|
Question/Myths | Response/Reality
|
| OLAs have no value | An OLA is the contract that seals a service partnership within the IT
department. It unifies the organization to provide a coordinated service
delivery model.
|
| SLAs have no value | An SLA is the contract that seals a customer's partnership with IT. It is the
document that records the obligations of all parties involved to set realistic
expectations for service.
|
| SLAs merely outline services provided | While services provided are an important aspect of an SLA, the comprehensive
contract also includes performance levels and legal aspects. Information that
should be contained in an SLA includes the purpose of the SLA, description of
service, duration of service, installation timetable, payment terms, termination
conditions, and legal issues such as warranties, indemnities, and limitation of
liability,
|
| Business goals should not be included in an SLA | Writing the customer's business goals into an SLA provides the vendor with a
greater understanding of the customer's priorities, which can prove invaluable
in a time of technical crisis.
|
| The services determine pricing | The single greatest factor in price determination, as specified in an SLA, is
performance level. Customers pay the vendor according to predetermined
performance criteria such as availability and response time. An SLA should also
include specifications regarding financial penalties, in the event that the vendor
is unable to meet the performance levels indicated in the SLA.
|
| The vendor's standard SLA cannot be customized | Many vendors provide a standard SLA, and some even market their services
based on the strength of their SLA. But almost all vendors will customize their
services and their SLAs to satisfy customers' requirements.
|
| The vendor will monitor performance | Vendors generally do not monitor their own performance, although an
increasing number of software vendors are producing tools that monitor service
provider performance on behalf of their clients.
|
| An SLA only applies to the vendor that sign it | While this reasoning appears logical, service providers often participate in an
entire network of service providers. This network can include IT functions that
they outsource, as well as extended partnerships, which allow other
organizations to cover their service responsibilities. To minimize third-party
performance risks, customers should insert a clause stipulating that the primary
vendor remains accountable for any damages caused by third-party partnerships.
|
| If it's in the SLA, it's guaranteed | In the excitement of the sale, vendors sometime promise services that they
cannot provide. For this reason, customers should be wary of exacting demands
that the vendor is hesitant to meet. Customers should also remember that an
SLA is only a contract that represents a partnership; they must continue to
manage the vendor for the duration of the relationship.
|
| Remediation of a failed SLA - or partnership - is impossible | Many consulting firms offer mediation services that help customers and service
providers to renegotiate the SLA and the partnership. In fact, as outsourcing
becomes more popular, consulting firms are doing more and more mediation
work. And, if all else fails, there is always legal recourse.
|
| What is the most common mistake you have seen in establishing SLAs? | A common mistake is for people to create a statement of services and
mistakenly think they have created a service level agreement. While these
service statements are useful, they are not SLAs. In particular, they lack
information concerning the terms and conditions of service delivery, and often
fail to describe how the SLA will be managed; that is, how compliance with the
agreement will be tracked, reported, and reviewed, and how changes to the
SLA will be handled.
|
| I've heard people say that an SLM should include a glossary? Is that really necessary? | One of the biggest sources of misunderstanding between providers and
customers is that they define key terminology differently, which leads to
conflicts in service delivery. It is not at all unusual for the two parties to have
different things in mind when they use such terms as availability, reliability,
acknowledgment, response, uptime, access, and problem resolution-to name a
few. Even members of the same team often interpret these terms differently.
Because of the high potential for misinterpretation, the process of developing a
glossary is an immensely valuable effort
|
| What should customers keep in mind in preparing to negotiate an SLA? | Before entering into negotiations or making commitments o providers,
customers should conduct a service assessment. This assessment entails
gathering information from as many service recipients as feasible and as many
sources of service data as possible, so as to answer such questions as:
- what services are you currently receiving?
- what aspects of these services are confusing or unclear?
- what services are you not currently receiving that would be beneficial?
- in what ways has service delivery been on target?
- in what ways has it fallen short?
- what aspects of the service need improvement?
- what changes in service delivery would be desirable?
- The information gleaned from this assessment helps customers enter the SLA effort knowledgeably and better prepared.
|
| How often is it necessary to hold service review meetings? | Important problems, issues and concerns invariably surface during periodic
service reviews, even when service delivery has been on target during the review
period. Regular service reviews, with both provider and customer
representatives participating, are essential to SLM success. The intention to
conduct these reviews should be documented in the OLA/SLA.
A formal review meeting should be held at least weekly, when the SLA is new,
when service delivery has been below acceptable levels, or when the service
environment is complex or undergoing significant change.
When service has been stable and at acceptable levels, monthly reviews may be
sufficient; then move to quarterly review meetings.
|
| What can I do if my
management doesn't want to
create SLAs?
|
Start by trying to determine management's reasoning. An understanding of their
perspective will help you build a case that is targeted to their specific concerns.
In doing so, watch for problems that might not have occurred if SLAs had been
in operation, such as customer confusion about service availability or conflicts
between providers and customers about service quality. Point out to
management the cost of lost productivity while dealing with these situations.
Many of the steps involved in creating an SLA can be carried out without a
formal SLA effort. For example, one of the biggest tasks in establishing an SLA
is creating a service description or service catalog to clarify service offerings.
Another task is defining and communicating service standards that document
the time frames and conditions of service delivery. A third task is gathering
customer feedback to service as a baseline for assessing service effectiveness. If
management supports these and the other individual steps involved in
implementing an SLA, you may be able to achieve the benefits of an SLA
without ever formally defining it as an SLA.
|
| What kinds of circumstances
warrant making changes to an
OLA/SLA?
| Although everything in an OLA/SLA is eligible for change, changes should not
be made lightly. Typically, it is best to limit changes to significant
circumstances such that those arising from changing business or service needs,
significant variations from agreed-upon service standards and unanticipated
events. Whatever conditions are determined to warrant making adjustments to
the OLA/SLA should be articulated in both the OLA/SLA.
|
8.3 - Optimization
8.3.1 - The optimization process
Support Center Manager's role, responsibilities and activities
The Support Center/Helpdesk Managers have the most important role in motivating staff. Managers' attitudes and actions set the tone for the entire staff. They should not think of themselves as managers; instead, they should consider themselves as team leaders. The Manager sets the tone and leads by example on a daily basis; he/she needs to spend time in front of and with the team. It is the Manager's job to establish the expectations and demonstrate the enthusiasm needed to meet and exceed them. They must do this every day to establish the culture.
If your organization is going through changes, such as implementing new Problem Management processes and implementing new tools, the Manager's participation is even more important. Your staff needs your support through times of change. They need to understand your vision and see your confidence and enthusiasm. This is your opportunity to turn vision into culture.
Measurement, costing and management reporting
Organizations are finding it difficult to collect, store and collate the metrics required to measure their OLA/SLA performance. In most cases this process requires extensive manual data collection and manipulation. It is often difficult or impossible for organizations to judge their SLA performance on an ongoing basis, due to the time consuming process of collecting and storing metric data. The situation is further complicated by the complex calculations required in generating these reports.
The next challenge lies in evaluating and meeting SLA performance. In the absence of automated tools, organizations are forced to rely on difficult, time-consuming, and error prone manual processes to collect store and analyze the data required to measure OLA/SLA performance.
One metric that is almost universal is availability. It is important to remember that availability must reflect the complete service covered by the SLA and not individual components. Availability may be expressed in terms of percentage availability, minutes of downtime, number of outages, mean time between failures (MTBF), etc.
Another important area for SLA metrics is performance. However, there is a difference between what is being used (reported) and what should be used. An example is the average responsiveness and resolution time of an incident, broken down from the time the customer places the initial call until the ticket is closed. A key requirement is that the metrics must be meaningful to the customer or support group receiving the compliance reports. Another requirement is that the metrics reflect the customer experience. Both of these requirements are frequently violated.
Metrics are the key to success. Establish measurable goals and objectives for the organization. Break high-level organizational goals and objectives into smaller team-level goals and objectives. Your organization achieves its goals based on the contribution of your teams, so define what teams are to accomplish. Most importantly, make sure the goals/objectives are measurable.
You may be faced with some difficult decisions on setting targets. You are implementing new processes, so you may not have historical data to base your targets on. At this point, you should have defined what it means to be successful. Many organizations do this based on what their peers are doing. For example, suppose your peer Support Centers resolve 85 percent of their incidents during the initial contact. Set that as a target. Start measuring immediately, and after one or two quarters, review your goals and make realistic adjustments to the targets. You can still use first-level resolution as a metric to foster competition between first-level teams. Gather the data and publish it. You may need to adjust your processes if you find that, after measuring for the first two quarters, you are far from the goal. Meet with your team and share this information with them, both in the beginning and during the reviews. Make sure the team knows that the first set of targets is a starting point and that once metrics are gathered, better targets will be established. This is critical in the beginning.
|
Measure | Example
|
| Responsiveness /acknowledgment time | to an incident is the acknowledgement time.
telephone/voicemail/email, or arrive at the desk side in response
time from the incident submission to contacting the customer by
operationally escalated to a Level 2 or Level 3 support group, the
When an incident is submitted to Level for when it is
|
| Resolution time | compliance.
Incident Management record promptly, the incident will be out of
accurately. If technicians resolve issues but do not update the
updated promptly in order to report on resolution time
You must ensure that the Incident Management records are
Support Center to the final resolution of the incident or request.
The time from submission of the incident by the customer to the
|
| Availability | based on this.
Days and hours the service is available or a percentage figure
|
| Responsiveness and performance | and technical and human speed of response.
time to acquire data, speed of data transfer and response time,
Speed and volume (throughput or workload measures) of service,
|
| Integrity and accuracy | The data in the service is doing what it is meant to do
|
| Security | The security of the service.
|
| Customer satisfaction | A formalized measurement of customers' perceptions of service
|
It is very common for IT departments to create OLA/SLA reports that only contain technical data. Examples of these metrics include: packet loss, latency, jitter, paging swapping, allocation failures, etc. Most end users will not understand this type of data or be able to relate it to their overall experience. The most commonly used metrics are not necessarily the best metrics to use; the choice of metrics depends upon the nature of the service and the technical sophistication of the user.
8.3.2 Tools
Organizations must define their objectives for service management first, then evaluate technology solutions to properly align current technology. Having the right information to monitor service level compliance is the biggest step toward successful Service Level Management. However, without the right support tools to help in the management task, Service Level Management can prove to be a daunting activity.
When reviewing SLM tools, it is important for the IT department to be able to align with the business units it supports. The tool must be able to provide the framework for establishing and monitoring service requirements and automating the tracking and reporting of critical metrics.
Most infrastructure management tools initially were developed to allow for generating alerts to managers letting them know a service was out of tolerance. Technology is also available for the logging and access of key management metrics for both reporting and troubleshooting purposes across multiple platforms, with more platforms on the way.
With proper planning and attention paid to establishing key service levels and the service objectives put in place to support them, Service Level Management can be achieved with today's tool offerings and the benefits of Service Level Management can be achieved that much sooner. Surprisingly enough, if the early phases of Service Level Management implementation are treated with rigor and properly applied, the implementation of the actual monitoring and reporting on established services levels becomes fairly easy.
Other important features include the provision of diagnostic tools, automated alerts, and automated recovery tools. The impact of changes upon the quality of service and how it affects the OLAs/SLAs also need to be considered. It is essential that incident and problem handling targets included in OLAs/SLAs are the same as those included in Support Center tool(s) and used for escalation and monitoring purposes. Organizations that have failed to do this end up monitoring something different from that which has been agreed in OLA/SLAs and as a result are unable to know whether OLA/SLA targets have been met not to mention the wasted effort. SLM cannot work in isolation; it relies heavily on the existence and effectiveness of all the other processes. Best practice states that nothing should be included in an SLA unless it can be effectively monitored and measured at commonly agreed points in time.
Measuring and reporting IT results
According to ITIL, Service Level Management aims at controlling the service delivered by the IT department to the business users. Although multiple factors relating to the IT service are relevant for improving the contribution to the business, two of them are the best known: performance and availability of the business applications. Whenever IT fails to deliver adequate performance and availability of key applications, business processes are halted immediately, affecting financial results and customer satisfaction negatively.
- A business customer only wants to know what the IT department delivers as a whole, not how the technical components and elements are performing.
- Provide fact based information on the delivered service by the IT department, providers and subcontractors
- Compare actual service delivered with the agreed service levels (OLA/SLA)
- Improve the relationship between the business management, IT management and IT providers/departments by separating facts from subjective opinions
- Set future service targets and responsibilities
- Reduce operating costs by avoiding unnecessary IT investments due to sub-optimization
Common Metrics
- Incident response (acknowledgement) time - When an incident is submitted to Level lot when it is
operationally escalated to a Level 2 or Level 3 support group, the
time from the incident submission to contacting the customer by
telephone/voicemail/email, or arriving at the desk side in
response to an incident is the acknowledgement time.
- Incident resolution time - The time from submission of the incident by the customer to the
Support Center, to the final resolution of the incident or request.
- Network based metrics - The percentage of the time that services will be available
- The number of users that can be served simultaneously
- Specific performance benchmark to which actual performance will be periodically compared
- The schedule for notification in advance of network changes that may affect users
- Help desk response time for various classes of problems
- Dial-in access availability
- Usage statistics that will be provided
- Performance - Performance metrics are generally characterized in terms of
response time and throughput.
- Service/system response time - This metric defines the maximum time for a service to respond
to user requests.
- Throughput - This metric defines the rate at which data is delivered to the
customer.
- Customer support - These include typical help desk problem reporting and problem
resolution guarantees. For example: the provider will deliver 24x7
supports; the provider will assign a single point of contact to the
customer; the provider will resolve problems within a predefined
time frame based on the priority level (P I, P2, P3, P4) of
reporting.
- Utilization - This metric defines the maximum usage of a service during
which the service will perform within guaranteed response times
and throughput. For example, this metric could specify the
maximum number of simultaneous users: The system will
support 100 simultaneous users during peak hours, where peak
hours are between
8 a.m. and 3 p.m.
- Reliability - Reliability metrics consist of availability guarantees over a period of
time. For example: unscheduled network downtime will not exceed
one hour over the course of a year; the Web server will be available
90 percent of the time it is accessed over a period of a year.
- Business continuity and disaster recovery - This guarantees that steps have been taken to include
specification of a recovery plan in the event of a disaster, such as
facilities redundancy, distributed backups and storage plans. In
addition to reliability and support metrics, service performance
metrics are important for business-critical applications.
Sample Service Level Agreement Metrics
| |
S1 | S2 | S3 | S4
|
| Acknowledge Problem | 15 Min | 30 Min | 60 Min | 60 Min
|
| Tech on-site | 15 Min | 2 Hrs | 6 Hrs | 48 Hrs
|
| Resolution Time | 2 Hrs | 4 Hrs | 8 Hrs | 72 Hrs
|
| Target Goal | 90% | 90% | 90% | 90%
|
| Q 1 Target | 70% | 70% | 70% | 80%
|
| Q2 Target | 75% | 75% | 75% | 85%
|
| Q3 Target | 80% | 80% | 80% | 90%
|
| Q4 Target | 90% | 90% | 90% | 90%
|
| Answer Rate | 90% of all calls answered within 60 seconds
|
| Abandoned Rate | less than 10% abandoned calls
|
| Customer Satisfaction | 90% satisfied or better from customer satisfaction
surveys (ie on a scale of 1-5)
|
Install/Move/Add/Change (IMAC) Service Targets
| Standard Desktop - Forecasted | 85% Within 10 Business Days
|
| Standard Desktop - Non-Forecasted | 85% Within 15 Business Days
|
| Standard Laptop - Forecasted | 85% Within 15 Business Days
|
| Standard Laptop - Non-Forecasted | 85% Within 20 Business Days
|
| De-Install | Logins within 24 hours
|
| Data Restores | 90% Within 48 hours
|
8.4 - Summary
SLM should focus on the customer's underlying interest in SLAs: they are trying to quantify a minimum performance threshold for the offering. By addressing the SLA question holistically in terms of both technical and business general SLAs, the IT department can provide an improved context for service delivery. Successful Service Level Management requires a commitment at the highest levels of management.
The evaluation process is very important. Without evaluation criteria; there is no objective
of determining how well your service provider is performing. The Customer
initative should select metrics with assistance of the Service Level Manager. Metrics
should be meaningful and geared toward IT service delivery. Percentage of infrastructure
availability; minutes lapsed until performance issues are corrected, average peak bandwidth and connectivity availability, average peak bandwidth capacity, and acceptable outage windows for maintenance should be specified. Ensure that your IT department has the tools in place to track the metrics requested before agreeing to the metrics.
Service Level Management has proven its worth in IT environments and data centers around the world. It has an even greater potential for key benefits for the distributed enterprise by strategically focusing on business users as the IT driver. Service Level Management can be used to help control rapidly increasing costs created by uncoordinated acquisitions of IT materials to support the distributed enterprise by focusing on providing required levels of service, rather than building infrastructure.
Bibliography
- Implementing Service Level Management -Practical Guidelines for the IT Support Organization white paper, Char LaBounty, HDI website, October 2003
- Service Level Management: An Overview white paper, Char LaBounty, HDI website, September 2001
- Efficiency Tool Kit, Network World, Tom Duffy, November 5, 2001.
- IT Best Practices, Network World Management Strategies Newsletter. Melissa Shaw, November 11, 2001
- Practice Questions, Computerworld, Frank Hayes, October 7, 2002 Service Support. Norwich: The Stationery Office, 2000 Service Delivery. Norwich: The Stationery Office, 2001
- Service Level Management at Zurich Life, USTechnology Asset Manager, Ecpweb.com, Mark Bradley February 2004. Web
- State of the Support Industry: Visioning Your Support Organization Help Desk Institute, April, 2003.
- Understanding and Improving: The Business Perspective On Your IT Infrastructure. Norwich: The Stationery Office, 1996
