SLM Table of Contents
Service Level Management in the form of Service Level Agreements, Service Catalogues, Schedules of Intent, Contracts or even licences are more important than the actual documents suggest. Service Level Management is a core module, and is probably the first point of reference when implementing ITIL within an organization. Unless regularly monitored and reviewed, under performance or undisciplined expansion can choke the effectiveness of Management and jeopardize the whole organization. This process needs to be re-written for confomance with ITIL Version 3. This involves removal of Service Catalog, Service Reporting and Service Improvement functions/sub-processes to other Version 3 processes.. More...

Introduction to Service Level Management

Service Level Management is a process under Service Design in the ITIL Version 3 concept.

In an ideal setting, the levels and kinds of IT service provided are perfectly aligned with business requirements. Few organizations, however, have the organizational capabilities to perfectly align all aspect of the organization's operations - IT included - with strategic goals and intents^N. As such the organization should carefully construct and institutionalize structures and processes to facilitate alignment.

This exercise will never be undertaken in the absence of existing governance and communication structures. Consequently, most organizations will start by understanding their AS-IS situation with regards to service offerings. Developing the Service Catalogue is an important first step in promoting widespread understanding of service offerings.

The TO-BE model is then determined in negotiation with business leaders, and, the SLA is then developed on the basis of these requirements and priorities. Service variations and nuances are determined and performance measured established and agreed upon. Services are monitored and measured according to the agreed-on SLA criteria in order to ensure compliance with it. Service level monitoring entails continual measurement of mutually agreed–upon service-level thresholds and the initiation of corrective actions if the thresholds are breached.

Service Level Management allows the IT department to meet business expectations and opens a dialog to confirm these expectations.

Service Level Management

Objectives

Many organizations have embraced ITIL as a framework for improving IT Service Management processes. These organizations traditionally start by listing a number of 'gaps' between current and ITIL best practices and recommend improvements to close these gaps.

Key to closing those gaps are the following kinds of measures:

• gaining some "quick wins" (ie., return on investment) through using ITIL practices. In most ITIL implementation-scenarios quick wins are obtained through the introduction of processes requiring modest levels of organizational maturity (as defined in CMMI - see Glossary),
• the employment of standard, defined and managed processes to reduce service variations in the delivery of IT services,
• on performance reporting as a key enabler of continuous service improvement,
• on customer communications to further their opinion of services delivered,
• on marketing of IT Service Provider services as a vehicle for leveraging the original ITIL investment, gaining recognition for IT Service Provider and further disseminating the benefits throughout the organization.

While each of the above ITIL processes will permit the achievement of modest benefits, greater rewards can be sought by integrating the separate processes into an overall service management concept with service level management (SLM) as the integrating concept. SLM highlights the point that the level at which services are provided is geared to the business' need for them. SLM puts the relationship between providers and consumer of IT services on a more professional basis - describing service offering, their costs and continuing performance in negotiated agreements which are continually monitored for compliance. Accurately defining the relationship between IT Service Provider and its' line of business (LOB) partners allows the LOB IT Provider to better describe their IT service provisioning to their customers - the ultimate payer of products and services.

Critical Success Factors

• The reliance of critical business processes on IT is defined and is covered by SLAs,
• There are governance structures and a service culture within the organization which can be exploited to implement SLM concepts and approaches,
• IT provider demonstrates its' commitment through Service Catalogue and OLOs statements,
• OLOs and SLOs are expressed in end-user business terms,
• Measures meet the metrics test outlined in Measurement,
• Root cause analysis is performed when service levels breaches occur,
• Skills and tools are available to provide useful and timely service level information,
• There is a demonstrable relationship between service provisioning and the costs of providing services,
• A system for tracking and following individual changes to services is available.

Process Coverage

Scope

In Scope

• Services are described in a service catalogue. One service may form part of another service. The description of each service is the responsibility of the Service Owner. The description is maintained as a Configuration Item (CI) and managed through Change Control procedures. Service Provisioning is described at offered levels, with a service chain describing participants and their obligations in the provision of the overall service. The costs and charge-back methods are described for the general offering and for all service variations.
• For direct customers Service Levels are negotiated and described as Service Level Requirements (SLRs). The identification of Service Level Requirements (SLRs) is based on the existing and anticipated technology needs of supported corporate lines of business. The results of the negotiation of these services are recorded in Service Level Agreements (SLAs).
• For supported lines of business (LOB), an Operational Level Agreement (OLA) describes the provision of all IT services. The description of service chains associated with services described in the Service Catalogue identifies where OLAs are required in order that participants in that service chain understand their obligations towards meeting the overall performance goals for the service.
• External Service providers will have their expectations and obligations detailed in Underpinning Contracts (UCs). OLAs and UCs have Service Owners responsible for their integrity and updating and are maintained as Configuration Items (CIs) under Change Control.

• Ongoing negotiation and liaison with customers on service matters through Account representatives.
• Monitoring and reporting of performance against the service and operational level objectives (SLO, OLO)s on a real-time and periodic basis by the account representative.
• The coordination of agent deployment throughout the infrastructure to provide performance data on CIs within the IT provider's sphere of responsibility.

Usually Excluded

• SLAs negotiated by the LOB IT service provider are within their respective domains though the OLA negotiation with the IT service provider will provide important performance descriptions which should be reflected in these documents.
• Day-to-day service provision is provided by operational units.
• Service planning is traditionally covered by other bodies. Account representatives should remain aware of these endeavors in order to keep their portfolio LOBs informed on happening and ensure that LOB interests are represented in the planning deliberations.
• Customer Relationship Management (CRM) as a disciplined, quantitatively measured process of maintaining relevant information on customer habits is the domain of the primary LOB. The application of CRM concepts to the maintenance of relationships between the iT service provider and its' Customers is considered beyond the scope of this Service Level Management implementation

Relationship to Other Processes

Configuration Management

Change Management

Service Request

Availability and Service Continuity Management

In efforts for an organization to determine the requirements that it may need to address in a service continuity effort, it must first understand the business impact if a process, person, or technology fails, what will happen. This examination is called a business impact analysis. From this analysis, closer attention is then applied to identify impact points, and a business impact assessment is done. This assessment identifies the actual risks that a specific process may face. The results of both these reports are then utilized to mitigate the risk with sound strategies.

A key driver in determining the requirements is how much the company stands to lose as a result of a disaster or other incident and the speed of escalation of these losses. The purpose of a business impact analysis is to assess this through identifying:

• Critical business processes
• The potential damage or loss that may be caused to the organization as a result of a disruption to critical business processes
• The form that the damage or loss may take including lost income, additional costs, damage to reputation, loss of goodwill, and loss of competitive advantage
• How the degree of damage or loss is likely to escalate after an incident
• The staffing, skills, facilities, and services necessary to enable critical and essential business processes to continue operating at a minimum acceptable level
• The time within which minimum levels of staffing, facilities, and services should be recovered to normal levels
• The time within which all required business processes and supporting staff, facilities, and services should be fully recovered.

The last three items provide drivers for the level of mechanisms that need to be considered or deployed. Once presented with these options, the organization may decide that lower levels of service or increased delays are more acceptable based upon a cost/benefit analysis. The level needed is recorded and agreed upon within an SLA. These definitions and their components enable the mapping of critical service, application, and infrastructure components, thus helping to identify the elements that a organization needs to provide. The requirements are ranked and the associated elements confirmed and priorized in terms of risk assessment/reduction and recovery planning. Impacts are measured against particular scenarios for each customer such as an inability to receive raw material or deliver products or services.

• Impacts are measured against the scenarios and typically fall into one or more of the following categories:
• Failure to achieve agreed service levels with the customer(s)
• Financial loss
• Immediate and long-term loss of market share
• Breach of law, regulations, or standards
• Risk to personal safety
• Political, corporate, or personal embarrassment
• Loss of goodwill, credibility, image, and/or reputation
• Loss of operational capability, for example in a command and control environment

This process enables a company to understand at what point the unavailability of a service would become unacceptable.

Capacity Management

Financial Management

Policies & Guidelines

