Process 5: Service Level Management

  • Article

 

If IT strategy is to be seamlessly aligned to the organization’s strategy, IT must manage the ongoing delivery and enhancement of its services—this is the goal of Service Level Management. Service Level Management ensures that ongoing requirements, communications, and expectations between business and IT are proactively managed. Service Level Management is also responsible for ensuring that internal IT expectations are being met.

The service catalog sets the standards against which expectations, improvements, and performance metrics are measured. SLAs and operating level agreements (OLAs) ensure that agreements are in place to support the offerings within the service catalog.

IT Service Catalog:

  • Communicates standard IT services to customers in clear, familiar terms.
  • Provides a centralized channel through which end users can request standardized, typical IT service bundles.

Operating Level Agreements (OLAs):

  • Communicate and document the agreed-upon expectations of dependent IT services.
  • Are agreed upon between IT teams.

Service Level Agreements (SLAs):

  • Communicate and document the agreed-upon expectations of business-facing IT services.
  • Are agreed upon between business and IT representatives.

Underpinning Contract (UC):

  • Ensures there is a contract between suppliers, third parties, and the organization.
  • Communicates and documents the agreed-upon expectations between the suppliers, third parties, and the organization.

Figure 3 depicts the relationship between the customers, SLA, OLA and UC.

Figure 3. The relationship between customers, the SLA, the OLA, and the UC

Figure 4 graphically depicts a set of SLAs and OLAs for the fictitious Woodgrove Bank. The SLA is in place to ensure that end users receive prompt and accurate desktop support. The overall usability of the desktop is ensured through this SLA; however, supporting services funnel to this node from OLAs covering desktop hardware, messaging, directory, line-of-business (LOB) applications, and networking.


 

Figure 4. SLA, OLAs, and UCs for Woodgrove Bank desktop computing (example)

Activities: Service Level Management

The following table lists the activities involved in this process. These activities include:

  • Managing business relationships.
  • Tracking changing business needs.
  • Creating the service catalog.
  • Defining OLAs.
  • Defining UCs.
  • Defining SLAs.

Table 9. Activities and Considerations for Service Level Management

Activities

Considerations

Manage business relationships

Key questions:

  • Which key topics and performance metrics should be reported? (Examples might include reliability metrics, financial reporting, business value reporting, or new enhancements introduced.)
  • How often should reports be generated? Can reports be online? How can IT ensure that the organization is viewing the reports?
  • How often should formal meetings and reviews occur?
  • How should urgent issues be communicated?
  • Which service failures require attention from the organization?

Inputs:

Outputs:

  • Results of Service Alignment Management Review
  • Communication to the business

Best practice:

  • Assign an account manager—an individual responsible for structuring communication, managing requirements, escalating issues, and ensuring that the organization’s ongoing needs are met. If the organization is large, consider assigning a resource to each of the various business units.

Track changing business needs

Key questions:

  • How will the business keep IT informed of changes to organizational strategy, plans, and regulatory requirements?
  • How should the organization request new enhancements to services?

Inputs:

  • Change management process for business requirements (see Change and Configuration SMF for more information)
  • Updates to governance and policy requirements (see Policy SMF for more information)

Output:

  • Business change requests
  • Best Practices:
  • Keep track of rhythm of the business activities to monitor and understand increased or decrease in demand or reliability.   For example, during a holiday season, a retailer’s systems may see additional load. 

Create service catalog

Key questions:

  • Who is the target audience for the catalog? Should the catalog be created solely for end users and internal business customers, or should it also present IT services that are used by other IT groups (for example, those who need new servers, server consolidation, or security reviews)?
  • What IT services do end users/customers need to support their job functions?
  • Which views into the catalog can be shared by everyone in the organization? Which are unique to a given end-user/customer segment? Is there a financial application applicable only to the finance department? Is there a desktop service that is available to the entire organization?
  • What IT service does the organization consider essential? What do they call those services? (Examples might include new computer setups, virus removal, password resets, archiving financial reporting data, fixing an application’s logon problems, business policy implementation, and identity management.)
  • What attributes should the catalog contain? (Examples might include business service supported, service owner, service description, support policy, charging model, and/or planned service updates.) For an example of a service catalog, see Appendix A: “Sample Desktop Service Catalog Entry for Woodgrove Bank” at the end of this document.

Inputs:

  • Production services as identified in the portfolio
  • Service maps
  • Views needed by end users that describe the services they can order
  • Service request records  (see Customer Service SMF for more information)
  • Views needed by IT that describe IT-dependent services, such as server provisioning, backup, software updates, and patching
  • Views needed by business unit and IT executives that present a broad, aggregated look at the IT services defined within the catalog

Output:

  • Service catalog structure that supports clear communication and offerings from IT to business and from IT to IT

Best practices:

  • Treat the service catalog as a corporate business decision that drives a new model and standard for delivering IT services to the internal business community.
  • Ensure that representatives from the end-user and business unit communities drive the requirements process for catalog structure, content, and overall usability.
  • Let users know that the service catalog will expand over time as new service offerings become available, packaging and bundling of existing services changes, and IT’s understanding of users’ needs improves.
  • Offer a set of basic fulfillment services that reaches the broadest group of users, and build additional capabilities from there. Good services to pilot in the catalog include password reset, mobile phone connectivity, and PC acquisition.
  • Organize catalog services by internal IT service, end-user service, and business service.
  • Link the catalog to the service request system.

