1. Service Management Processes
Introduction

2. 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 standard.
Copyright: The Art of Service 2008

3. ISO/IEC Processes
There are thirteen processes divided into 4 high level categories. Every service delivered by the service provider will, in some manner, touch each of these processes. The largest category, Service Delivery Processes, will have the greatest impact on service delivery, because they define and fulfill the functional and technical aspects of the service. Capacity Management, Service Continuity and Availability Management, and Information Service Management are common attributes of every service; providing a consistent approach to ensuring the proper number of resources are available to meet customer expectations, ensuring those resources are available when required, and securing the service against unintentional or malicious acquisition of sensitive data owned and controlled by the customer. Service Level Management provides a structure for reaching an agreement on what the customer needs from IT services and what the service provider can reasonably provide, specifically in the process areas already managed. Service Reporting is a process for comparing the effectiveness of service delivery against any agreements defining the service. Naturally, any service delivery requires financial support to acquire and maintain the necessary resources: Budgeting and Accounting for Services provides the structure to support the financial aspects of service delivery.
Service delivery requires extensive communication and cooperation between different parties: from making agreements to providing status, to making decisions to providing feedback, from governing processes to demonstrating effective delivery. Aside from the service provider, two groups must be actively involved in the delivery of services – the customer and the supplier. Business Relationship Management and Supplier Management defines and operates the communication structures between the service provider and both parties respectively.
Additionally, any service which remains stagnant will eventually lose its value to the customer and the service provider. As customer requirements change, new technologies emerge, or industry and governmental expectations evolve, the services delivered to the customer must change. The Control Process work together to managing changes appropriately. Configuration management provides the structure for identifying and managing service components which are and must be controllable. Change Management is an active process for handling all changes to the environment, providing policies and guidelines to ensure every change is successful and minimizes the impact on the customer and/or service provider environment. Release and deployment management handles major changes to a services, such as adding or removing service functionality or modifying that functionality or how it is delivered.
The final set of processes, Resolution Processes, address two processes which are most seen by the end-user and technicians: Incident and Service Request Management and Problem Management. Both process work together to ensure end-users have the functionality required by their role or purpose and will handle any situations which prevent the user from accessing that functionality. Incident and Service Request Management is primarily a Service Desk process and is initiated when an end-user contacts the service provider. Problem Management provides an approach to investigate and resolve any problems which are impacting the desired delivery of a service.

4. 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.
Before moving forward, some delineation must be made between services and processes, specifically the roles of service owner and process owner. As mentioned before, every service management process will, to some extent, play a part in ensuring the delivery of a service. This extent is largely based on the interpretation of service requirements and what technical and resource capabilities the service provider has. When multiple services are being delivered, these technical and resources capabilities must be adequately allocated to meet the individual service demands.
Ownership means accountability. The service owner is accountable to the service, the process owner is accountable to the process. Specifically,
READ SLIDE
Cooperation between service and process owners increases the effectiveness of the service management system in managing the delivery of services to the customer. 4 4

5. 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
This process encourages the service provider and the customer to develop a proactive attitude towards joint responsibility for the service.
Service Levels define what must be delivered, when it must be delivered, and the minimum thresholds for the delivered service. For instance, a service may represent the technical support required for an application operating in the customer environment. Supporting the applications is what is required of the service. Since the application is only used during local business hours from specified and secure customer locations, the service is only available at specific times and locations. However when available, the application may be used by 85% of the company’s employees concurrently; which requires adequate capacity and availability mechanisms in place to ensure this happens. The importance of the application to the customer may require that very little tolerance is present should end-users fail to access the application (service).
Service Level Management is responsible for negotiating the obligations of the service provider in delivering the service, the roles and responsibilities of the customer to cooperate, and the measurements for evaluating effectiveness. The process is also responsible for communicating those terms and periodically evaluating service performance against those terms, using service reports.
Customer satisfaction is an important part of service level management but it should be recognized as being a subjective measurement, whereas service targets within the SLA should be objective measurements. The SLM process works closely with the business relationship and supplier management processes.

7. Service Catalog
A catalog of services for each customer, showing dependencies between services and service components.
A service customer must maintain a list of services they have agreed to deliver to the customer. Each customer will have a different service catalog, though the contents may be similar between multiple customers sharing the same services.
A service found in the service catalogue should be define, often in a consistent manner with other services to ensure greater readability to the all parties. While the service definition may include much information about the service, the ISO/IEC requires, at minimum, that the dependencies between services and service components are documented.
Consider are previous example of an business application being supported by a service. The customer’s business process requires that this application must communicate with another application, sharing information between the two applications: or maybe the second application is a data warehousing service provided by the service provider. In either situation, a dependency between the application service and the second service which naturally exists because of the business process. A dependency can be created as well: consider an application which requires a login. The service provider is providing a service to enable single sign-on capabilities for the business environment: this means that the application login is controlled and initiated from outside of the application automatically using a name and password for every application service.
Service components are the physical and logical building blocks of the service. In the application service, the basic components are the application, the application server, the end-user interface/client, storage resources, and network resources, at minimum. A failure in any of these components will result in a failure in the service. Understanding the relationships between the service and service components will aid the service provider in evaluating the urgency and priority of an incident, change, or problem relative to individual service components based on service level agreements. For instance, since the application has limited availability, it would be best to make any changes to the application or service when it is not required to be available. If the application is required at all times, then the change is best made when the demand on the service is at its lowest point.
While the service catalog may not provide the details necessary to make every decision, by establishing these relationships and even pointing to the details, the service catalog provides a central repository for understanding the different facets of the delivered services.
Copyright: The Art of Service 2008

