lesson-8-service-design-processes-part-1.pdf

/d/>&/d^D

Lesson 8 Study Guide ^WW

The ITIL Foundation Certificate in IT Service Management

www.itiltrainingzone.com

Page 1 of 23 2011 IT Training Zone LTD www.ITILTrainingZone.com

ITIL is a registered trademark of the Office of Government Commerce in the United Kingdom and other countries

Welcome to the eighth chapter of your Study Guide. This document is supplementary to the information available to you online, and should be used in conjunction with the videos, quizzes and exercises.

After your subscription to the course has finished online, you will still have the Study Guide to help you prepare for your exam - if youve not taken the exam by the time your subscription expires.

Youll download a Study Guide at the end of most Lessons as you progress through the course.

This Chapter contains the Study Guide information for Lesson 8 Service Design Processes: Part 1.

Use this Study Guide in conjunction with your own notes that you make as you progress through the course. You may prefer to print the Study Guides out, or use them on-screen.

After each Lesson, you can consolidate what you have learnt whilst watching the videos and taking the quizzes by reading through the chapter of the Study Guide.

If you progress on to the formal exam, your Study Guide will provide you with vital revision information.

Remember, your Study Guide is yours to keep, even after your subscription to the course has finished.

Service Design Processes Part 1





Study Guide Icons 3

Lesson Contents 4

Service Level Management 5

Service Level Management Key Concepts 7

Exercise Service Level Agreements 7

Service Level Agreement Structures 10

Service Level Management Activities 12

Service Catalogue Management 15

Availability Management 19

Availability Measures 21

Vital Business Functions 23

Table of Contents





Watch out for these icons as you use your Study Guide. Each icon highlights an important piece of information.

Tip this will remind you of something you need to take note of, or give you some exam guidance.

Definition key concept or term that you need to understand and remember.

Role a job title or responsibility associated with a process or function.

Exercise Solution suggested solution to one of the exercises you will complete throughout the course.

Goal or Objective for a particular process or core volume.

Study Guide Icons





This Lesson is the first of two studying Service Design processes.

We studied:

Service Level Management Service Catalogue Management Availability Management

Text in "italics and quotation marks" is drawn from the ITIL core volumes Quoted ITIL text is from Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement Crown copyright 2011 Reproduced under license from OGC.

Lesson Contents





Service Level Management is responsible for defining the service targets that are used to measure value.

The targets are documented in Service Level Agreements, which are defined and measured by Service Level Management.

Process Purpose and Objectives

The Service Level Management process purpose is to make sure that all current and planned services are delivered to agreed, achievable targets.

To do this, Service Level Management will negotiate, agree, monitor, report and review IT service targets and achievements. They will also take corrective action when targets are not achieved, and initiate improvements to services.

The objectives of Service Level Management include these areas:

Managing the agreement and review of targets Working with Business Relationship Management to improve the customer

relationship Make sure all IT services have targets in place Monitoring and trying to improve customer satisfaction Making sure IT and the customer have a clear and unambiguous understanding of

the level of service to be delivered Cost effectively improving service performance

Service Level Management





Process Scope

The scope of Service Level Management is to be a path for communication between IT and the business.

Although the Service Level Management roles are often part of the IT organization structure, the process needs to be neutral and shouldnt be seen as favoring one side or the other.

Service Level Management includes current and future services, making sure that customer expectations are realistic.

For new services, Service Level Management will produce a set of agreed Service Level Requirements. These document what the customer wants, and are signed off so that everyone understands what has been agreed.

Service Level Requirements make sure all services and service components are aligned with business needs.

Every IT service should have targets documented as part of their Service Design. Service Level Management has a major role to play during Service Design when targets are agreed.

The process is also responsible for providing ongoing measurement and reporting once the service is live and operational.

As well as agreeing targets for new services, Service Level Management needs to make sure that existing services wont be affected. A new service might mean another service starts to perform poorly, so this needs to be understood and managed.

Although Service Level Management carries out a lot of work within Service Design, it also has an ongoing role through the rest of the lifecycle. Part of its role is to monitor and measures live services and provide reports to stakeholders and customers.

Its also worth considering what is NOT in scope for Service Level Management. This includes:

Agreeing detailed functionality requirements for a new service Carrying out technical activities to make sure targets are met Negotiating supplier contracts this is done by Supplier Management

There is a close relationship between Service Level Management and Business Relationship Management, but they have different areas of scope. Remember that BRM is more focused on general customer satisfaction, and Service Level Management is more focused on specific service targets.





Service Level Agreement

The Service Level Agreement is the instrument that Service Level Management uses to document the targets they have agreed with the customer.

