Service Management Processes

Introduction

Introduction

The service management system is a system, comprised of processes, tools, and technologies working together to fulfill the goals and objectives of the service management plan and meet the demands of the customer.

The foundation of operating a service management system effectively is the measuring, control, and management of service management processes as defined by the ISO/IEC 20000 standard.

ISO/IEC 20000 Processes

Service Owner vs. Process Owner

A service owner is accountable for the delivery of a specific IT service and is responsible for continual improvement and management of change affecting services under their care.

A process owner is responsible for ensuring that the process is fit for the desired purpose and is accountable for the outputs of that process.

Service Delivery Processes

Service Level Management Service Reporting Capacity Management Service Continuity and Availability

Management Information Security Management Budgeting and Accounting of Service

6

6.1 Service Level Management

Objective:

To define, agree, record, and manage levels of service

Service Catalog

A catalog of services for each customer, showing dependencies between services and service components.

Agreements – SLAs, OLAs, UCs

Several agreements exist in a service environment:

– Service Level Agreement – an agreement between customer and service provider

– Operational Level Agreement – an agreement between one group of the service provider and another group of the service provider

– Underpinning Contracts – an agreement between the service provider and a supplier

Content of SLAs

Service Level Agreements should contain the following information, at minimum:

9

• Service description

• Service hours

• Communication: reports, schedule and frequency

• Guidelines for determining impact and priority

• Service targets

• Interruptions to services (agreed and scheduled)

• Escalation and notification process(es)

• Complaints procedure

• Workload limits (upper and lower)

• Actions or processes taken for unplanned service interruptions

• Service period (dates agreement is valid or can be changed)

• Responsibilities of customer

• Liabilities and obligations of service provider

• Financial information (i.e. charge codes)

• Change approvals

• Glossary of terms

• Related services

• Service exceptions

Service Reviews

Service and Service Level Agreements are reviewed with customer at planned intervals

Service Targets and Monitoring

Monitoring for trends and performance Identifying causes of nonconformities Identifying opportunities for improvement

Services From Other Parties

The service level management process is responsible for:

– Making agreements with customers and internal groups

– Monitoring performance against agreed service targets

– Identifying the causes of nonconformities and opportunities for improvement

13

6.2 Service Reporting

Objective: To produce agreed, timely, reliable, accurate reports for informed decision making and effective communication

14

Service reports shall be produced using information from service delivery, service management system activities, and service management processes.

Management decisions and corrective actions shall take into consideration the findings in the service reports and shall be communicated to relevant parties.

The success of the Service Management processes are dependent on the use of the information provided in service reports.

Service Reporting

15

6.3 Service Continuity and Availability Management

Objective:

To ensure that agreed service continuity and availability

commitments to customers can be met in all circumstances

Continuity and Availability Requirements

Service Continuity and Availability requirements must include (at minimum):

– Access rights to services– Service response times– End-to-end availability of services

Service Continuity Plan(s)

Service provider shall create, implement, and maintain a service continuity plan(s), which includes:

– Procedures to implement in event of major loss of service

– Availability targets– Recovery requirements– Approach for returning to normal working

conditions

Availability Plan(s)

Availability Plans must include:Availability requirementsAvailability targets

Monitoring and Testing

Service provider must ensure:– Service availability is monitored– Unplanned service outages are investigated– Plans are tested, and retested after major

changes– Test results are recorded and reviewed

20

6.4 Budgeting and Accounting

Objective: To budget and account for the cost of service provision

Budgeting and Accounting

All accounting practices used should be aligned to the wider accountancy practices of the whole of the service provider’s organization.

Policy– What objectives need to be met? What cost types? How to

apportion overheads? What rules are there to handle variances?

Budgeting– Consider seasonal factors, planned changes, variances

Accounting– Track costs to an agreed level of detail– Decisions based on cost effectiveness comparisons– Show the cost of service provision– Accounts should demonstrate over and under-spending

22

6.5 Capacity Management

Objective:To ensure that the service provider has, at all times,