8. 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
The three types of agreements mentioned comprise the majority of agreements made with the service provider. The Service Level Management process is primarily concerned with the Service Level Agreement which defines what the service provider will deliver to the customer.
However at times, the service provider will need to depend on another party to deliver all or part of service. Remember that another party may be a customer, an internal group, or a supplier. This is where the other agreement types come into play. It is unlikely, and unwise, for the service provider to have two separate agreements with the customer when the customer is responsible for delivering part of a service. When this situation occurs, the customer’s responsibilities should be part of the original Service Level Agreement. This prevents any ambiguity or conflict which may result when two different agreements are in place.
Operational Level Agreements (OLAs) and Underpinning Contracts (UCs) are made with internal groups and suppliers respectively and are based on the service level agreements agreed by the customer. Service Level Management will typically take responsible for creating and managing OLAs, while underpinning contracts are the responsibility of the supplier management process.
All agreements are based on service requirements. A service requirement will typically define the functionality and reliability of the service: i.e. a service must ensure the application is available 99.5% of the time during defined business hours. ISO/IEC requires that SLAs contain agreed service targets, workload characteristics, and exceptions to service delivery. The service level agreement defines the service in a document agreed by the customer. An individual service may have one or more service level agreements. A service level agreement document may contain one or more service level agreements.
Copyright: The Art of Service 2008

9. Content of SLAs
Service Level Agreements should contain the following information, at minimum:
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
A typical service level agreement will contain the information shown here.

10. Service Reviews
Service and Service Level Agreements are reviewed with customer at planned intervals
Service reviews give service providers and customers an opportunity to evaluate the performance of the service and the effectiveness of the service provider in meting the requirements defined in the service level agreements.
The service reviews are planned; that is, they must consider intent, criticality, timing, and frequency. A typically service review may occur every month; however, this is just a rule of thumb to consider. If a service is critical, unstable, or subject to lots of changes, the frequency may be more often. New services or services with new releases may have more frequent reviews than more established services. IF a service supports a critical business process, the frequency of the service review more increase.
Conducting service reviews requires a commitment from several people within the service provider and customer organizations, a commitment which could take them away from other duties; therefore, it is necessary not to overload any single person with multiple or too frequent service reviews.
As a result of service reviews, areas of nonconformance or opportunities for improvement may be identified, which can include changes to documents service requirements, the service catalog, service level agreements, or other agreements. These changes must be managed by the change management process and be reflected appropriately in the service catalog.
Copyright: The Art of Service 2008

11. Service Targets and Monitoring
Monitoring for trends and performance
Identifying causes of nonconformities
Identifying opportunities for improvement
Outside of the service review, the service provider is expected to monitor operational trends and performance on a regular basis. This level of monitoring must be planned out with procedures for handling results. The focus of this monitoring is the service targets defined within the agreed service level agreements and provides the service provider an opportunity to proactively identify potential failures or improvements to the service.
Trends are simply patterns which indicate the behavior of the service, whether it shows increased or decreased effectiveness of service delivery or predictable variations in service performance. Monitoring is essential in identifying unknown factors on the service: for instance, service performance may show performance is impacted by a degraded server or the addition of several hundred users to a service.
Copyright: The Art of Service 2008

12. 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
Under the scope of service level management, the activities required to reach an agreement with customers and internal groups to provide a part of a service and monitor the service performance for these parts are included. For compliance with ISO/IEC 20000, a simple rule should be followed – document everything.
Copyright: The Art of Service 2008

13. 6.2 Service Reporting
Objective: To produce agreed, timely, reliable, accurate reports for informed decision making and effective communication
A clear description of each service report is required including:
Identity
Purpose
Audience
Frequency
Details of the data source
The success of all Service Management processes is dependant on the use of the information provided in service reports. It is important that service reports are sufficiently accurate to be used as a decision support tool amongst all processes.