• the IT provider should publish its service offerings in catalogues describing services, variations, costs, expected performance and the obligations of all participants in the provision of the service.
• The level of current services should be delineated in corporate client SLAs and OLAs between the primary IT service provider and its' current customer base.
• Service variations should be negotiated between the primary IT service provider and lines of business contracting for the variations. The costs associated with standard services, including costing algorithms will be negotiated and detailed in the Service Catalogue. The costs of variations will be detailed in the same Catalogue and tracked closely.
• The performance and behavior expectations of all internal participants involved in providing a service should be negotiated amongst the participants and detailed in Operational Level Agreements between senior leadership and operational units.
• The expectations of all external service providers should be maintained in Underpinning Contracts (UCs) maintained by Service Level Management on behalf of the iT service provider.
• OLAs and UCs should be constructed in a manner which facilitates the collection and reporting of end-to-end service performance. They will be maintained as Configurations Items (CIs) and recorded in the CMDB. Changes to them will be subject to Change Management procedures.
• A Service Level Manager should monitor service delivery against established Service Level Objectives and report against them on a monthly basis. The Service Level Manager should attempt to mitigate the adverse impacts of service breaches.
• There should be methods to escalate issues which are within established threshold (eg., 80%) of constituting a breach of a negotiated service objective as set out in a SLO,
• Software monitoring tools and agents designed to provide metrics on performance should be an explicit consideration for new software introduced into the production environment. Consideration will be given to developing "synthetic transactions" for applications not having management capabilities.
• Regular reviews of the effectiveness of Service Level Management will be conducted.
• Ownership of SLAs with corporate customers should be by account representatives who act as the primary customer point of contact for negotiation and issue management.
• There should be provision to log and classify a service complaints which should be treated as an Incident with a Category="Service Complaint". Service complaints should be automatically escalated to an account representative responsible for the originating source's organization. Complaints will be monitored and reported.
• All agreements (SLA, OLA, UC) and catalogues should be easily available to employees through an intranet site.
• Ongoing performance, as expressed in Service Level Objectives (SLOs) and Operational Level Objectives (OLOs), should be continually monitored and regularly reported.
• Multiple agents that duplicate agent functionality (devised to provide service level management information), should be avoided wherever possible. This can be achieved by careful coordination across management disciplines such as network management, database administration, and systems management. Each management area should be responsible for controlling agent deployment within its' area. Policies and procedures will be developed for deploying and managing distributed agents.

How the Process Scales

Key Concepts

Key elements in this definition are:

• An SLA is the primary document and the contractual agreement which outlines how, where, at what level and to whom IT services are to be provided to further business goals and objectives,
• How well the agreement is being fulfilled is determined through an ongoing processes of performance reporting
• The objective is to improve service provision over time

An Operational Level Agreement (OLA) is an agreement between participants in the provision of that service. It details the characteristics of the service "hand-offs" between participants. While an IT service provider will have direct customers as represented by the corporate service personnel to whom it provides IT services, its' primary customer base is to business lines who provide IT services to a client base (ie. their customers). In this relationship, an SLA would define the provision of services between the business product IT provider and the end user of the product. The primary IT provider supplies specific corporate services to any LOB IT provider. This relationship is defined by an Operational Level Agreement (OLA). The definition of these individual relationships can be defined in a standard OLA with each LOB being a signatory.

The focused emphasis on performance reporting distinguishes SLM from other ITIL processes. It implies "quantitative management" of service provision - a level 4 activity as described by Capability Maturity Model Integration (CMMI). Most ITIL processes are described for implementation somewhere between levels 2 (repeatable) and 3 (defined) processes. Therefore, fully implementing SLM practices requires more mature supporting processes than do other ITIL areas such as incident, change, problem and release. Key to providing SLM to primary service providers are Operational Level Objectives (OLOs). OLOs cite the agreed upon levels of service which IT Service Provider would promise its' LOB customers.

Given the difficulty of adopting level 4 maturity practices without supporting practices at the same level of maturity, a reasonable direction would be to adopt a phased approach to SLM implementation. The strategy should be to internalize a mentality and organizational pre-disposition for developing and reporting upon customer-centric performance metrics (see section on Service Culture) in order to develop momentum to continue the effort - to provide a predictable, acceptable service to the customers of the service by,

• Establishing a basic service catalogue describing the services of the IT provider. The catalogue should describe what services are offered, their costs, how to access them and the obligations of both the provider and the customer. Develop a service chain associated with the delivery of services described in the Catalog
• Leveraging the Service Request (SR) process as the vehicle to market and order services,
• Establishing Operational Level Agreements amongst service delivery partners in service chains,
• Instituting measurement reporting for processes which have direct and easily collectable metrics (excluding difficult and/or expensive availability and capacity metrics),
• Preparing standard OLA and SLA templates,
• Marketing a model of SLM excellence by establishing a locally focused SLA to corporate service organizations

Hence, services are funded at "good enough" levels.

Or consider how how Microsoft defines customers and client when outlining Microsoft Solution Framework.

All too often the rationale for funding at a particular level is not properly communicated to the organization or end users. As a result, the consumers of the service - the end users - will expect service perfection. They do not understand the performance constraints placed on the service provider by business leaders making funding decisions. These leaders often fail to make the connection between funding and performance constraints and the end users develop the perception that the internal provider is delivering low value rather than agreed-upon service according to business requirements. ^R

.

Classes of Service

By always trying to please everyone and minimize complaints, IT organizations are, perhaps, partly to blame for the above misconception. However, as Lutcheon comments - "the days of the IT free ride are over" ^R. Simply put, most IT Providers have learned the lessons resulting from continuing, escalating user demands without compensating funding.

The table below illustrates how different drivers work together to increase the costs associated with service provision.

It is incumbent upon prudent IT leadership to make sure everyone in the company understands the impact of IT decisions on the total IT budget allocation. Typically, this is done by creating "classes" of use/service categories. These classes are usually driven by the complexity or volume of the service or use required and are identified are periodically verified by identifying and re-visiting service level requirements. There are three primary considerations when devising classes of service:

• To avoid undue confusion (thereby negating many of the gains achieved by offering service classes), the number of classes should be limited. Doing this facilitates standardization, cost efficiency and leveraging economies of scale.
• the speed in which the service is offered - how quickly can the service be delivered form conception to completion?
• the continuing availability of the service - how universal is the service to be online, at what performance levels and to which customer groups?

Business units that can live with "standard service levels" at "normal speeds" (eg., a mature business unit with well-developed processes and little change in its business model over time) may choose to pay the least per unit of volume or per head. Other business units, which may require customized or unique types of service and very fast delivery of these services at any time (eg., a fast growing business unit with a highly mobile workforce) may pay may additional amounts per volume or head count. For these latter business units, revenues must fully support their needs or to cover their costs, they must find increased investment funds or obtain a corporate subsidy.

This approach allows business units and corporate departments to share in basic, standard, commodity-type services at the same unit cost, the driver being either the number of users or the volume of use by class of use or service. Business units requiring higher levels of more specialized services and/or faster speed or greater availability can identify the premium services they want from the It organization "by the pound" in increments above the standard services.

Startup and Maintenance

This lifecycle is academic until the process is implemented sufficiently well that it is subject to an initial iteration. The tasks in implementing a sustainable process have often proven insurmountable to organization's which will abandon SLM principles as being too time-consuming with unclear or unachievable benefits.

Service Level Management implementation should, therefore, be subject to Project Control with a Project Charter and detailed Work Breakdown Structure. That WBS should include tasks which:

• Appoint a Process Owner.
• Define a Service Catalogue initiative over several years of increasing comprehensiveness encompassing participant obligations within defined service chains, financial costs, performance objectives, etc. The initial release should an organizational framework for service descriptions and a method of requesting access to a service.
• Define service chains involved in the delivering of services. Once completed, each service relationship should be identified and subject to performance objectives between the IT provider's Senior Leadership Team (acting on behalf of the next actor in the service chain) and organizational divisions responsible for the delivery of activities in that service chain. These are collectively recorded in OLAs, and, where the provider is external to the organization, in Underpinning Contracts (UCs with contain stronger legal strictures).
• Establish an SLA-OLA architecture describing the network of agreements between the IT provider and its' customer base which best reflects:
• the off-loading of material to a comprehensive Service Catalogue which would normally be contained in an SLA/OLA,
• the removal of redundancy in service and objective reporting,
• the unique one-to-one (ie. Provider to a single or discrete number of business lines) service provision,
• Identifies performance metrics with initial concentration on workload and response time metrics which are easily obtainable from existing sources and which supplements this with survey measures of user satisfaction.
• Develops measures of availability and capacity and determine appropriate benchmarks based on similar industry usages,
• Develops strategies to implement monitoring tools to provide availability and capacity measurement on a regular basis with ultimate emphasis on developing end-to-end measurements.

Many organizations will have only a few SLAs. They may are most likely product-focused and outline the delivery of a specific application to a specific Customer base. Given that each application has a unique set of customers this strategy often results in undue duplication amongst SLAs in use. The SLAs are administered by Line of Business technology providers which provide technology service for which the application is the major supported feature. A typical agreement architecture might look like that presented below.