sufficient capacity to meet the current and future agreed demands of the customer’s business needs

23

Capacity management shall produce, implement and maintain a capacity plan.

Capacity Management Plan

24

6.6 Information Security Management

Objective: To manage information security effectively within all service activities

25

• Create Security Policies with management approval and communicate to all relevant parties.

• Implement the controls (and document them).

• Assess impact on security controls BEFORE changes are implemented.

• Access rights (particularly for external parties).

• Investigate security incidents.

• Actions for improvement of this process

Information Security Management

Evaluating Impact on Security

Operational activities related to changes and incidents can have an unintentional impact on information security.

Information security should be a key evaluation point for assessing the appropriateness of any request for change, workaround, or resolution.

All requests for changes must be assessed to identify the risks, or changes to risks, to information security and impact on security policies and controls

The types, volumes, and impact of security incidents should be analyzed regularly to determine any opportunities for improvement.

Relationship Processes

Supplier

ServiceProvider

(The IT Organization going for ISO/IEC 20000 certification)

Business

SupplierManagement

Business RelationshipManagement

7.2 Business Relationship Management

Objective:To establish and maintain a good relationship between the

service provider and the customer based on understanding the customer and their business drivers

There shall be a

complaints process.

Business Relationship Management

29

There shall be a communication mechanism.

7.3 Supplier Management

Objective:To manage suppliers to ensure the provision of seamless, quality services

30

ISO/IEC 20000 does NOT include procurement of suppliers

Supplier Relationship Management

Part 1:There shall be a named contract manager responsible for each supplier.All service and communication processes shall be documented.All interfaces between processes shall be documented and agreed.

32

Supplier Relationship

Service Provider

)

Business

Service Provider going for ISO/IEC 20000 audit can be internal or external

SUBCONTRACTED SUPPLIER 4

LEAD SUPPLIER 1

LEAD SUPPLIER 2

LEAD SUPPLIER 3

Does the Lead supplier provider have processes to meet contractual requirements?

Does the service provider have full management control over all Service Management processes?

Resolution Processes

Incident and Service Request Management Problem Management

34

Background

Reminder:Priority is based on URGENCY and IMPACT.

Workarounds:Problem Management should develop workarounds. Incident Management should use workarounds.This data is stored in a knowledge database.

Incident Management and Problem Management are 2 SEPARATE processes!

8.1 Incident and Service Request Management

Objective: To restore agreed service to the business as soon as possible, or to respond to service requests

Incident and Service Request Management

Part 1:

• Procedures to manage ALL incidents and service requests shall be written and adopted.

• IMPACT and URGENCY shall be used to determine priority.

• Customer shall be kept informed.• All staff shall have access to relevant information,

including CMDB, known errors, problem resolutions, etc.• Progress shall be communicated to customers.• There shall be a separate process for major incidents.

Major and Security Incidents

Major and Security Incidents will often have a higher impact to the organization and required greater attention than provided by the normal procedure for incident management.

ISO/IEC 20000 requires a separate procedure for handling major incidents. The standard incident management procedure is used for security incidents but requires a priority appropriate to the risk involved.

What defines a major incident must be agreed between customer and service provider and documented. Based on the risk involved, security incidents could fall into the definition of a major incident.

Escalation

Escalation of incidents and service requests can take the form of:Functional escalationHierarchical escalation

Functional escalation is performed by the Service Desk or second-level support as part of the procedure for handling the incident or service request.

Hierarchical escalation is performed when the procedure for handling the incident or service request breaks down and requires the attention of management.

Major incidents will generally require both functional and hierarchical escalation because of the nature of the incident.

8.3 Problem Management

Objective:To minimize disruption to the business by proactive identification and analysis of the cause of incidents and by managing problems to closure.

Main focus of Part 1: Documented procedures for managing problems must

be established. Have procedures to identify, minimize, or avoid the

impact of incidents and problems Problem Management shall have a preventative

component. When changes are required pass on to Change