14. Service Reporting
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.
READ SLIDE
A description of the service report must be documented and agreed by all stakeholders of the service. They can be produced from any service component, service management tool, or process used to support the service. Service reports are created for each service, typically reflecting each agreed service target; but may be expanded to measure aspects of service performance outside the requirements defined in the SLA.
Service reports are used to make decisions and take actions relevant to the successful delivery of services. Any action taken must be communicated to the proper stakeholders.

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
Read slide
The ISO/IEC process is comprised of two related efforts:
Service Continuity
Availability
Service Continuity speaks to ensuring the services remain operational in the event of a “catastrophic” event. The most obvious catastrophic events may be natural disasters, but can also include malicious or terror attacks, power outages or “brownouts," or a major incident.
Availability focuses on maintaining the availability of services during a typical workday and deals with varied demands, both predictable and unpredictable, on the service.

16. 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 and availability requirements are identified by the service provider and agree with the customer and interested parties. These requirements must take into consideration the relevant business plans, service requirements, service level agreements, and risks associated with each service.
Often, the service provider and customer will agree to limited services when an catastrophic event occurs; similar in analogy to emergency lighting in the event of a power outage. Therefore, the expected service levels may be different for service continuity and daily availability to services. While the requirements may differ based on the situation, the requirements must be consistent: if there are requirements for access to a system within daily operations, similar requirements should be in place for service continuity plans.
End-to-end availability refers to the service provider’s consideration of every service component and risks to those components related to the service and maintaining the availability of that service. Risk management, though not a formal process of ISO/IEC 20000, is alluded to in this process; specifically requiring the service provider to assess and document all risks to service continuity and availability.
Copyright: The Art of Service 2008

17. 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
Continuity planning is extensive and sometimes complex. Sometimes, it is necessary to have different plans to address different categories of service loss, from disaster to power loss. Continuity planning will typically distinguish between the terms “response," “recover," and “restore." Response addresses the immediate actions expected to invoke the plan and assess the impact of the event. Response is often investigative in nature and seeks to understand different aspects of the event, including cause, scope, and damage. Investigations may take a few minutes or several day depending on the event.
Recovery can often begin before response activities are complete as long as it does not impede the investigation. Recovery activities focus on making sure service availability is returned. The time required greatly depends on the situation and the business requirements on service continuity. High performance solutions such as hot sites will allow the service provider to simply “hit a switch” to allow services to be rerouted though an alternative pathway: however, this type of solution will usually require a duplicate and operational data center to be maintained offsite. Slower recovery approaches may require bringing in replacement components.
Restoration speaks to the service provider making an effort to return the customer to its original state, before the event. While this can be accomplished in most invocations of service continuity plans, some situations are too devastating or cost prohibited to return to an original state and the customer must make a decision with the service provider to determine the best course of action. In theory though, effective continuity planning could address even the most bizarre of circumstances; but will typically focus on working through the identified risks to service continuity.
One major consideration for all service continuity plans should be the situation when physical and/or logical access to service locations is not possible: as in the case of most natural disasters. In this situations, ISO/IEC requires that access to the service continuity plan(s), contact lists and the CMDB be accessible. This requirement can be fulfilled by storing this information off-site at another location.
Changes to service continuity plans must be managed through the change management process. All requests for change must be assessed for their impact on service continuity plans.
Copyright: The Art of Service 2008

18. Availability Plan(s) Availability Plans must include:
Availability requirements
Availability targets
Availability planning may not be as extensive as continuity planning; however, the results will often provide additional considerations for both. ISO/IEC 2000 even recognizes the fact that a service continuity plan and an availability plan may be contained in a single document. The availability requirements and targets of a service will often be defined and agreed in service level agreements.
Changes to availability plans must be managed through the change management process. All requests for change must be assess for their impact on availability plans.
Copyright: The Art of Service 2008

19. 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
The requirements regarding monitoring of availability and testing of service continuity and availability plans are straight-forward. Services are to be monitored. The results of this monitoring must be recorded and compared against targets agreed within the service level agreements. If a service becomes unavailability without cause, that cause must be investigated and actions taken to correct and/or prevent reoccurrence: these actions are often performed as part of incident and problem management.
Plans should be tested against their respective requirements. While the standard does not stipulate regular testing, it does explicitly mention testing after any major change to the service environment operated by the service provider. The results of the tests must be recorded. A review of the service continuity plan must be conducted after every invocation, whether because of testing or an actual event. This review will evaluate the effectiveness of the plan and identify any deficiencies to be addressed.
Copyright: The Art of Service 2008

20. 6.4 Budgeting and Accounting
Objective: To budget and account for the cost of service provision
This section covers budgeting and accounting for IT services. In practice, many service providers will be involved in charging for such services. However, since charging is an optional activity, it is not covered by the standard.
The shall criteria requests areas such as:
An interface between Budgeting and Accounting and other financial management processes
Defined policies and procedures for:
Budgeting and accounting for service components
Establishing a over cost for each service through apportioned indirect costs and allocated direct costs
Effective control and approval of finances
Monitor and report costs against budget, reviewing financial forecasts, and managing costs
Changes shall be costed/approved via Change Management
Service components to be budgeted and accounted by the service provider must include:
Service assets
Licenses
Shared resources
Overhead costs
Capital and operating expenses
Externally supplied services
Personnel
Facilities
The costs of a service must be budgeted to ensure effective control of finances and facilitate better decision making
Service providers are recommended that where charging is in use, the mechanism for doing so is fully defined and understood by all parties. All accounting practices in use should be aligned to the wider accountancy practices of the service provider’s organization.