The agreement is between the service provider and the customer. It provides a description of the service, the actual targets and its associated reports and reporting cycle.

Service Level Agreements should be reviewed regularly (typically at least annually) to help ensure the targets are still relevant.

In order for the targets in a service level agreement to be met, we may use external suppliers or a number of different internal functions. Because we are reliant on these internal and external resources, we may also have documented agreements with these resources too.

Exercise Service Level Agreements

This Lesson included an Exercise to look at Service Level Agreements in more depth. If you didnt have time to complete the exercise during the Lesson, why not attempt it now?

Exercise

Service Level Management needs to develop templates for SLAs.

Draw up your own template. What needs to be included in the document? For example, youll need a service description.

Try and think of at least 10 things that need to be included.

Service Level Management Key Concepts





Exercise Solution

A typical Service Level Agreement will include:

Details of the service provider and customer representatives Date and validity period Service description Scope Service hours Service functionality, availability, reliability, performance, continuity and

security targets Support arrangements, contact points and escalation Processes such as change and incident management Roles and responsibilities Charging (if implemented) Reporting schedule Glossary of terms

Remember, if you found this exercise challenging or have any questions, you can email a tutor at [email protected].

Operational Level Agreements

Operational Level Agreement or OLAs are sometimes referred to as back to back agreements.

These agreements are used to manage internal resource chains. For example, incidents may be passed between a number of different support teams before they are eventually resolved.

If the SLA has a four hour fix-time, all the teams involved will carry out their role according to their own individual OLAs so that the four hour fix time is met.

Operational Level Agreements can be used to govern complex functional structures, or to bring order to an organization that has poor internal communications. If teams dont work well together, OLAs can be used to define how they should interface with each other.





Contracts

If we use an external supplier as part of the delivery mechanism for an SLA, we will document this in a contract. Contracts related to Service Level Agreements may also be referred to as underpinning contracts (UPCs or UCs).

A contract is a legal document between two commercial entities. Its important to remember that for your Foundation exam.

If a supplier fails to provide the service detailed in the contract, we may choose to invoke contractual penalties or even terminate the contract and change supplier.

Service Level Management works with other processes such as Supplier Management to ensure that the targets in contracts will enable us to meet the targets in our SLAs.

SLAs, OLAs and contracts will normally be written in different types of language.

SLAs need to be written in business language, so that the customer understands what they are signing

OLAs can be written in technical language, as they are often between different areas of the service provider

Contracts will be written in legal language, as they are between 2 separate organizations

Service Level Requirements

For Service Level Agreements to reflect business requirements, Service Level Management must collect and document the customers aims for a service. One of the earliest activities for Service Level Management is to collect the customers Service Level Requirements, or SLRs.

Collecting the customer SLRs can be a challenging process. For example, the customer may not be able to articulate what they want in technical terms. Or, they may ask for extremely high levels of service that the current infrastructure cannot provide. SLRs must be aligned to the business criticality of the service. If a service is not business critical, then the business should not be asking for extremely high levels of service.

It can be useful for the Service Level Manager to attend the SLR negotiation with a solid idea of what IT is capable of providing. This should be done in consultation with all other service management processes for example Capacity and Availability Management. From here, the Service Level Manager can then help to draft reasonable SLRs.





There are different types of SLA that can be used - depending on the nature of the service and the organization. The three SLA types are:

Service based Customer based Multi-level SLAs

The Service Level Manager has to decide which will be most appropriate for their customers needs.

Service Based Service Level Agreement

A service based SLA covers one service, and is applied to all customers of that service. For example, most companies provide an email service to all of their staff.

A service based SLA is appropriate here - because all staff will be offered the same level of service and support for email, regardless of which department they work in.

The service based SLA becomes more complex when customers have different requirements, so the Service Level Manager will need to decide if this will work in individual situations.

Service based SLAs also allow for the option of differentiated levels of service such as bronze, silver and gold. This will depend on how much the customer uses - or is willing to pay - for the service.

Customer Based Service Level Agreement

The second type of SLA is a customer based SLA. This is almost the complete opposite of a service based SLA.

The customer based SLA is for a single customer, and covers all of the services that they use.

This could be with a single department, for example Human Resources. It could cover services such as: Payroll, Training Records and the Employee directory - as well as all their other generic IT services.

Service Level Agreement Structures





Customers often prefer a customer based SLA, as it provides them with all of their service targets in a single, agreed document.

Combinations of customer and service based SLAs are possible, but the Service Level Manager will have to ensure that there is no duplication.

Multi-Level Service Level Agreement

The third type of SLA that is available to the Service Level Manager is a multi-level SLA.