This diagram highlights the following relationships and the agreement which is used to describe obligations and performance expectations. The description has the following organizational assumptions:

• this is a business-centric SLA architecture
• lines of business maintain control over business critical applications which rely upon centralized IT services (eg. network, support desk). If all application support is centralized within an Corporate IT Division, then End User Agreement might be between the Corporate IT Division and the End User.
• lines of business have centralized and/or decentralized business operations which utilize centralized IT services
• some services are outsourced. Outsourced services may be administered by the Corporate IT Division or by a line of business

Organizations should develop an agreement architecture as a preliminary framework for developing SLAs and SLM in general. The various agreements involved in this are:

Agreement	Between	Content
Service Catalogue	Corporate IT service providers describing their service offering	Types of service per cost, performance expectations, obligations of participants, including customer
SLA	service Level Agreements: Corporate IT Provider and Line(s) of Business	one standard SLA itemizing standard services, specialized SLAs describing specific agreements or deviations from standard agreement. References service catalogue and itemizes deviations from standard offerings. contains signatures, length of agreement, how to amend agreements.
OLA	Operation Level Agreements: IT Corporate Services and Corporate Senior Management	Obligations and performance expectations required to meet SLA and Service Catalogue service descriptions.
UC	underpinning Contracts: IT Corporate Services or a line of business and external vendor providing service(s)	Obligations and performance expectations described in exacting legal terminology and containing penalty descriptions for breeches of performance
EUA	End User Agreement: Between users of specific applications and the line of business (might be Corporate IT Services) responsible for delivering the application	Contains disclaimers, tools and offering restrictions, minimum access requirements, security obligations, etc

The ultimate service expression is described by an SLA between the LOB product provider and the Customer of the business' product. A major enabler of this relationship will be defined in the OLA between the primary corporate IT service provider and a LOB IT provider (the primary signatory of the SLA). This OLA will be a composite of all the service commitments inherent in the provision of services by corporate IT provider to the LOB IT provider. These obligations will, in turn, be expressed in OLAs between the corporate departments' offering services and the corporate IT provider's senior leadership acting as the focal point for the expression of commitments.

Services are expressions of benefits bundled in a way to best satisfy Customer wishes. This bundling happens many times and in different ways. A IT service provider department is a representation of this multiple bundling and, the way the organization is setup should render the multiple delivery of these services efficient and effective. This will most often follow technology product lines or workforce specializations. There is seldom an exact match between an organization and the services it delivers.

Each service will have one or more service objectives which establish targets to be met. When a defined service involves multiple departments there are "hand-off" in terms of the technologies and/or specializations involved. Each hand-off raises a commitment by one department to another to efficiently perform their obligations in the total service offering. Those commitments are expressed in Operational Level Agreements.

There are two perspectives on which to focus initial attention on - SLA or OLA/UC development. In mature organizations, customer requirements will dictate what levels of performance are required. SLOs will be the operational expression of these requirements and provide high level guidelines for how service providers in the service chain should perform in order to meet the SLO on a consistent basis.

However, many organizations which are implementing SLM will have some existing characterization of their services, though performance expectations may not be well formulated. Service execution will be established by the performance of the various service chain participants. Codifying these characteristics will be a useful organizational exercise and one that is more accomplishable because it avoids (for the time being) the more difficult task of ensuring performance is sensitive to end-customer specifications. Also, establishing workable service objectives based upon current practices and reporting on them will establish the value and integrity of the process before undertaking more serious, time-consuming and conflictual negotiation processes.

Establishing OLAs for the many combinations of hand-offs which occur in service provisioning would be excessively complicated to administer on an ongoing basis. Instead, the relationships are accounted for in a single OLA between the unit and IS management. This simplifies the retention of these agreements and facilitates their comparison with the agreements which are used to describe the relationship with LOB technology partners and Corporate service customers.

Using the catalogue as an aid, SLM must plan the most appropriate SLA - OLA structure to ensure that all services and all Customers are covered in a manner best suited to the organization's needs. It is recommended that the architecture be adopted which establishes:

• A single Corporate SLA itemizing all services as detailed in the service catalogue for all direct Corporate Customers,
• A single corporate OLA between the primary IT service provider and individual LOB IT providers providing direct services to the organization's customers,
• Specific SLAs and OLAs with customers for unique services provided,
• Specific OLAs between the corporate IS senior leadership and departments for the composite provisioning of services described in services maintained in a service catalogue,
• Individual services described in service descriptions maintained in a Service Catalogue,
• SLAs and OLAs are maintained as Configuration Items in the CMDB and are subject to Change Management.

IT Service Catalogue

Or, this commentary from Centrata...

A service is: 'One or more IT systems which enable a business process'.

The purpose of the Service Catalogue is to:

• Highlight the services offered and managed by the IT service provider - a marketing endevour intended to demonstrate the breadth and scope of the provider's operations,
• Provide customers with information on how to access an IT service, its' costs and the choices available - an element of good customer service.
• provide a prowerful vehicle to promote better alignment between IT services and the goals and objectives of the organization

To avoid confusion, it may be a good idea to define a hierarchy of services within the Service Catalogue, by qualifying exactly what type of service is meant e.g. business service (that which is seen by the Customer), Infrastructure services, network service, application service (all invisible to the Customer - but essential to the delivery of Customer services).

The catalogue is maintained as part of the Configuration Management Database (CMDB). By defining each service as a Configuration Item (CI) and, where appropriate, relating these to form a service hierarchy, the IT provider will be able to relate events such as Incidents and RfCs to the services affected, thus providing the basis for service monitoring via an integrated tool (e.g. 'list or give the number of Incidents affecting this particular service').

The Service Catalogue can also be used for other Service Management purposes (e.g. for performing a Business Impact Analysis (BIA) as part of IT Service Continuity Planning, or as a starting place for Workload Management, part of Capacity Management). The cost and effort of producing the catalogue is therefore easily justifiable. If done in conjunction with prioritization of the BIA, then it is possible to ensure that the most important services are covered first.

At its' basic definitional level a service catalogue is a simple concept. Webster defines it as "a complete enumeration of items arranged systematically with descriptive details". There are three key elements in this definition:

• Complete - implies that the description of IT services should be exhaustive. However, it need to be complete only with reference to a stated purpose - expressed in terms of overall IT Service Management
• Systematic - "formulated as a coherent body of ideas or principles", the depiction of services should be based upon a consistent logic to achieve understanding of organizational goals and objectives,
• Descriptive details - the background material on the service, presented to sell or encourage usage by a Customer base.

A Service Catalogue should have easily-understandable descriptions and an intuitive interface for browsing service offerings. Effective Service Catalogs should also segment the customers they serve – whether end users, business unit executives, or other IT managers – and may provide different content based on role and needs.

The Service Catalogue should be transaction-based. A consumer viewing it should assume that if they see something they reqiure in the catalogue that it can be ordered directly. This direct relationship expedites processing and enlists the customers attention and ultimate usage of the catalogue.

Lastly, a Service Catalogue can provide a system of record for data that you need to manage the IT organization. The Service Catalogue can provide the means to manage customer demand, map fulfillment processes for each service, track service levels, drive process efficiencies, govern vendor performance, and determine costs. No service-oriented business can run effectively without such operational and financial data readily and easily available. ^R

The Purpose of Measurement

1. how is IT spending it's assigned appropriation
2. is the company receiving agreed-on value for this appropriation?
3. is IT assisting in meeting strategic and tactical business goals and objectives?

Because many parts of the organization are involved in answering these questions each requires different sets of metrics for their unique reasons. Lutcheon identifies different sets of users:

IT Value Area/Metric & Examples	Application and Use
	Enterprise	Business Unit Specific	Functional Area Specific
Alignment Governance and Leadership Business Management Liaison/SLAs Performance Measurement/Analysis/Reporting		Attributable IT spending per direct employee (budget & actual)
Support Sourcing Management and Legal Contracts and Issues Organization and People Skills Marketing and Communications Finance and Budgeting	Growth rate of total IT employees per growth rate of total employees (budget & actual)
Operations Service Delivery (Operations and Initiatives/Infrastructure) Enterprise Core System (Applications)			Growth rate of attributable IT spending per growth rate of direct total spending (budget & actual)
Resiliency Security/Confidentiality/Privacy Data Management and Quality Business Continuity and Disaster Recovery
Leverage User Technology Competencies and Skills
Futures Emerging Technology
Mark D. Lutcheon, managing IT as a business, John Wiley & Sons, 2004, ISBN: 0-471-47106-6, p. 162

Understanding how IT provides business value requires categorizing IT investments. Lutcheon outlines the business value considerations, typical business value outcome and presents key metrics for each of these areas. ^R.