21. 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
READ SLIDE
Please note that this list is not exhaustive. There are more points mentioned in the standard, but these points are at the top of the list of good practice. For more best practices refer to section 6.4 of ISO/IEC

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
READ SLIDE

23. Capacity Management Plan
Capacity management shall produce, implement and maintain a capacity plan.
The main activities in the capacity management process are monitoring, tuning and providing capacity. Part 1 of ISO/IEC explicitly requires methods, procedures and techniques to execute these activities, after producing a capacity plan.
To properly execute capacity management, the service provider must identify and agree upon the requirements for capacity and performance with the customer and any interested stakeholder of the respective service. Once identified, a capacity plan must be created to apply the appropriate number of resources to meet those requirements. Resources can be human, technical, informational, or financial.
The content of the capacity plan must address at least the following concerns:
Current and future demand for services
Expected impact of requirements for availability, service continuity, and service levels
Schedules, thresholds, and costs for capacity upgrades
Impact from changes in statutory, regulatory, or contractual requirements and organizational structures
Impact of adopting new technologies and new techniques
Documented procedures or referenced to enabling predictive analysis
The service provider must provide sufficient capacity to meet the capacity and performance requirements of the service to the customer. To ensure this at any given time, they will monitor capacity usage, analyze capacity data, and tune performance.

24. 6.6 Information Security Management
Objective:
To manage information security effectively within all service activities
READ SLIDE

25. Information Security Management
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
The mandatory requirements from part one of the standard state that the Information Security Management process shall generally:
READ SLIDE
An Information Security Policy must consider the service requirements, statutory and regulatory requirements, and contract obligations placed on the service provider.
In addition to the creation, implementation, and maintenance of the Information Security Policy, management is also accountable to:
Communicate the policy and importance for compliance to personnel within the service provider, customer, and suppliers
Established information security management objectives
Define approaches and criteria for accepting and managing risks to information security
Conduct security risk assessments at planned intervals
Conduct internal security audits
Review audit results to identify areas of improvement
The management of information security is achieved through the implementation and maintenance of security controls. Controls can be physical, administrative or technical. The purpose of these controls is to:
Preserve data and information confidentiality, integrity, and accessibility
Fulfill information security policy requirements
Meet information security management objectives
Manage security risks
All controls must be documented and associated to the risks being prevented, their expected operation and maintenance. Periodically, the service provider is required to review the effectiveness of each security control, taking and reporting action when needed.
As part of information security management, the service provider is responsible for identifying any external party who has a need to access, use, or manage information or services provided. Any controls with managing this access or use by an external organization must be documented, agreed, and implemented.
Finally, information security management has some responsibility in relation to requests for change and incidents. Every request for change must be assessed to identify potential security risks whether new or changed, and the potential impact of the change on the information management policy and controls. In relation to security incidents, the primary mechanism for managing the incident is the incident management process. Prioritization of security incidents is based on t security risk associated with the incident. The service provider is required to analyze different types of incidents based on their volume and impact. Major incidents will be assessed, reported, and reviewed for potential opportunities for improvement.

26. 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.
READ SLIDE
Information Security is an essential component in today’s technology landscape, requiring organization’s to be proactive, rather than reactive, to known and unknown threats to its IT environment. Establishing and rigorously executing work procedures ensures that security controls are maintained and unaffected during daily operations. Evaluating changes for impact on security ensures unintended changes to controls and solutions in place to strengthen the infrastructure’s security base.

27. Relationship Processes
Supplier Management
Business Relationship Management
Supplier
Service Provider
(The IT Organization
going for ISO/IEC
20000 certification)
Business
Relationship processes handle those activities specifically designed to manage the interactions between the service provider and other parties. As illustrated in the diagram here, there are two sets of interactions recognized: supplier and business. Putting this into perspective, the goal of the service provider is to provide services to the customer to fulfill their outcomes. In this context, the supplier is an outside party which is bought into to provide all of, or part of, a service; however, the contract agreement is typically with the service provider and not the customer. The Supplier Management process is used to manage suppliers in this context.
NOTE: While the standard does not explicitly define a supplier as an external party in this section, within the service level management process is does call out internal groups and customers: section 4.2 about governance recognizes internal groups, customers, and suppliers. From this perspective, a supplier is any group which does not already have a binding “contract” as an internal group (to the service provider organization) or the customer (business).
The other interaction relevant to the success of service management is with the business, or more specifically, the customer who the service provider is delivering services. The Business Relationship Management process is accountable for maintaining and building this relationship.