Management. Monitor, review, and report Problem Resolution. Keep up-to-date information on known errors available to

incident management.

Problem Management

Proactive Problem Management

Proactive Problem Management involve activities designed to seek out and resolve potential problems within the service management system and the delivered services.

The activities include analyzing data and trends on incidents and problems to identify root causes and apply preventive measures to the environment.

Trend analysis is a practice of identifying patterns within existing information which may be used to predict future behavior.

Problem Reviews

Problems reviews enable:– Improvements to problem management process,

SMS, services or other service management processes

– Prevention of a particular problem – Awareness and training related to human errors – Identifying responsible parties

Major problem reviews are performed for problems which are unresolved, unusual, or can have a significant impact to the SMS or services.

Known Errors

Known errors can come from a variety of sources, including:

– Error messages in commercial applications and systems

– Errors identified during development and testing and allowed into the production environment

– Investigations of incidents and problems

Known errors must be documented and made available to persons involved in incident management. Every known error must have a workaround or resolution associated with it.

Control Processes

Configuration Management Change Management Release and Deployment Management

9.1 Configuration Management

Objective:To define and control the components of the service andInfrastructure, and maintain accurate configuration information

Configuration Management

Part 1:• Definitions for each type of configuration item shall be

established along with appropriate procedures.• Configuration items shall be uniquely identified in

CMDB.• CMDB shall be audited at planned intervals.• CI information available to change management • Changes to CIs traceable in CMDB

Part 1 (cont’d.)• Configuration control shall ensure integrity of services

and service components.• A baseline of the appropriate configuration items

shall be taken before a release into the live environment.

• Master copies of digital configuration items shall be controlled in secure physical or electronic libraries and referenced to the configuration records, e.g. software, testing products, support documents.

• Define the interface to financial asset accounting.

Configuration Management – Shall

9.2 Change Management

Objective:To ensure all changes are assessed, approved, implemented, and reviewed in a controlled manner

Change Management Policy

The Change Management Policy defines:What configuration items are controlled by the change management processThe criteria for determining major impact of changes to services or the customer

Requests for Change

Part 1 of standard requires:– A documented procedure for recording,

classifying, assessing, and approving requests for change

– Requests for change must be raised for all changes to a service or service component

– Requests for change must have a defined scope

Change Management – Review

Has the planning been met? Has the impact been correctly estimated? Has the usage of resources been correctly estimated? Has the right effect of the change been reached? Are the users satisfied with the result? Number of incidents on the change Were/are there unexpected side effects? Have detected anomalies been communicated to the

CAB for future changes?

Change Schedule

A change schedule:– Contains details of approved changes and their

deployment dates– Used to communicate changes to interested

parties– Used in planning deployment of changes and

releases

9.3 Release Management

Objective:To deliver, distribute, and track one or more changes in a release into the live environment

Release Management

Part 1:

• Policy shall state the frequency and type.• Deployment of new or changed services and service

components shall be planned, including reversals and remedies due to failure.

• Emergency release shall be defined.• Releases shall be tested before deployment.• Acceptance criteria is established.• The process shall include reversal and remedies.• Integrity of hardware and software is maintained.• Measure success and failure.

The Toolkit

The Toolkit is designed to be holistic and comprehensive to ISO/IEC 20000. The parts of the standard provide guidance on what to implement, not how to implement the standard: where the standard lacks in this area, the toolkit will attempt to complete.

The goal of the ISO/IEC 20000 Toolkit is to define the contributing factors, major components, and their relationships as defined by the ISO/IEC 20000 , while providing the basic tools to take action based on the organization’s needs.

Moving Forward

The presentations found within the Toolkit provide education about the different facets of ISO/IEC 20000: they can be used for self-edification or as the foundation for presenting a case to different levels of the organization.

The process document, Developing Service Management Processes, is intended to be a step by step guide in developing the processes required in your organization based on the ISO/IEC 20000 standard. Multiple templates have been created to support the process and aid organizations in their efforts to improve their capabilities.