IT Investment category	Value Characteristics	Value Outcomes	Value Metrics
Mission Critical Technology investment to gain competitive advantage or to position the organization in the marketplace to increase market share or sales	competitive advantage competitive necessity market positioning innovative services increased sales	50% fail some spectacular successes 2 to 3 yr lead time higher revenue / employee	Business Value Financial: revenue growth ROI ROA Revenue/employee
Business Critical Technology investment for managing and controlling the organization at the business unit level N	better information better integration improved quality increased sales	shorter time to market superior quality premium pricing improved control	Business Unit Operational: Time-new product to market Sales-new products Production/service quality
Management Control Technology investment to process basic repetitive transactions of the company. Focus is on high-volume transactions and cost reduction	increased throughput cost reduction	25% to 40% return higher ROI/ROA lower risk improved control	Business Unit IT Application: Time-application implementation Cost-application implementation
Infrastructure Technology investment to construct foundation IT capability N	standardization flexibility cost reduction	utility-type reliability support and facilitates change creates compatibility	Enterprise-wide IT infrastructure: infrastructure availability cost per transaction cost per user

Service Level Metrics

• Conceptually simple - ie. clearly defined and easily understood,
• Measurable - without excessive cost or effort,
• Valuable - provide the basis for decision-making and action including ROI analysis,
• Leverage organizational economies - ie. encourage functional behaviors,
• Consistent - the way the measurement and reporting is approached by anyone performing the measurement must be consistent, ^R
• Agreed to by all parties.

Infrastructure availability, for example, is measured at the Users screen, not at some intermediate component. The challenge is in integrating all intermediate components into the end-to-end metric. The result, in all cases, is that a much higher availability is now required from each subcomponent (since individual component availabilities are multiplicative to the overall measure).

To meet this overall requirement requires the stating and operational readiness of the individual components in the service chain. These metrics are stated as Operational Level Objectives (OLOs) amongst internal service partners and in Underpinning Contracts (UCs) when the service is provided by an external providers (eg. ISP, ASP).

What Gets Measured

• Availability - percentage of time service is available for use
• Performance - the rate (or speed) at which work is performed
• Reliability - how often a service or device, or network goes down or how long it stays down
• Recoverability - the time required to restore the service following a failure

Other measures which support the IT Provider in obtaining resources to delivery services include workload volumes, service desk responsiveness, implementation times for configuration changes and new services, as well as overall customer satisfaction.

A recent study by EMC advances a slightly different view of performance. It advances Quality of Experience as a key concept in measurement - "Quality of Experience is the ultimate “quality” metric because it is directed at real customer/consumer experience versus an array of technical objectives that may be measurable, but which as an aggregate may often have little or nothing to do with actual business impact^R".

EMA has defined the following key areas as useful in establishing QoE:

• Service availability – Availability needs to be understood first in terms of what it means to the end user experience, and then in terms of the infrastructure interdependencies that impact the availability of that service.
• Service responsiveness – Response time is primary in impacting the end user’s experience in interacting with an IT service. EMA research indicates that persistent degradation in responsiveness can be more disruptive to end-user experience than occasional or intermittent failures. This is because most users can work around short downtime issues and are more confident failures of availability will be fixed, than they are trusting that performance degradation will be corrected or even noticed.
• Service consistency – This is the consistency with which a service is available and responsive to the end customer. Consistency can be far more important that absolute averages that depend on huge swings in value. This is because most people work or perform communications-related and other application-related tasks in expected rhythms. When those rhythms are disrupted or unstable, the negative impact can be greater than it is when average delay times are slightly higher than ideal. For businesses with customer-facing applications, erratic responsiveness can be especially damaging in terms of customer loyalty and even brand position.
• Service appropriateness – IT should proactively determine, rather than take on face value, that the services it is delivering fit the customers they’re being delivered to. Customer Experience depends on delivering the right kinds of services at the right levels of quality to the right service consumers.
• Flexibility and mobility – Customer empowerment can increase satisfaction levels. These criteria really combine two notions – flexibility in terms of choosing types of application services and selecting from different quality levels; as well as mobility options for accessing information remotely – at home, or in the office, or while traveling.
• Security and compliance – These criteria are becoming increasingly visible requirements. More specifically, these criteria can include setting levels of guaranteed data security guaranteed for certain information, as well as enforcing and auditing appropriate end user access to critical IT services. They can also include metrics surrounding end user privacy and security in exchanging information
• Cost-effectiveness – Expense control is always important to customers, whether they’re business customers or individual consumers^R.

How it Gets Collected

• Monitoring all components used by application transactions and aggregating them to devise overall availability and performance measures,
• Inspecting network traffic to identify application transactions, which are then tracked to completion and measured for propagation delay,
• Using client agents that decode conversations to identify application transactions and measured client-perceived availability and responsiveness,
• Instrumenting the application code to define application transactions and collecting information on completed transactions and response times,
• Generating synthetic transactions at regular intervals and collecting availability and performance measures based on their tracking.^R

Applications with response times recorded above a pre-defined threshold are considered unavailable. A combination of the above method usually provides the best overall result though considerations of cost, reliability and intrusiveness may preclude some approaches.

These collection techniques fall into one of two primary categories:

• Event-driven Measurement - the times at which certain event shappen are recorded and then desired statistics are compared by analyzing the data
• Sampling-based Measurement - taking a scheduled, periodic look at certain counters or information access points

Who Uses it

Measured as the percentage of the time that a service is available for use, can be a controversial subject since it can involve a number of different measurement mechanisms. The variability of measurement is a result of differing perspectives of service goals, which vary primarily by the job function of the individual doing the measuring. For example, the network manager typically sees the service as network connectivity; the system manager views the service as the server remaining operational; the database administrator sees the service as available access to data held in the database. Hence, quoted availability usually relates to individual components and do not match the IT user's perception of availability. The end user or LOB wants to know that they can access the application and data required to perform their duties.

The first step in measuring and managing service levels is to define each service and map out the service from end-to-end.

1. Operating system service on hardware, presuming hardware availability. Most platform vendors that claim 99.9 percent uptime are referring to this.
2. End-to-end database service, presuming operating system and hardware availability.
3. Application service availability, including DBMS, operating system, and hardware availability.
4. Session availability, including all lower-level layers.
5. Application server divorced from the database. In this scenario, the business logic and connectivity to a data store are measured (and managed) independently of the database component. Note that a combination of (2) and (5) are essentially the same as service (4) to the user/client.
6. A complete, end-to end measure, including the client and the network. While the notion of a service implies the network, it is included in this diagram to show that you can establish the measure of availability for the stack as a whole with or without the network. For Internet-based applications, separating the network is important, because service providers can rarely, if ever, definitively establish and sustain service levels across the public network. Moreover, when a user connects across the Internet, it's important to understand how much of the user experience is colored by the vagaries of the Internet, and how much is under the direct control of operational staff. Decomposition into services is the first step toward defining what availability is measured, and why. As will be seen, indicating end-user availability over time does not require every service component to be measured and tracked separately.

There are three primary methods for capturing type 6 - the end-to-end measurement:

• Capture information at the User's desktop using client agents to decode conversations - this involves loading every client machine with a small agent that non-intrusively watches events such as keystrokes or network events. The agent then attempts to detect the start and end of the transaction and measure the time between them. The agent then sends the measured data to a central place where broader analysis can occur.
• Instrumenting an application (using APIs) to identify transactions with markers that can be monitored - the instrumentation APIs define the start and end of a business transaction and capture the total end-to-end response time as users process their transactions. Industry standards such as ARM (see Glossary) for the APIs have yet to be solidified. Best employed in a situation in which a full revision and upgrade of an application is undertaken
• Generating sample transactions that simulate the activities of the user community and that can be monitored - using scripts and intelligent agents or tools to capture transactions and later playing them back against an application service, this approach allows a simulated response time to be measured. By using distributed server resources or placing dedicated workstations at desired locations to submit transactions for critical applications, a continuous sampling of response times by location can be captured and reported. The strength of this method is in its ability to provide the end-user experience using samples rather than having to collect large volumes of data across all transactions from all end users.

How It Should be stated

Stating the goal as percent Unavailability has a different impact. In this case the goal was .4% unavailability and the Provider had 1% unavailability. Here the percentage is (1.0-.4)/.4 = 150% variation from expected. An entirely different perspective ensues. Even quoting unavailability does not provide the whole picture. From the Customer's perspective an outage of 2 hours may be more palatable than 6 outages of 20 minutes each (or it may not - depending on the application). The difference would certainly lead to the perception of greater instability in the second instance.