28. 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
READ SLIDE
Business Relationship Management is very important in the service provider’s efforts to understand the customer’s service requirements, fulfill those requirements, and retain a high level of customer satisfaction for the services delivered.

29. Business Relationship Management
Part 1 of the standard has a number of discrete requirements related to business relationship management, including:
Customers, users, and stakeholders for the services must be identified and documented.
An individual must be assigned by the service provider for each customer to manage the customer relationship and customer satisfaction (in ITIL®, this is the Business Relationship Manager, or Account Manager)
A communication mechanism must be established between the service provider and the customer to allow the service provider to understand the environment where services are delivered and the requirements of the customer.
A review of service performance must be conducted at planned intervals with the customer (usually performed as part of the service review)
Changes to documented service requirements are controlled by the change management process
Changes to SLAs are coordinated with the service level management process.
Service Complaints are defined and agreed by service provider and customers. A documented procedure for handling service complaints will be established, including how complaints are recorded, investigated, acted on, reported, escalated to customer, and closed.
Customer satisfaction will be measured from a statistical sampling of customers and users at regularly planned intervals. Results will be analyzed for potential opportunities for improvement.
There shall be a communication mechanism.
There shall be a
complaints process.

30. ISO/IEC 20000 does NOT include procurement of suppliers
7.3 Supplier Management
Objective:
To manage suppliers to ensure the provision of seamless,
quality services
READ SLIDE
Even when the service provider has no “suppliers,” the supplier management process must be developed and maintained; however, it is unlikely that any service provider cannot claim a single supplier in a world of commercially available applications, hardware, and IT services.
Supplier Management covers all the activities related to managing the relationship with the supplier except the actual procurement of a supplier: this activity is considered a business activity performed outside of the service management system. The service provider may make recommendations on procuring suppliers and may be part of the procurement process, but the process is not part of the ISO/IEC scope.
ISO/IEC does NOT include
procurement of suppliers 30

31. 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.
A supplier can be used by the service provider to provide services as a whole or in part. Multiple suppliers can be enlisted to provide different service components. Each supplier must have an individual assigned by the service provider to manage the relationship contract and performance with the supplier.
A contract between the service provider and supplier must be documented and agreed. The contents of the contract must include at least the following:
The supplier’s scope of delivered services
Dependencies between service, processes, and parties
Service requirements fulfilled by supplier
Service targets
Interfaces between service management processes for both the service provider and supplier
Integration of supplier activities with service management system
Workload characteristics
Contract exceptions and procedures for handling them
Roles and responsibilities for both service provider and supplier
Expected reports and communications from supplier
Basis for charging by supplier
Procedures and responsibilities for expected and early termination of contract and transfer of services
The SLAs set with the supplier must support and align with the SLAs set with the customer.

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
SUPPLIER 2
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?
The relationship with suppliers may be complex. In many cases, several suppliers may be in place to provide similar services, whereupon it is recommended that one supplier be identified as a lead supplier and all other suppliers sub-contract to the lead. When this type of hierarchy is in place, the service provider must understand the roles and relationships between lead supplier and sub-contracted suppliers in delivering services. The service provider must also ensure the lead supplier is properly managing their sub-contractors to ensure contract obligations are met.
The performance of the supplier will be monitored by the service provider at planned intervals. Performance is measured against service targets and other contract obligations. The results of monitoring will be recorded and reviews to identify nonconformities and opportunities for improvement.
Regular contract reviews shall be conducted to ensure relevance with current service requirements. A procedure will be established to handle contract disputes between service provider and supplier.
All changes to supplier contracts will be controlled by change management.

33. 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 two separate processes. Incident Management deals with restoring services ASAP, whereas Problem Management looks to identify the root or known cause of a problem. Priority of incidents and problems is determined by the urgency and impact.
Incident management is primarily performed by the Service Desk function, along with handling service requests. Therefore, ISO combines the two processes into Incident and Service Request Management. However, it should be noted that some incidents and service requests can be initiated at the Service Desk and resolved outside the Service Desk.
Problem Management, on the other hand, will typically be performed outside of the Service Desk and may be initiated after an incident has been resolved. For example, a service become unavailable for an hour. As part of Incident Management, a technician checks the primary server for the service and reboots it. Once the server has fully rebooted, the service is now available and the incident can be closed. However, the cause for the outage is still unknown, only that rebooting the server resolved it: without knowing the cause, it is difficult to predict if another outage will occur or when. Problem Management will now take the ball and find a cause for the outage; when found, the process will implement a permanent resolution or provide more information about handling the impact on the next occurrence.
Problems are typically seen as incidents with no resolution or workaround or recurring incidents. In either case, problem management serves to provide more information about the incident and prevent future occurrences from happening or create a faster response to the incident. An incident is any disruption in service or IT process.
Incident Management and Problem Management are 2 SEPARATE processes!