Multi-level SLAs can be used to reduce complexity - but they also need to be carefully managed and should be aligned with the service catalogue.

The diagram below shows a three level Service Level Agreement.

Corporate level: covering issues relevant to every customer across the organization

Customer level: covering issues that relate to an individual business unit, regardless of which service is being used

Service level: covers service issues relevant to a particular customer group

Service Design fig. 4.7 Multi-level SLAs

Crown copyright 2011. Reproduced under license from OGC





Remember

Whichever SLA structure we adopt, SLAs must be clear, concise and unambiguous. If we cant measure a target, it must be left out of the SLA. Targets that cant be measured are meaningless.





The core activities for Service Level Management relate to managing and monitoring the agreed levels of service.

Service Level Management ensures that reports are produced on time and distributed to the correct audience.

The process will also manage any complaints or customer escalations, and conduct regular Service Review meetings with the customer.

The service level manager is responsible for owning the service relationship with the customer. They are also responsible for discussing the service level reports with them that show whether or not services have met their targets.

SLM also provides templates and various standards such as draft SLAs. They will provide input into the drafting of service level targets for new or radically changed services.

One of the reports that Service Level Management often uses is known as a SLAM chart or Service Level Agreement Monitoring Chart.

A SLAM Chart is typically color-coded so that customers can see at a glance which targets are being met and which may have been missed. They are often based around a traffic light system red for targets that have been missed, amber for targets that have come close to being missed, and green for areas that are performing within acceptable parameters.

Service Reviews

SLAM Charts and other Service Level Reports will feed into the regular Service Reviews held by Service Level Management. Service Reviews are attended by the Service Level Manager and the Customer, and are often held on a monthly basis.

This is not necessarily a fixed frequency reviews can take place weekly or maybe quarterly - depending on what is appropriate.

Service performance is always discussed at Service reviews, as well as any changes that the customer may need.

Service Level Management Activities





Service Reviews are an important forum for communication between the service provider and customer. It is important that regular communication channels are established and maintained.

Customer concerns and outputs from the Service Review will feed into the overall Service Improvement Plan or SIP. Service Level Management is responsible for instigating and managing this plan.

The service level manager is accountable for the process activities, but he or she may also have a team of staff, such as service level analysts, working for them who will be responsible for a number of key tasks.

Service Level Management will also work closely with other areas of the Service Lifecycle; such as Service Operation which provides measurement of live services, and Continual Service Improvement, which also works with the Service Improvement Plan.





The Service Catalogue is the part of the Service Portfolio which provides a view of live services. The catalogue is the part of the portfolio that is visible to customers.

Service Catalogues can be complex documents used by a number of different audiences. They should contain a view and a brief description of all live services.

Before we can document any SLAs, we really need to have a Service Catalogue in place so we can understand the actual services that we are delivering.


The purpose of Service Catalogue Management is to provide and maintain a single source of consistent information on all operational services, and those that are about to become operational.

The Service Catalogue needs to be easily available to anyone who needs it. It could, for example, be hosted on the intranet.

The process objectives include these areas:

Manage the information in the Service Catalogue Make sure the Service Catalogue is accurate Make sure the Service Catalogue is available and useful Make sure the Service Catalogue supports other service management processes

Service Catalogue Management





Service Packages

Some of the information in the Service Catalogue will include the service packages that are available to customers.

Service packages are collections of services and Service Level Agreements that customers can choose to meet their needs rather than having to pick lots and lots of individual services.

As part of its scope, Service Catalogue management will help to define these packages. The process will also make sure that service is defined.

Before a Service Catalogue can actually be released to the business, the Service Provider has to set up and populate the catalogue with relevant information.

One of the main difficulties experienced when implementing a service catalogue is answering the question - what is a service?

This question can often involve the Service Catalogue Manager getting involved in long discussions with their customers for example - about whether the network is a service, or whether the internet is a service.

The network support team, for example, might well argue that the network is an essential service. But from a customer perspective, the network would be a supporting service that they wouldnt necessarily order on its own.





Service Catalogue Structure

The structure of the Service Catalogue is also important. If its structured correctly, customers will be able to order what they need and wont be confused by too much technical information.

We studied a 2 view and a 3 view Service Catalogue.

The diagram below shows a 2 view Service Catalogue.

Service Design fig. 4.4 A 2 view service catalogue

Crown copyright 2011. Reproduced under license from OGC

The business or customer view shows the services that are relevant to customers, along with any links to business units and business processes.

The technical or supporting view shows the supporting IT services that customers would be unlikely to order on their own. The links to the customer-facing services that they support help to show how critical a supporting service is.





This diagram shows a 3 view service catalogue.