The purest and most useful measure is to relate unavailability to costs to the business. To capture this requires that the Service Desk accurately record the number of people affected and that this gets multiplied by an amount per unit time of outage. This latter number must be established ahead of time. Frequently, this cost may have been devised as part of a Business Impact Analysis (BIA) in developing Disaster Recovery Plans (DRPs) for major applications.

Service Culture

The impact of culture on an organization is easily underestimated. Yet, to a great extent it influences the way employees function within the organization. Employees' attitudes toward leadership, for example, have a large impact on the effective style of that leadership within an organization. And, the primary businesses engaged in will establish many elements of how people interact with each other, achieve recognition and reward. The organizational culture also determines how people react to change and thus how successful a certain change strategy will be. To cope with cultural differences when implementing processes, change moderators should adopt a leadership style, which is most effective depending on the situation they face.

Cultural elements to be taken into account when implementing or improving processes in an organization:

• attitude towards leadership
• hierarchical or flat/informal structures
• communication: formal or informal
• sensitivity towards change: open vs. reserved
• position: extrovert vs. introvert.

These items are the mechanisms of organizational culture. However there are other, more ephemeral aspects of culture in the way people interact with each other, and with customers - and, many staff both are served by, and provide service to, someone else. Almost all organizations understand the value of customer service: after all, without customers there is no service - no service, no performance, no work, no jobs. However, what is less clear is the value of servicing those who provide service to paying customers - ie. those who provide indirect or "support" services. To most enterprises all of IT is usually in this class (although e-business has the tendency to alter this relationship as end customers increasingly interact directly with the technology). These are the service chains which comprise "end-to-end" service provision. Each interaction or "hand-off" needs to be treated as if it was the end customer that was the recipient of the service.

Every time customers do business with the IT provider, they are, without fully realizing it, scoring the organization on how well it is doing, not only at giving them what they want (hopefully established in agreements), but at fulfilling six basic customer needs:

• Friendliness: The most basic of all customer needs, friendliness is usually associated with being greeted politely and courteously,
• Understanding and empathy: The most basic of all customer needs, and it's usually associated with being greeted politely and courteously,
• Fairness: The need to be treated fairly is high up on most customers' list of needs. This will translate into consistency and is enabled through the application of consistent, stated methods and procedures,
• Control: Control represents the Customers need to feel as if they have an impact on the way things turn out,
• Options and alternatives: Customers need to feel that other avenues are available to getting what they want accomplished,
• Information: Customers need to be educated and informed about the products, policies, and procedures they encounter when dealing with your company.

Communications and Marketing

Central to any marketing activities is the service catalogue - 'A "menu" of services - their description, deliverables, availability. limitations, price, and method of accessing them - should be the basis of all marketing communications.' There should be regular communications, using an appropriate mix of 'push' and 'pull' approaches and using existing internet delivery sources, describing changes and introductions and changes should be described as they occur.

Instillation of a service culture is dependent on the communication of performance and communications is the life blood of the organization and fuel for processes. It should flow horizontally, elegantly and spontaneously to support service objectives - "Communication lubricates change; it won't guarantee success - it will guarantee failure."^Reference

Communications and Marketing Roles

The Service Desk plays primarily a reactive role. As the Fist Point of Contact (FPOC) for inquiries about services they must be prepared to direct Users to source information and answer service-related questions.

Management assures that communications channels remain open and 'lubricated' for easy access. They will frequently have to intervene when the news to be disseminated is less than positive or popular.

Operations needs to ensure that user satisfaction expressions with their services is received, acted upon and that the remedial actions are communicated back to Customers.

Communicating Performance

Roles and Responsibilities

SLM Process Owner

• primary source of management information on the Service Level Management (SLM) process,
• manages relationships between customers and IS department,
• provision and operation of tools to support performance reporting on an ongoing basis,
• ensure customer satisfaction with process,
• ensure that business and stakeholders are involved in collecting business requirements for service level determination.

Service Level Manager

• coordinate establishment, maintenance and review of SLAs, OLAs, UCs,
• CI owner of SLAs, OLAs and UCs,
• Define and negotiate the level of user services for specific customers, documenting them in SLAs,
• Determine fit of standard services (as defined in Service Catalogue) based on customer's service level requirements, and design custom service as necessary,
• Monitor, report and review on the achievement of Service and Operational level objectives,
• Initiate actions (eg. RfC, Service Improvement Plan [SIP]) to overcome problems identified in meeting service levels,

Customer Account Representative

• Primary interface between IT provider and lines of business,
• Ensure customer requirements are captured and communicated to IS department senior management,
• Foster the business relationship between IT and lines of business,
• Provide point of escalation for issues involving customer communications and user service disaffection,
• Advise LOB customers on IT provider policies, organization and strategies,
• Mediate disputes between IT provider and lines of business,
• Meet with customers to review and update SLAs and OLAs on the business of new and/or revised business needs,
• Advise on the impact of releases, changes and incident on service commitments.

Service Planning

• design new services,
• assist in establishment of services' funding levels.

Financial Management

• maintain costing formulae related to service charge-backs,
• allocate costs to IT provider organizational units,
• provide estimates of costs for fiscal year budgeting,
• provide service cost estimating advice.

Operations Management

• Configuration Owners for services listed in the Service Catalogue,
• assist in describing the service chains associated with service provisioning,,
• assess levels at which services can be provided for different funding and performance scenarios,
• meeting OLOs and explaining variances from targets

Senior Leadership Team

• approve new services for introduction in IS department,
• make decisions on the provision of services at specified levels,
• review and recommend Improvement Initiatives,
• review Balanced Scorecard information describing operational performance,
• act as the final point of escalation for service complaints.

Performance Measurement

Key Goal and Performance Indicators

By comparison, a Key Performance Indicator is a measure of "how well" the process is performing. They will often be a measure of a Critical Success Factor and, when monitored and acted upon, will identify opportunities for the improvement of the process. These improvements should positively influence the outcome and, as such, Key Performance Indicators have a cause-effect relationship with the Key Goal Indicators of the process.

Key measurable elements of a service include :

• Sign-off by strategic business unit that service levels are aligned with key business objectives,
• Customer satisfaction that the service level meets expectations^Note,
• Actual to budget cost ratio in line with service levels,
• Percent of all critical business processes relying on IT covered by SLA or OLA,
• Percent of SLAs and OLAs reviewed at the agreed interval or following major change,
• Service level partners sign off service level monitoring information provided,
• Percent of IT services which meet SLAs / OLAs.

Metrics

• Time lag of resolution of a service level change request,
• Frequency of customer satisfaction surveys,
• Time lag to resolve a service level issues,
• Number of times that root cause analysis of service level procedure and subsequent resolution is completed within required period,
• Significance of amount of additional funding needed to deliver the defined service level.

Measurement Issues

• End-to-end service availability is difficult to measure and is greatly facilitated by integrated toolsets which are rapidly emerging and maturing, but are presently expensive and not yet feature-rich. In their absence, it is sometimes necessary to rely upon tools which measure part of a process. Agreement on the degree to which these tools approximate measures of interest to users is a subject of negotiation and caveats when reporting,
• SLM reporting should cover a spectrum of targets from Business Management in which high-level Business Scorecards which outline performance against Key Goal Indicators are tracked to operational performance measures. These will specify technical performance as contributions to meeting KPI and KPG goals. The relationship amongst measures is akin the relationship amongst service participants in a service chain and describes how well each participant interacts to meet overall objectives.

Processes

Inputs

• Negotiated Agreements - Any previous written statements with Customers or amongst IT provider organizations which can be translated into service specifications by SLM staff responsible to fulfill SLA. Service level agreements may also be agreed between support groups within IT to define parameters and procedures for hand-offs and assignments between groups.
• Benchmarks - industry performance standards for Service Level Objectives,
• Past Performance - listing and cataloging of service commitments in use through IT provider,
• Service Level Requirements - lines of business need for services at specified levels of performance
• Incident Tickets - Incidents referred to Account Representatives dealing with services
• Satisfaction Surveys - review surveys conducted with Customers related to satisfaction levels

• Contract Requirements -- Written agreement with the client that defines specified support criteria. Defines core vs. add-on work in order to determine levels of approval required for fulfillment. Add on work as defined by the contract would require additional approvals before proceeding.
• LOB SLA - any SLA between LOB IT service providers and their Customers which will establish performance expectations which need to be infused in OLAs between IT Provider and LOB,
• LOB Budgets - determine line of business ability to pay for services provided by IT service provider
• Budget Cycle - determines timing around knowledge and creation of line of business budgets which determine the LOBs ability to pay for IT services
• SLM Operations - roles and responsibilities and resources to administer SLM process