35. 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
Read slide
Incident and Service Request Management is the process most associated to supporting the end-user directly, since it is the process used, and often owned, by the Service Desk. The typical structure of a service organization will promote Service Desk capabilities in customer service, rather than technical expertise; therefore it is often necessary for the service organization to support the Service Desk by providing the technical procedures and information needed to support the majority of issues and requests that may occur. This sharing of information is facilitated by a document repository (ITIL calls it a Known Problem Database) and the configuration management database (CMDB).

36. 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.
With regard to the Incident and Service Request Management process, part 1 of the standard states that –
READ SLIDE
For incidents, the procedures must cover the activities of:
Recording
Allocating priority
Classifying
Updating records
Escalation
Resolution
Closure
The success of incident and service request management is dependent on the information provided by other service management processes, namely configuration management, problem management, and release and deployment management. Each of these process is responsible for providing information related to the various services and service components supported in the environment.
The activities of incident and service request management are bound by specific service targets, usually in the form of the time allowed to resolve an incident or request. Service provider personnel are responsible for documenting the progress of the incident or request. If service targets are to be exceeded, the service provider must inform the customer and interested stakeholders and escalate the incident of service request accordingly.
Major incidents are special events potentially resulting in high impact to the service provider and customer. In most cases, problem management and incident management will be working in conjunction: while some major incidents may require the invocation of Service Continuity plans. Top management is always informed of major incidents. Because of the effort and resources to manage and resolve major incidents, a separate procedure is required to identify all additional activities required during a major incident. Before the procedure can be written, though, the service provider and customer must agree on the definition of a major incident.

37. 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 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.
READ SLIDE
When defining a Major Incident, the customer and service provider must agree on:
Conditions and circumstances resulting in a major incident
Who can declare and the methods used to declare a major incident
Authorities and responsibilities related to coordinating and controlling major incident activities
Expectations for conducting resolution efforts, such as response, rescue, and recovery
Expected communications during and after a major incident
Details on review after resolution, including format, timing, and participants
Interfaces between incident management and service continuity and availability management

38. Escalation
Escalation of incidents and service requests can take the form of:
Functional escalation
Hierarchical 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.
READ SLIDE
The expectation of the incident and service request management process is the personnel involved will have access to information such as procedures for handling specific service requests and workarounds or resolutions related to known errors and problems. This information may indicate that the best course of action is to transfer the work to the appropriate support area: or the information is not available and the work must be transferred based on the nature of the incident or service request. In either case, this form of escalation is considered functional and is expected throughout the service provider organization.
However, there are times when expectations are missed: an SLA is missed, work is inappropriately assigned, a customer is dissatisfied – in essence, the process breaks in some fashion. At this time, the attention of management is needed, either to be aware of the situation or to facilitate the action required to right the process. Notification of management in this fashion is considered hierarchical escalation.
Handling of either type of escalation is critical to effective IT service management and must be justified, with actions related to escalation documented within the incident or service request record.

39. 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.
READ SLIDE
Problem management focuses on investigating problems, real or potential, in the IT environment and seeking a reasonable solution to solve a problem or reduce its impact on the delivered services.

40. Problem Management 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.
With regard to the Problem Management process, part 1 of the standard states the following criteria:
READ SLIDE
For problems, the procedures must cover the activities of:
Identification
Recording
Prioritization
Classification
Updating records
Escalation
Resolution
Closure
All problems are to be managed according to these documented procedures, including analyzing data and trends on incidents and problems to identify root causes and potential actions to prevent future occurrence. If the root cause is found but the problem still exists, the goal of problem management is to identify actions to reduce or eliminate the impact of the problem on the services delivered. All known errors and problem resolutions shall be documented and maintained for use in the incident and service request management process.
The effectiveness of all problem resolutions must be monitored, reviewed, and reported. Problems existing with specific configuration items may require a change, which must be resolved though the change management by initiating a request for change.