Define OLAs

Key questions:

  • Is there a service map that defines all of the dependent services and their relationship to the business services identified in the service catalog?
  • Which critical dependent services need OLAs to ensure that SLAs can be met? Which of these dependent services form the core infrastructure that supports all business services? Examples might include Microsoft Active Directory® and Network Services.
  • Who are the owners of these dependent services?

Inputs:

  • Service maps
  • Existing SLAs

Output:

  • OLAs

Best practices:

  • OLA discussions should focus on the shared responsibility everyone in IT has for delivering high-quality, cost-justifiable services to help meet the organization’s targets and objectives. At first, it may make sense to limit the number of OLAs to the three or four that are most critical to the core infrastructure. Three that are always likely to be high on the list are:
    • The Active Directory team
    • The Security team
    • The Network team (This may involve multiple OLAs due to the breadth of services most network teams deliver—for example, DNS, DHCP, LAN, and WAN.)

Define UCs

Key questions:

  • Does the organization have legal representation and governance guidelines to define and finalize the UCs? How can the representation be involved early so that legal requirements are part of initial conversations with the partner?
  • Are there other departments (such as production or finance) that have similar contracts with partners? How can IT benefit from their experience?
  • How will contract performance be measured and reported?
  • What are the communication expectations between the partner and the organization?
  • Who are the primary contacts for the partner and for the organization? In the event of an incident, what is the escalation path?
  • Who needs to be involved in defining the following elements that are key to the UCs? Which of these elements should be part of the contract and which should be background?
  • Introduction
    • Service description
    • Service hours
    • Availability and reliability
    • Support routes
    • Transaction response times
    • Throughput
    • Change management expectations
    • Incident management: record, track, resources, and closure
    • Problem management: record, document, resources, and closure
    • Expectations on partner participation in problem management meetings and CAB meetings
    • Statement of work or project charter expectations
    • Release and testing procedures
    • Project management methodology expectations
    • Tool requirements or restrictions
    • IT service continuity and security
    • Charging
    • Service reporting and reviewing
    • Performance incentives, rates, and penalties
    • Contractual obligations, termination clauses, and litigation approaches
    • Non-disclosure requirements and agreements
    • Audit rights
    • Other protection requirements as mandated by corporate legal departments (indemnification clauses, penalties for non-performance, and so on)

Inputs:

  • SLA
  • OLA
  • Preferred partner list

Output:

  • Underpinning contract (UC)

Best practices:

  • An important component of a UC (as with an SLA or OLA) is a definition of success and how to measure it. Example criteria might include:
    • Percentage of systems that successfully completed the upgrade policy without fail.
    • Number of problems and known errors.
    • Upgrade duration.
    • Notification times.
    • Availability hours.

Define SLAs

Key questions:

  • Does the service have an exact specification? Have the service targets (such as availability, capacity, and service hours) been agreed to?
  • How will the service reports be communicated? For more information about service reports, see the MOF Service Health Review.
  • Have you identified the dependent OLA and UCs tied to each SLA? Who are their owners?
  • How will the SLA be published? Will it be tied to the service catalog? How will you know people are referencing it and using it?
  • How will you measure the performance of the SLA? How will you ensure that steps are taken to improve performance? Will there be periodic reviews?
  • Who owns the SLA from IT and who owns the SLA from the business?
  • How will you structure the SLAs? Will they be organized by service, by customer, or by dependent services?

Inputs:

  • OLA
  • UCs
  • Service catalog

Outputs:

  • SLA with the following items:
    • Contact information for both parties
    • Service description
    • SLA duration
    • IT roles and responsibilities
    • Service hours and exceptions
    • Availability targets
    • Reliability targets
    • The complaint process
    • Metrics:
    • Change process information that addresses the following questions:
    • How will changes to the SLA be handled?
    • How much notice is given?
    • Who is notified?
    • Who can approve?
    • Who can request?
    • Outage information that addresses the following questions:
    • How are outages handled?
    • What is the expected recovery time by severity?
    • How does escalation occur, and who can escalate?

Best practices:

  • Ensure that your core infrastructure services such as networking, operating systems, databases, and communication and collaboration tools are designed and managed to support the business SLAs. At the same time, when adjusting or creating new SLAs, do not commit to service levels that cannot be supported by current infrastructure capabilities.  

  • Ensure that the SLAs are written from a business perspective. Example: Use business metrics to define compliance, in addition to IT metrics. A real-time inventory system would be described perhaps by “accuracy of inventory on hand” and “availability of real-time inventory reports” as well as server availability.

  • Evaluate the SLA measures using the following criteria:

    • Do they support the business objectives?
    • Are they specific?
    • Can they be measured?
    • Are they attainable, even if this requires significant effort on the part of IT?
    • Are they realistic in relation to the benefit they will bring to the business?

    For a sample service level agreement, see Appendix B: “Sample SLA,” at the end of this guide.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.
Download

Get the Microsoft Operations Framework 4.0
Solution Accelerators Notifications

Sign up to learn about updates and new releases
Feedback

Send us your comments or suggestions