• Negotiation - SLAs, OLAs and SLRs are negotiated with lines of business management and amongst internal IT provider units
• Reporting - Agreements and performance are reported using a variety of techniques including online performance systems, regular meeting agenda, and monthly standard report formats
• Recording - recording service complaints and performance results for trend analysis and management decision-making

Outputs

• Updated Service Catalogue - Service Catalogue is updated to reflect changes in services provided by IT Service Provider
• Updated SLAs, OLAs - SLAs and OLAs are periodically updated to reflect new levels of operational characteristics and to the lines of business to whom the services are provided
• Performance Reports - Performance reports are regularly produced to report on how well IT service provider is performing against stated SLOs
• Resolved Complaints - Closed incidents by service category
• Service Improvement Programs - Where an underlying difficulty has been identified which is adversely impacting upon service quality, Service Level Management must, in conjunction with Problem Management and Availability Management, instigate a SIP to identify and implement whatever actions are necessary to overcome the difficulties and restore service quality.
• Service Review Meetings - Periodic review meetings must be held on a regular basis with Customers (or their representatives) to review the service achievement in the last period and to preview any issues for the coming period. It is normal to hold such meetings monthly, or as a minimum, quarterly.

Activities Detail

SL1.1 Describe Services

Current services have not evolved in a structured context within IT Service Provider. As such there is no consistent definition of their origin, their expected ROI, performance, etc. This information must be gathered from diverse sources and interviewing of key personnel. A service Catalogue traditionally includes the descriptions itemized in Appendix.

The language should be targeted at the business customer and should arduously avoid technical jargon.

SL1.2 Integrate with Other ITIL Processes

SL1.3 Solicit Customer Feedback

• Online survey to be filled in upon accessing service catalog,
• Focus groups,
• E-mail random survey.

SL1.4 Review Financial Model Against Service Descriptions

SL1.5 Extend Coverage of Service Catalogue

• The service chain involved in the delivery of the service including dependencies and performance obligations
• The full costs of delivery of the service and any charging arrangements associated with it
• Fully integrated performance measures, metrics used and the assumptions implied with their usage

Service Chain Description

These are descriptions of the service chain involved in the complete delivery of a service. It would include the respective roles and responsibilities of all participants in the chain and outline the Operational Level Objectives (OLOs) required to meet the total service commitments.

Service Costs

Service level management and the resulting IT services that it enables come at a substantial cost to the enterprise measured by both monetary and human resource requirements. In order to make an intelligent decision relative to service provisioning, IT Service Provider must accurately identify all costs of the services being evaluated. This might be found in the original determinations used for staffing levels for services. This information will not only provide needed financial information but will likely describe the various activities which are outputs of the service.

In order to identify costs, all components of the IT infrastructure that combine to enable a service need to be considered. In all areas, these costs can be significant. It is necessary that a comprehensive ROI analysis be performed on each activity to determine if the expected return to the organization, both directly financial (cost vs. benefit) and indirect effort (cost vs. increased or maintained customer productivity levels) is worthwhile. In cases where the ROI process indicates that the service does add enough value to the organization to be worthwhile, the service should not be implemented. In instances where the ROI process has established that the service is of value to the organization, the service will be implemented. In some cases, the service requested may be simple in nature. It does not significantly impact the areas of service provisioning that the cost analysis is designed to evaluate. The service level manager makes a "judgment call" in these cases and may elect to establish the new service without formally executing the financial analysis process.

A key driver in describing a service is how much IT Service Provider stands to lose as a result of a service outage and the speed of escalation of these damages. A Service Impact Analysis will assess this by identifying:

• Critical business processes which are reliant on the service
• The potential damage or loss that may be caused to the organization as a result of a disruption of the services
• The form that the damage or loss may take including lost income, additional costs, damage to reputation, loss of goodwill, and loss of competitive advantage
• How the degree of damage or loss is likely to escalate after an incident involving the service
• The staffing, skills, facilities, and services necessary to enable critical and essential business processes to continue operating the service at a minimum acceptable level
• The time within which minimum levels of staffing, facilities, and services should be recovered to normal levels following a loss of service

.

The last two items provide drivers for the level of mechanisms that need to be considered or deployed. Once presented with these options, the organization may decide that lower levels of service or increased delays are more acceptable based upon a cost/benefit analysis. The level needed is recorded and agreed upon within an SLA/OLA. These definitions and their components enable the mapping of critical services, thus helping to identify the elements that a organization needs to provide. The requirements can be ranked and the associated elements confirmed and prioritized in terms of risk assessment/reduction and recovery planning.

Fully Integrated Performance Measures

This involves the total rationalization of performance metrics through Service Catalogues, SLAs, OLAs and UCs. The rationalization includes internal consistencies between metrics forming a part of a larger metric.

SL1.6 Revise Service Catalog

SLM2: SLA Project Startup Process

SL2.1 Appoint SLM Process Owner

With the introduction of SLM the Catalogue becomes an integral part of the service management picture. It becomes a central focus of "negotiated" service levels with sufficiently accurate financial and performance data to permit sophisticated ROI and performance analyses. It is an important amendment to SLA and OLA negotiations and has a central place in monitoring the overall performance of IS.

This added dimensionality requires explicit accountability in order to make it happen. The Service Level Manager should be a senior IT Service Provider manager with primary responsibility for relationship management with IS's customer base and a direct reporting relationship to IS Corporate Head.

SL2.2 Design SLA - OLA Architecture

• A single OLA describing services common to multiple LOB IT Providers,
• Most of the LOB IT Providers have associated survival-critical applications which are specific to their areas but which utilize underlying technologies which may be in use in other LOBs (eg. Oracle, websphere),
• A single SLA outlining the provision of the above and additional services to multiple corporate service clients,
• An evolving trend to further consolidation of service offerings within IT Service Provider in order to maximize the economies of scale associated with support and licensing

SL2.3 Get Agreement on Agreement

SL2.4 Establish Rules of Engagement

SL2.5 Develop SLR/OLRs

SL2.6 Pilot with Memorandum of Understanding then migrate to SLA / OLAs

A Memorandum of Understanding (MOU) is a far more limited agreement which can transpose itself into an SLA or OLA at some time. Secondly, the MOU can be initiated for designated services (eg., network) and expanded later to encompass other services in a timed release. Lastly, the agreement can be devised for a specific LOB IT Provider and/or corporate services the choice partly determined by the services selected).

To invoke an agreement IT Service Provider evaluates and decides which services/customers are used for the pilot effort. Criteria for selection of the appropriate MOU are subjective. The following criteria have been cited:

• The area most critical to the business,
• Where most improvement is needed,
• The most disgruntled group,
• The most politically powerful group,
• Areas of highest/lowest visibility.

The purpose of the effort is to test the fundamental SLM processes in as non-complex, low risk environment as practical. It is critical that customers be involved. Engage customers that use the service. As with selection of the service itself, the customers involved must meet minimum criteria in that they:

• View IT a true value add to the enterprise,
• Are proficient users of the service,
• Are enthusiastic and willing to participate,
• Are genuinely interested in enabling improvements in service quality,
• Perceive the service as beneficial to them, not as a service that they are forced to use.

LOB Customers are more interested in issues such as responsiveness, usability, and reliability. All of the appropriate and relevant customer requirements, at all levels, must be identified and incorporated in the MOU in order for the process to be successful. Representatives from the internal IT support partners must also be consulted during the process. Agreement that targets are realistic, achievable, and affordable need to be obtained or modified based on their input. This includes the views of any external IT support partners who should also be consulted and any contractual implications should be accounted for during the negotiation stages of the pilot process.

The MOU used in this effort remains in draft format for the initial pilot period. Before developing a SLA or OLA, all members of both parties who have a stake in, or responsibility for, the success of the agreement should have an opportunity to review the MOU, raise questions, and offer suggestions. Using this feedback, SLM staff can begin more extensive negotiations towards an initial SLA / OLA.

SL2.7 Market Service Catalogue and Agreements

SLM3: IT Corporate Performance Measurement Process Startup

SL3.1 Research Metrics in Current Use

Most organizations with a history of application and network support have some means of reporting availability and capacity metrics. Many have implemented automated toolsets to provide metrics on a continuing basis.

Rarer are enterprise management systems designed to provide the kind of end-to-end service metrics described in section 5.4. When SLM is implemented a Level 4 or 5 maturity the SLM architecture contains design elements such as:

• Event correlation strategies to automatically diagnose root causes of failure and institute corrective actions.
• Component-to-service mappings which makes assignments when components are or are not working based on response thresholds
• The definition of agents to undertake monitoring - device, traffic, system, application, special-purpose and enterprise-wide agents
• How agents are integrated to provide end-to-end measurements
• Given the costs of using end-to-end agents what available proxy measures can be obtained more cheaply.