41. 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.
In the beginning of this module, a problem resulted from the inability of the service provider to resolve an incident successfully. Because this is a reaction to an event, in this case, a stubborn incident, the problem management process is considered reactive. With proactive problem management, the process takes the lead in looking at the environment and identifying root causes before they seriously impact the environment.
This monitoring of the environment will occur across all the service management processes, but the scope of problem management will usually be restricted to the analyzing current incidents and problems. Other service management processes may identify potential problems which need further investigation and initiate problem management. For instance, capacity management may see a downward trend in capabilities with no observable explanation and create a problem record to document the situation and manage to resolution. Problems may be the result of identifying single points of failure, risks, or trends in service delivery.
A key activity of proactive problem management is trend analysis. This is an approach where data is analyzed to identify any patterns of interest. A pattern can be defined clearly and often visibly mapped on a data graph: it can indicate a positive or negative influence on a process, service, or system. For instance, the service provider may see an increase of calls into the Service Desk over several days or weeks. Whether the trend is positive or negative, the service provider should make all efforts to understand the root cause: if the trend is negative, so the situation can be reversed; if the trend is positive, so the situation can be exploited or handled properly. To understand the root cause and determine the right course of action, problem management will be initiated (though some people may be resistant to label positive trends as “problems," it is a problem if the reason for the trend is unknown). Resolutions resulting from proactive problem management should be proposed though the change management process.
Proactive activities in problem management also include communicating with the customer of any knowledge gained from problem reviews to ensure the customer is aware of actions and any recommendations for improvement. Measurements for proactive problem management can be significantly different from reactive problem management and will establish the value of both activities to the service provider and customer.

42. 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.
Problem reviews are designed to identify opportunities for improvement. They are to be recorded and should occur regularly. There is no requirements to review every problem individually; some organizations may choose to focus on those categories or service areas with the highest number of problems. However, some expectation may exist to review every “major problem” individually. Because of the nature of a major problem as an unresolved, unusual, or highly impactful problem, the risks to the business, customer, and service provider should be identified and managed. The results of the major problem review should be communicated to management to make them aware of these problems and their potential impact.

43. 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.
Known errors are simply problems in the environment which are known to the service provider. Nearly every piece of software or hardware in the environment will have known errors. Most are easily identified when an error message opens. Most users will have no idea what this error message means or what to do when it happens; and the diversity of systems existing in a typical IT environment makes it unlikely any IT technician will be familiar with every error message which can potentially occur. By documenting known errors, the service provider is creating substantial information for effectively supporting the customer in any situation.
While problem management is responsible for documenting known errors and their resolutions, another process involved ensuring known errors are identified and documented is the release and deployment management process. The reason for this can be easily explained: during the development and testing of a release, errors may occur. Though problem management may be utilized to identify the root causes of these errors and apply any available resolutions, some errors may not have a permanent resolution; however, the existence of these errors does not severely impact the integrity of the release and it is deployed with these errors still in place. Problem management will likely already have the known errors and their resolutions documented, but some responsibility falls on release and deployment management to update release records with these known errors.
Unfortunately, some errors may not be identified during development, testing, and deployment of a release. In this case, an unidentified error occurs within the production environment: in short, an incident occurs. During the handling of an incident, one of the first steps in handling an incident is to compare the characteristics of the incident to known errors already documented. Remember, error messages are always known errors and the code can be used to find the appropriate documentation. But when an error message does not occur, the incident’s characteristics provide the only information. If a known error cannot be found, the person handling the incident must take the best approach based on their knowledge and experience: they may eventually resolve the incident, but still have insufficient information to state the root cause. Therefore, they will initiate problem management to investigate the unknown error. The intention is to clearly define the error and document its resolution for future use.

44. Control Processes Configuration Management Change Management
Release and Deployment Management

45. 9.1 Configuration Management
Objective:
To define and control the components of the service and
Infrastructure, and maintain accurate configuration information
Configuration information includes:
configuration items
relationships
documentation necessary for effective Service Management.
NOTE: Financial Asset Management is NOT part of the scope of this process

46. 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
With regards to the Configuration Mgmt. process, part 1 of the standard states the following criteria –
READ SLIDE
Defining the type of configuration item managed ensures control of the configuration items is effective. A definition must include the following information:
Description of the configuration item (for instance, is the configuration item hardware, software, and what is its purpose)
Relationship between the CI and other CIs (for instance, what servers is an enterprise application installed on)
Relationship between the CI and service components (what part of the business process is the CI supporting)
Status (active, under maintenance, retired, etc.)
Version (including specific versions of any updates to the configuration item)
Location (physical and/or logical)
Associated requests for change
Associated problems and known errors
Configuration Items must be uniquely identified in the configuration management database to allow for greater control, reliability, and accuracy in data. A documented procedure must be established to define how different versions of CIs will be recorded, controlled, and tracked. The level of control required is dependent on the integrity required to achieve service requirements and manage risks. Therefore, a high-risk item which is needed for a critical business process will require greater control than a similar item used sporadically in a non-critical business process.
All records within the CMDB must be audited regularly. Any deficiencies must be corrected and reported appropriately. The purpose of the audit is to maintain the integrity of the data stored in the database, which is used continually in other service management processes, particularly change management when assessing request for change impacting a managed configuration item. Changes to CIs must be traceable and auditable from the CMDB.

47. Configuration Management – Shall
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.
Before deploying a new release, a new configuration baseline is taken. This baseline provides a marker to determine the level and impact of change made by the release an allows the service provider to return the environment to its original state should the release fail. Deliverables from releases may include software images, images of hardware configurations, and support documentation used as templates for multiple configuration items. Considered master copies of their respective configuration items, these deliverables should be stored in a secure physical or electronic location and referenced by the configuration items managed in the CMDB.
While configuration management for ISO does not address financial asset management, an interface between configuration management and financial asset management must be defined.

48. 9.2 Change Management Objective:
To ensure all changes are assessed, approved, implemented, and reviewed in a controlled manner
For the change management process, the standard requires that the service provider shall report on the outcomes achieved by the new or changed service against those planned following its implementation. A post-implementation review comparing actual outcomes against those planned shall be performed through the change management process.

49. Change Management Policy
The Change Management Policy defines:
What configuration items are controlled by the change management process
The criteria for determining major impact of changes to services or the customer
The policy for change management must define what configuration items will be controlled by change management. This identification will be supported by the configuration management process: with configuration items under control listed in the configuration management database. The policy must also establish the criteria of determining the impact of a change on services or the customer, particularly major impacts which are required to use the design and transition of new or changed services process. The potential changes to services which may potentially have a major impact are called out by the standard: removal of services and transfer of services.
Copyright: The Art of Service 2008

50. 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
The service provider is required to document a procedure for recording, classifying, and approving request for change. The definition of emergency change must be defined and agreed by the customer. A separate procedure for handling emergency changes must be documented.
Once the definition of a change and all its variants are established, the standard requires that all changes to a service or service component be handled by raising a request for change. A request for change must have a defined scope, particularly identifying what services, service components, and/or service requirements are being changed. All requests for change will be recorded and classified. If a change is classified as having a major impact, the design and transition of new or changed service process will be invoked. The change management process will be used in all requests for change to configuration items defined in the change management policy.
The activities of the change management process must include the following:
An assessment of the request for change using information available to the process from other service management process.
A decision by the service provider and other stakeholders to accept the request for change. Acceptance requires interested parties have considered the potential risks and impact to services and the customer, service requirements, benefits to the business, technical feasibility, and financial impact.
Approved changes are developed and tested, including all activities related to reversing or resolving a failed change.
A request for change is scheduled appropriately on a master schedule, or change schedule. The change schedule is used as a basis for planning release deployments.
Conducting investigation into failed changes.
Updating the configuration management database.
Reviewing changes for effectiveness.
Analyzing requests for change regularly to identify trends and potential opportunities for improvement.
Copyright: The Art of Service 2008

51. 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?
Requests for change must be reviewed and, at planned intervals, analyzed for trends. Here are some of the questions asked during a change review.

52. 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
READ SLIDE
Copyright: The Art of Service 2008

53. 9.3 Release Management Objective:
To deliver, distribute, and track one or more changes in a release into the live environment
READ SLIDE

54. 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.
With regards to the Release Management process, part 1 of the standard states:
READ SLIDE
A release is a set of related changes to a service or service components. The change management process is not sufficient to manage releases through deployment, though many of the activities and requirements between the two are similar. However, change management does interface with the release and deployment management process to ensure individual changes are managed and communicated properly.
The release policy establishes the definition of a release, including what type of releases are expected and at what frequency. For instance, an in-house application suite may create an application release every six months. However, a security release for anti-virus programs may be available for installation every two weeks. Clearly defining the type and expected frequency of releases allows the service provider to plan and control releases into the environment.
Coordination of releases plans requires interfacing with several processes, including:
Design and transition of new or changed services
Change Management
Problem Management (for known errors and open problems)
Incident and Service Request Management (to provide support information)
Configuration Management
Planning requires that the dates for deploying each release, the deliverables of the release and the methods of deployment be established. Emergency releases are accepted if they fall within the criteria established to define an emergency release, which is established and agreed by the service provider and customer. A documented procedure for emergency releases must be written and interface with the emergency change procedure.
All releases must be built and tested before deploying into a live environment. A controlled test environment will be used for all building and testing of releases. The test will be against the acceptance criteria agreed by the service provider, customer, and interested stakeholders. IF a release is not verified against the acceptance criteria or approved, the service provider and stakeholders must take the necessary actions to resolve.
The deployment of a release into the live environment must maintain the integrity of the hardware, software and other service components. This means, the release cannot impact any component or service level not defined in the scope of the release. For instance, the implementation of a new server cannot disrupt the operation of other servers in the data center. If the deployment of a release fails, the planned actions of revoking or remedying the deployment must be executed. All unsuccessful releases must be investigated. The success of failure of a deployed release must be monitored and analyzed over a period of time extending to beyond the actual deployment of the release. An assessment of customer impact must be conducted. The results of monitoring and analysis will be used to determine opportunities for improvement.
Release policy shall state the frequency and type of releases.
Organize a release plan, with the business. This process shall include reversal and remedies if unsuccessful.
The plan records the release date and deliverables (refer to RFCs, Kes, and Problems). This information should be passed to Incident management
A controlled acceptance test environment in place
Make sure the integrity of hardware and software is maintained throughout
There should be Measures of both success and failure

55. The Toolkit
The Toolkit is designed to be holistic and comprehensive to ISO/IEC 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 Toolkit is to define the contributing factors, major components, and their relationships as defined by the ISO/IEC , while providing the basic tools to take action based on the organization’s needs.
Copyright: The Art of Service 2008

56. 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 standard. Multiple templates have been created to support the process and aid organizations in their efforts to improve their capabilities.
Copyright: The Art of Service 2008