Service Design fig. 4.5 A 3 view service catalogue Crown copyright 2011. Reproduced under license from OGC

You can see that the supporting service view is still the same, but the customers are divided into wholesale and retail service catalogue views. This allows different types of customer to be shown the information that they need.

There is no right or wrong way to structure a Service Catalogue, and each organization will need to create a structure that works for them. Service Catalogues often start as a simple spreadsheet or matrix, before evolving to more complex views.





Availability Management extends right across the service lifecycle, but its most critical responsibility is during service design.

Availability management makes sure the availability requirements of the business are understood, and are designed into each new or changed service. This means that services match the business needs and are delivered cost-effectively.

The latest trends in technology and business reliance on IT mean that availability is becoming more and more important.

For example, end-users of IT services expect their services to be available for longer periods of time to suit their working patterns, as well as being made available from more places - to suit mobile, home and weekend working.

Availability management needs to consider these requirements whilst the service is being designed. Its much more expensive to change a service after it goes live.


The purpose of Availability Management is to make sure that the level of service availability delivered for an IT service meets the agreed targets or availability needs. This has to be done in a cost-effectively and timely manner. As well as current business needs, availability management needs to consider future business needs and how they may change.

As part of its objectives, Availability management will produce an availability plan that shows the current and future business needs. The availability plan is normally updated annually, and shows where investment is needed.

Availability management will also advise the business and other IT teams on any availability issues. The process will make sure availability targets are met, and help with any availability incidents or problems such as service downtime.

Availability management will also interface with Change Management and advise if changes are likely to affect availability. They will identify any possible proactive measures to improve availability, and implement them where cost-justified.

Good monitoring is essential for availability management to be effective.

Availability Management





Process Scope

The scope of availability management starts when availability requirements for an IT service are clear, and doesnt finish until a service is retired.

The process has 2 key elements:

Reactive activities that deal with operational issues such as incidents and problems

Proactive activities that plan for improvement and make sure availability is designed into services

To carry out its role effectively, availability management must understand business and IT information. They need to be aware of business requirements, and also how technology can be exploited to deliver business outcomes.

Availability management should be applied to all services, planned and live. One area that is explicitly out of scope for availability management is the restoration of service after a disaster such as a fire or flood. This falls within the remit of IT Service Continuity Management.

The availability manager will work with any customer requirements that have been fed into the service design. The role is also responsible for measuring availability and producing reports at both the service and component levels. By measuring at service and component levels, the Availability Manager will produce reports that are relevant to both customers and the technical teams within the service provider.

Customers typically want to see end-to-end measures of service availability. This could be given as a percentage. The user or customer is not necessarily interested in which actual component failed to cause the downtime only the effect on service overall.

Component availability monitoring looks at individual configuration items like servers, network links and routers. This level of monitoring is far more relevant to the service provider - as it needs to understand the real impact of any component failure on the overall service.

If a service needs to be highly available, then component resilience will be built in. This means that if a component fails, the overall service availability is not affected.

Component availability can have an impact on service availability, so its important for availability management to work at these 2 inter-connected levels. All aspects of service and component availability and unavailability need to be understood. Availability Management information is stored in the Availability Management Information System or AMIS.





Availability

Availability is defined as a service or IT component being available whenever we need it.

Modern technology can deliver services that are classed as high availability services.

Availability is normally measured during Agreed Service Time or AST. Downtime outside normal service hours will not have the same impact on the user.

It is worth remembering that the higher the availability required - then the greater the cost.

The more redundancy and duplication we use in our infrastructure, then the higher the cost involved with the service. More components are required to deliver high levels of availability.

Reliability

Reliability is how often a service becomes unavailable. The less a service breaks down, the more reliable it is.

This is often measured as the Mean Time Between Failures or MTBF.

Availability Measures





Maintainability

Maintainability is a measure of how easy it is to restore the service back to working order once it has broken down. If a service takes a week to get back up and running each time it breaks down, then this obviously wont be a satisfactory level of maintainability.

This is measured as Mean Time to Restore Service, or MTRS.

Serviceability

Serviceability means that the availability, reliability or maintainability have been contracted out to a third party - who will manage these specific levels on our behalf.





A Vital Business Function defines the critical part of a business process.

For example, an ATM dispenses cash and statements. Dispensing cash could be described as a VBF, but statements arent as essential. Resources and protection should be targeted towards critical service elements.

Its important to identify VBFs so that they can be protected, without wasting resources on less critical parts of a service.

Vital Business Functions

lesson-8-service-design-processes-part-1.pdf

Documents

Transcript of lesson-8-service-design-processes-part-1.pdf