The best, most encompassing agents may be too costly. However, measures which approximate the performance characteristics of what is being measured may provide satisfactory results at acceptable costs. The organization must make a strategic trade-offs amongst precision, risk and cost. Since integrated tools continue to improve and since many company's internal processes are not ready for quantitative management techniques the best strategy may be "wait and see" with SLM endeavors concentrating on developing ancillary, less costly procedures as a priority.

SL3.2 Establish Benchmarks

A benchmark is a measurement or standard that services as a point of reference by which IT Service Provider service performance can be measured. Benchmarking is a structured approach for identifying best practices and comparing and adapting them to IT Service Provider's operations. These targets provide goals for achieving intended service results and for directing Service Improvement Initiatives (SIPs).

Benchmarking performance assists IT Service Provider is comparing its' performance with organizations with similar characteristics. The benchmarking then provides a reference point for improvement.

In the absence of meaningful industry comparison IT Service Provider can sometimes find internal benchmarks either from other internal service providers or develop them over time. In the end, the defined Service and Operational Level Objectives (SLO/OLOs) will constitute benchmarks for service improvement. By designing a stretch objective and a commitment objective IT Service Provider can distinguish between what it is committed to meet and what it aspires to meet.

SL3.3 Rationalize SLA / OLA metric usage

IT Service Provider service commitments as part of an overall service chain should also be internally consistent amongst bundled services that they form a part of. For example, the acquisition of a software product should involve the same timeframe when it is acquired constitutes part of a new employee service as when it is required as part of a remote access service.

The provision of these services should also be in accordance with any SLAs maintains by LOB IT service providers and their Customers in order that they can achieve them. This means that IT Service Provider services should have OLAs consistent with existing SLA by LOB providers, and, conversely, when constructing and/or modifying agreements that LOB IT Providers recognize IT Service Provider OLOs as they are published.

SL3.4 Determine Reporting Needs

Traditionally, organizations start by reporting on measurements which are readily available. This usually involves the reporting of service availabilities. Subsequently, as capabilities are augmented responsiveness measures are added. As well it is traditionally easier to measure and monitor the availability of various technology components before they can be rationalized to provide end-to-end availability of service from the corporate client or LOB IT provider's perspective.

During implementation of measurement, a stabilization of IS's overall IT-CPM strategy will occur. People viewing measures can determine inconsistencies with the aggregated measures and what is generally expected. This will help to uncover glitches in the collection processes. Determining problems with data collection and connecting them is a necessary evolution that takes place during the measurement stage. Without this weeding out of collection problems, companies cannot successfully move into the latter stages of the cycle because to base analysis and planning on a suspect measurement system makes no sense.

SL3.5 SLM Toolset Selection

Use scorecards as the "shop window" to CPM, but focus on the overall planning and control cycle for substantial improvements.

The most widespread approach to monitoring applications uses intelligent autonomous agents to gather information on an application and the underlying infrastructure. These agents use a variety of measurement techniques to collect the data that is then used for incident management and problem diagnosis and stored for trend analysis and reporting. Management agents perform a number of functions including scheduling the collection of data, determining event conditions, forwarding this event information to consoles, executing recovery actions and storing metric and event information for historical purposes. However, they should be piloted first in order to measure the extent of the performance "hit" they impose. By estimating the number of events and overhead required to manage those events, the agent's impact on the system can be accurately planned.

SLM4: Service Management Ongoing Process Summary

SL4.1 Service Catalogue Change

SL4.2 Ongoing IT-CPM

Once the agreements are in place, it's important to compile and analyze performance data and report it regularly to customers. This should lead to a service improvement program (SIP). The goal is to know where targets were missed and how to fix them -- buy more capacity, for example. By continually improving the tie between IT performance and business goals, IT Service Provider stands a better chance of building an IT organization that truly serves business success.

Periodic review meetings must be held on a regular basis with Customers (or their representatives) to review the service achievement in the last period and to preview any issues for the coming period. It is normal to hold such meetings monthly, or as a minimum, quarterly.

Actions must be placed on the Customer and provider as appropriate to improve weak areas where targets are not being met. All actions must be minuted, and progress should be reviewed at the next meeting to ensure that action items arc being followed up and properly implemented.

Particular attention should be focused on each breach of service levels to determine exactly what caused the loss of service and what can be done to prevent any recurrence. If it is decided that the service level was, or has become, unachievable, it may be necessary to review and re-agree different service targets. If the service break has been caused by a failure of a third-party or internal support group, it may also be necessary to review the underpinning agreement or OLA.

Where analysis of performance data suggests an operational problem it may be necessary to convene special meeting of participants in a service chain to discuss specific operational issues pinpointed by the performance figures. These discussions should result in specific recommendations to address performance bottlenecks.

SL4.3 SLA / OLA / UC Amendments

In addition, new business demands may necessitate changes to existing agreements. It is recommended that such changes be framed as separate agreements or addenda to existing agreements and that agreements be subject to a defined versioning logic.

As with new services introduced into the live environment, the planning and formalization of the support arrangements for any retiring services must be addressed. The specific responsibilities of all involved need to be defined and either added to existing SLAs, OLAs, UCs, or new agreements and contracts established. The resulting documents identify the support requirements for the service. Once created, these documents and associated support arrangement and all escalation routes must be integrated into the CMDB. This facilitates awareness by those support groups affected such as the service desk, availability, change management, release management and capacity management teams. When identified as required, appropriate education and familiarization for these affected groups must be completed before the point in time between when the new service is introduced and support for the new service will be required.

SL4.4 Service Catalogue Review

• Annual budgetary appropriations are charge-back formulae which might suggest Service modification
• Changes in service descriptions resultant from organizational re-organizations
• Technology changes which will modify service offerings
• The integration and rationalization of new services into the environment

SL4.5 Service Improvement Program (SIP)

SL4.6 Update Service Level Requirements

Updating SLRs should have the following deliverables:

• Determine Business needs - to gain input into the account planning process with respect to changes that need to be factored into the business unit account plan and ultimately into the overall IT plan
• Review Previous Experience - gain an understanding of the service history of a specific business unit
• Determine Satisfaction Level - develop a broad view of the overall satisfaction of the business user with their experiences
• Determine Expectations Gap - complete account profile by analyzing the information contained in the account profile and highlight the gaps uncovered between the user's expectations and the service provided
• Develop SLR Plan for each account - create a document for each business unit to serve as a focal point for planning how to provide service to that unit in the future

SL4.7 Evaluate SLA / OLA Performance

These reviews should evaluate performance against all service level requirements to determine which ones have been satisfied and which ones have not. The staff then takes corrective action to address those areas that fail to meet the requirements and/or negotiates changes in the service levels required. In addition, the incident management and problem resolution processes result in important learning about the supported system. This learning drives changes to specific operational processes, tools, and procedures as needed.

SL4.8 Renew SLAs and OLAs

• To ensure agreements reflect evolving business requirements,
• Re-state Service and Operational Level Objectives in terms of realistic objectives which reflect business needs,
• To continue to improve service level management practices and procedures
• To extend the scope and breadth of SLM coverage
• To achieve operational efficiencies in the delivery of SLM

Appendix

SLA Architecture Options

Service Based

This may appear fairly straightforward. However, difficulties may arise if the specific requirements of different Customers vary for the same service, or if characteristics of the IT Infrastructure mean that different service levels are inevitable (e.g. head office staff may be connected via a high-speed LAN while local offices may have to use a lower speed leased line). In such cases, separate targets may be needed within the one agreement. Difficulties may also arise in determining who should be the signatories to such an agreement.

Customer Based

Customers often prefer such an agreement, as all of their requirements are covered in a single document. Only one signatory is normally required, which simplifies this issue.

Multi-level SLAs

• Corporate Level: covering all the generic SLM issues appropriate to every Customer throughout the organization. These issues are likely to be less volatile and so updates are less frequently required.
• Customer Level: covering all SLM issues relevant to the particular Customer group, regardless of the service being used.
• Service Level: covering all SLM issues relevant to the specific service, in relation to this specific Customer group (one for each service covered by the SLA).

As shown in the figure to the right, such a structure allows SLAs to be kept to a manageable size, avoids unnecessary duplication, and reduces the need for frequent updates.

Parties to the Agreement

Term of the Agreement

Scope

Limitations

• Volumes - eg. Number of concurrent users
• Topology - locations of facilities where service is to be delivered
• Funding - available funding sources

Service Level Objectives (SLO)

• The agreed upon levels of service which are to be provided. For each aspect of the service covered by the agreement, there should be one or more target level defined (eg. expected target and a stretch target - ie. a commitment and a goal).
• The most popular SLOs are availability, performance and accuracy. Others might be cost and security.
• Define the minimum acceptable percentage of availability
• Performance includes measurement of speed and/or volume - typically, response time

SLOs should be:

• Attainable - under identical conditions everywhere,
• Meaningful to all parties - ie. expressed in terms understandable by Customer and reflecting end-to-end service - ie. as experienced by user
• Measurable - if it is not possible nor affordable to measure something to represent an SLO then the objective is worthless and should not be included,
• Controllable by the Service Provider - must be able to exercise control over the factors that determine the level of service which is delivered,
• Mutually acceptable to all parties - all must be able to live with it.

Service Level Indicators (Metrics)

Frequency and Interval of Measurement

LOB's Responsibilities

IT Provider's Responsibilities

• shall assume responsibility for customer communications at the point that customer messages leave the Internet service provider.
• shall ensure that all messages are processed in a timely fashion. (Be sure to define the specifics of "timely" standards.)
• shall ensure that the system shall be able to accept and respond to 1,200 inquiries per minute.
• (Include any other items that IT Service Provider will need to do to provide the prescribed level of service to LOBs.)

Escalation Guidelines

Renegotiations

• Authorized representatives of LOB and IT Service Provider must mutually agree upon changes to this SLA.
• All changes must be made and agreed to in writing.
• Either party may request review of this SLA at any time. Each party will review the SLA annually and advise the other party of any desired changes.
• Technology service providers encompass a broad range of entities including but not limited to affiliated entities, nonaffiliated entities, and alliances of companies providing products and services. This may include but is not limited to: core processing; information and transaction processing and settlement activities that support banking functions such as lending, deposit-taking, funds transfer, fiduciary, or trading activities; Internet-related services; security monitoring; systems development and maintenance; aggregation services; digital certification services, and call centers. Other terms used to describe Service Providers include vendors, subcontractors, external service provider (ESPs) and outsourcers.

Comparison of SLA and OLA

SLA	OLA
Describes the service, terms, and conditions for agreement between IT and one or more customers	Describes service components, requirements, and conditions required from an internal service provider (IT entity)
The duration of the SLA is specifically defined with a start and end date	Reviewed frequently to capture changes in day-to-day service delivery
Is business and customer-focused	Is internal-IT focused
Describes the specific business metrics committed to by IT and the frequency they will be reported	Describes the service component metrics and the frequency they will be measured by the internal service provider (IT entity)
Describes roles and responsibilities for customer and IT	Describes roles and responsibilities for IT staff and individual contributors
Describes the business linkages between IT and the customer	Describes the day-to-day linkages between IT service providers and customers

Service Catalogue Description

Description

How to Access

Long-Term Objectives

The "targets" for this service over the near, medium and long term. Targets may be "strategic" (positioning of the service in alignment with I&IT objectives) or metric (measurable performance indicators). Objectives should indicate how well the service is to be delivered now, and in the future and methods to close any performance gaps. Any existing service standards which the organization is expected to strive towards should be discussed here.

Service Commitments

• Availability - what IT Service Provider will commit to in terms of ensuring the service is available.
• Capacity - what response can the Customer expect from the service.
• Integrity - the accuracy which can be guaranteed (sometimes expressed as security)

How a measure is determined and any assumptions implicit in its' use should be discussed. There should be some discussion as to what would constitute a significant variance which would trigger management attention.

Work Packages

Dependencies

• Partner Obligations: Dependencies often result in service obligation by a service partner. It is important to specify conditions upon which a service is dependent. The ways in which the obligations might be breached and the implications of the failures on meeting performance expectations should be discussed.
• Customer Obligations: If we assume that customers are sometimes service co-producers, this means that they are either an asset or a 'disruptive factor'. The role, participation and responsibility of the customer in service production must therefore be made clear. The goal of service development is to provide the best and right prerequisites for well-functioning processes - for instance, the technical resources, the administrative routines and procedures, which customers must understand and use.

Financing

In order to identify resource needs, all components of the IT infrastructure that combine to enable a service need to be considered. In all areas, these costs can be significant.

Resource Model

• When Service is Performed - Scheduled (on an ongoing basis) or On Demand (as requested by Customer)
• Offered Time - the time period in which the service is offered - eg. 24x7x365, 7x7 (Mon-Fri), 8x5
• Skill Set- job description code(s) assigned to work package
• Frequency - an estimate of how many times a work package (activity) will be performed, eg. how many server installations will be requested
• Unit of Measure - determines how the work package will be measured. It is usually preferable to use measurement of one (eg. one server installation) but other aggregations may be more appropriate (including expression of time periods such as per hour, per day, etc)
• Estimated Time to Complete a Work Package - How many resources are required to complete a Work Package
• Overhead Costs - an amount or percentage which needs to be added to the above per Work Package to maintain or complete the work package. This may accommodate ongoing training, holiday provisioning, benefits, equipment support, etc

At some point, it is necessary that a comprehensive ROI analysis be performed on each activity to determine if the expected return to the organization, both directly financial (cost vs. benefit) and indirect effort (cost vs. increased or maintained customer productivity levels) is worthwhile. In cases where the ROI process indicates that the service does add enough value to the enterprise to be worthwhile, the service will not be implemented. In instances where the ROI process has established that the service is of value to the organization, the service will be implemented. In some cases, the service requested may be simple in nature. It does not significantly impact the areas of service provisioning that the cost analysis is designed to evaluate. The service level manager makes a "judgment call" in these cases and may elect to establish the new service without formally executing the financial analysis process.

The cost and methods of financing the service should be expressed. If the service is provided as part of an overall annual appropriation to the IT provider some effort should be devoted to estimating the capital, start-up and operating costs of the service. This permits a comparison of Return on Investment (ROI) from the services offered by the Provider. Where costs are recovered (typically as part of a premium service offering) the costs of various level of premium service should be itemized. Details of any charge-back scheduled and methods should be listed for the service.

Contacts

COBIT Definition of SLM Maturity Levels - IT-CPM Equivalent

SLM Toolset Considerations

Monitoring Agents

Some types of problem tracking or call management systems market themselves as having service level management functionality. In some ways, this is correct: many businesses use standard help desk tools to report on network availability, overall system availability, and customer service levels based on the types of trouble tickets received. This kind of "service level management" is, by nature, purely reactive, relying as it does on after-the-fact information capture of service failures. These tools also provide no mechanism for tying performance to business goals.

Still other types of systems will be a little closer to a mature implementation of SLM by using test transactions to simulate customer/end user activity. Essentially, these systems send a 'synthetic transaction" through standard customer system, timing them and monitoring for difficulties. Obviously, these systems confine themselves to network and application service level management, although they can make some measure of business success by examining employee productivity (or lack thereof, due to system problems) or customer system experience.

Web monitoring systems are becoming more prevalent. These systems examine the service experienced by web site users, and may also use test transactions to measure web site access events. There are also service level management systems that focus on specific technologies, such as VOIP, or on particular industries (telecom, ISPs).

Dashboards / Scorecards

When looking for these types of tools, integration may be the most critical "under-the-hood" factor. A system that can integrate, out-of-the-box, with as many of your current performance measurement tools as possible is highly desirable. As long as existing tools are performing in a satisfactory manner, there is no need to replace them; but rather to harvest their data. In addition, the SLM tool should be able to link to proprietary data sources.

Besides ease of use for the administrator, ease of use for business people is a main consideration. An SLM tool must allow customers to define, in business terms, what service success means. SLAs must be built up from clear SLOs: a business person should be able to create a metric for, say, the cost of providing "Gold" level service to major account customers that's comprised of measurements like average speed of answer, talk time, resource costs, and the specific customer contract terms. The system should also be able to report on this type of metric with a simple dashboard- or cockpit-style interface, and allow business users to drill down to determine the specific measurement that may be threatening the overall service.

Analytic Tools

Reporting must be flexible and easily customizable. It should be easy to set alarms to indicate when service levels are in danger of being breached, and these alarms should be easily configurable to alert for e-mail, pager, cellular phone, etc. Finally, the system should be smart enough to adjust objectives based on changing conditions. An increase in the number of employees providing a particular service should be reflected in all the metrics associated with that service - without requiring administrator or business unit intervention. Ideally, the system needs to be able to take data from systems or files associated with services, contractual agreements with outsourcers or customers, resources, finance and budgets, and processes (such as change management or knowledge management) and relate it into unified information that speaks directly to the organization's overall business goals and vision. In this way, true Service Level Management is achieved.

Business Intelligence Tools