THE FOLLOWING ITIL OPERATIONAL SUPPORT AND ANALYSIS CAPABILITY INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:

•  The value to the business of OSA activities
•  The context of OSA activities within the service lifecycle
•  How OSA activities support the service lifecycle
•  Optimizing service operation performance
•  Generic roles associated with all service management processes

Service operation’s main aim is to deliver and manage services at agreed levels to business users and customers. The service operation stage is when the service is actually delivered, and it’s often a much longer stage than the previous stages of strategy, design, and transition. It is the most visible part of the lifecycle to the business. We will cover the purpose, objectives, and scope of the service operation processes and their context within the service lifecycle. We’ll examine the value provided to the business and discuss the fundamental concepts and definitions involved in these processes.

Understanding the Purpose, Objectives, and Value of the Operational Support and Analysis Processes

The outputs from service strategy, design, and transition becomes visible in service operation. It is in the operational stage that the service—which was originally considered in strategy, put together in design, and rolled out in transition—actually delivers the benefit that the business requires and the service was designed to deliver. It is also a much longer stage of the lifecycle than the first three stages; the service should continue to meet the defined business requirement for months or even years.

Most IT staff are involved (to a greater or lesser extent) in the service operation stage. They may contribute to other lifecycle stages, but their main focus is the delivery of the operational services.

Service operation is a critical stage of the service lifecycle. After all, the best strategy will fail if the service is badly managed, and good design is of limited value if the service is not run effectively. Transition can be successful only if the environment into which the service is being transitioned is ready to receive it and takes responsibility for managing it. Finally, service improvements will not be possible without reliable metrics from monitoring performance and other data. Service operation gathers the measurements used for baselines and for measuring success of improvements, so consistent, systematic measurements are a key element of service operation.

The staff working in this stage of the service lifecycle need to have processes and support tools in place to enable them to do their job—monitoring tools that allow them to have an overall view of service operation and delivery so they can detect failures and resolve them quickly. They also need service management tools to ensure that the correct workflow takes place for each process and the necessary information is easily accessible. This may entail monitoring elements of the service supplied by external providers.

Because services may be provided, in whole or in part, by one or more partner/supplier organizations, the service operation view of the end-to-end service needs to encompass external aspects of service provision, including managing cross-organizational workflows.

Process A process is defined as “a set of coordinated activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs.”

The processes included in Operational Support and Analysis are as follows:

Event Management This process is concerned with having useful notifications about the status of the IT infrastructure and services. Event management sets up rules to ensure that events are generated so that they can be monitored, captured, and acted upon if necessary.

Incident Management The purpose of incident management is to return normal IT service to users as quickly as possible. This may prompt the question, how do we define normal service? It is the level of service specified, and agreed to, in the service level agreement (SLA). The goal is to minimize the adverse impact of incidents on the business, and thus on service quality and business productivity. The objective of incident management is to ensure that the best possible levels of business-aligned service quality are maintained.

Problem Management The responsibility of problem management is to manage the lifecycle of problems, which includes monitoring and reviewing the process in addition to managing problems to their conclusion. Problem management is about the prevention and reduction of incidents, solving and removing their root cause. At the very least, if an incident cannot be prevented, then the impact to the business should be reduced through the provision of workarounds provided through the known error database.

Request Fulfillment The objectives of the request fulfillment process are to log and fulfill standard requests for users in a simple, efficient way. For a request to qualify, a predefined approval and qualification process must exist. Request fulfillment also provides information to users about the availability of services and how to obtain them. Users can request and receive the service or the software/hardware they require to use the service. Request fulfillment is also the channel for general information, complaints, and comments.

Access Management Access management is responsible for putting the policies of availability and information security management into day-to-day practice. It is essential to control access to protect an organization’s data and intellectual property while at the same time enabling authorized users to have the access they need. Access management is not responsible for ensuring that this access is available at all agreed times—this responsibility is provided by the availability management process.

The Value Operational Support and Analysis Processes Deliver to the Business

Service operation is responsible for running the new service and for fixing any unforeseen flaws. The service must run efficiently if the cost of the service is to be less than the benefit to the business. The ITIL framework offers guidance on the best practices that can be used in the various lifecycle stages, and following this advice can deliver real benefits. In the area of service operation, the following benefits can be achieved from following best practices:

• Financial savings from reduced downtime as a result of the implementation of the service operation processes of problem and incident management. Problem management will reduce the frequency of failures so that less time (and therefore money) is wasted by the business not being able to work. It will ensure that skilled IT staff members concentrate their efforts on identifying and removing the root cause of the incident, thus preventing recurrence. Meanwhile, efficient incident management ensures that the service is restored as soon as possible, often by service desk staff members using defined workarounds. This both speeds up the service restoration and reduces costs, the latter because the more expensive IT staff members are not called on to resolve simple incidents.
• Service operation includes the production of management information regarding the efficiency and effectiveness of the service delivery. This is used by other processes to target, justify, and implement continual service improvement initiatives. Technology may be used to automate this report generation, reducing the cost of production.
• By carrying out the access management activities, service operation ensures that the business is able to meet the goals and objectives of the organization’s security policy by ensuring that IT services will be accessed only by those authorized to use them; services are protected from unauthorized access in accordance with the organization’s security policy.
• Service operation also provides quick and effective access to standard services through request fulfillment. This improves the productivity of users by enabling quick access to the services and equipment they need for optimum efficiency while maintaining control over expenditure. Technology may be used to provide users with a self-service facility such as resetting passwords, ordering standard items, or logging incidents through a web portal. This offers an efficient and cost-effective means of providing these services.
• By using technology to automate routine tasks, based on the information provided by the event management process, service operation reduces the number of staff members required to operate the service. This means, as the number of users grows and the complexity of the services increases, the number of people needed to support the users remains broadly the same. This reduces costs and frees up technical staff members to concentrate on identifying improvements and new opportunities. Automation also delivers a more reliable and consistent service.
• Service operation also provides the operational results and data that is then used by other ITIL processes as evidence of the need for service improvements (answering the “where are we now?” question) or to justify investment in service improvement activities. It also provides the data required to answer the “Did we get there?” question.

The Context of Service Operation, the Operational Support and Analysis Processes, and the Service Lifecycle

Service operation needs to be considered within the context of the whole service lifecycle. Each area of the lifecycle addresses a particular set of challenges that need to be addressed for successful service management, and each stage has an impact on all the others. The service lifecycle diagram in Figure 1.1 shows the five areas of the lifecycle.

Stages of the lifecycle work together as an integrated system to support the ultimate objective of service management, which is to deliver business value. Every stage is interdependent, as shown in Figure 1.2. In particular, note the interdependence of service operation to each of the other lifecycle stages.

Generic Roles and Responsibilities in Service Management Processes

There are many different ways to organize an IT department, and no two service providers are identical, so the exact configuration of roles within each organization will differ. Often two or more roles may be combined; in other organizations, a single role may be split. ITIL provides guidelines, not prescriptive rules, so each organization should consider what would best fit their own requirements.

We will first clarify what is meant by the term role. The official glossary defines it as follows:

A set of responsibilities, activities, and authorities assigned to a person or team. A role is defined in a process or function.

Within each of the processes we will cover throughout the service lifecycle, there are a number of roles. The role may be carried out by an individual or a team, and one person may have multiple roles. The person responsible for the availability management of the infrastructure may often also be fulfilling the capacity management role. It may be that capacity management is divided between a number of people, with one considering network capacity, another responsible for storage, and so on.

It is important to remember that although roles may be shared, or combined, there can be only one process owner for each process and one service owner for each service.

Often a job title may be the same as a role description; service level manager is one such example. Job titles are for each organization to decide, and it may be the case that the job of service level manager includes the role of service level manager, along with one or more other roles, such as supplier manager, within that particular organization.

It is also often true that one task carried out by an individual may touch several processes. A technician may submit a request for change to overcome a capacity issue that has been identified by problem management. The action may have been identified as desirable as part of a service improvement plan (SIP), which has been logged on the CSI register. The technician’s action therefore involves several processes: problem, change, capacity, service level management, and continual service improvement.

Every process has its own specific roles. Here we will be looking at the generic roles that appear in all lifecycle stages.

Service Owner

With every service interacting with so many processes, there is a danger that the service itself may no longer receive the required attention. To avoid this, ITIL recommends that each service should have a single service owner. This clarifies who is accountable for the service and ensures that there is a focus on the business processes that the service supports.

Whatever technology is used to deliver the service and regardless of whether aspects of the technology are provided in-house or are outsourced, the service owner remains accountable for delivering the service. This role is responsible to the customer for the service being developed, implemented, and maintained, but it is also accountable to the IT director or service management director for its delivery.

As we will examine, ITIL recommends that each process should have an identifiable owner. Each process may affect many services, and it is the service owner of each who will ensure the service is delivered effectively and efficiently, whatever process is being carried out. Service owners will often own more than one service. For each service, they will carry out the following responsibilities:

• Ensuring that the service is delivered and supported to the required standards by working with all IT groups and process owners
• Ensuring that the customer’s requirements are understood and that the tasks required to deliver them are implemented by working with the business relationship manager
• Communicating with the customer as required on all issues regarding the delivery of the service
• Using the service portfolio management process to define new service models and to evaluate the impact of any changes to existing services
• Ensuring that the service undergoes continual service improvement by identifying possible improvements and, with the customer’s agreement, putting these forward as requests for change
• Ensuring that appropriate monitoring and reporting is taking place to enable an accurate view of the level of service being delivered
• Ensuring that the required levels of performance and availability are delivered
• Developing a thorough understanding of the components that make up the service and ensuring that the potential impact of their failure is realized
• Representing the service across the organization and attending service review meetings with the business
• Representing the service within IT and at change advisory board (CAB) meetings and internal service reviews
• Being the escalation (notification) point for major incidents affecting the service
• Working with service teams to negotiate service level agreements that meet the customer requirements and operational level agreements that support the service provision at the agreed level
• Maintaining the service catalog entry
• Working with the CSI manager to identify improvements to be added to the CSI register and participating in the review and prioritization of these and their eventual implementation

As the owner of the service, this role is concerned with the impact of any process affecting the service. This means service owners should be considered stakeholders in these processes, with whatever level of involvement is appropriate.

For example, the service owner plays a crucial part in the major incident process and will attend or possibly run any crisis meetings. They will also be involved in investigating the root cause of problems affecting their service. The service owner will represent the service at CAB meetings and will be involved in discussions regarding if and when a release should go ahead. They will want to ensure that the service portfolio and catalog entries and configuration data held on their service is accurate.

As explained earlier, a close relationship should exist between the service level management process and the service owner who acts as the contact point for the service. The service owner will also liaise with the owners of the more technical processes, such as availability and capacity, to ensure that the data collected by these processes indicates that the performance and reliability of these services meets the agreed standard.

The service owner is responsible for ensuring that the IT service continuity management (ITSCM) plan for their service is practical and that every element of the plan is in place. They will work with the ITSCM manager to make sure that all aspects are considered. They will often attend rehearsals of the plan to observe it in action to confirm that nothing has been forgotten.

The service owner understands the costs involved in delivering the service and will work with the supplier manager and other managers to ensure that costs are controlled and value for money is achieved. In organizations where the business is charged for IT services, they will ensure that the recovery of costs takes place as agreed.

Finally, the service owner ensures that the service follows the information security management policies.

Process Owner

As we have seen, the service owner is the focus for one particular service across all process areas. The process owner, in contrast, is accountable for a single process, whatever the service it affects.

The process owner must ensure that the process works efficiently and effectively. Although the role may often be carried out by the same person who fulfills the process manager role, in larger organizations this is less likely. A global company may have a change management process owner and a number of process managers carrying out the process in different countries, for example. The process owner is accountable for ensuring the process is fit for its purpose and is being carried out correctly by the process managers and practitioners. The role therefore has both a design and an enforcement aspect.

The process owner is accountable for the following:

• Developing the process strategy, policies, and standards
• Assisting with designing the process and amending it as required to implement improvements that make it more effective or efficient
• Assisting with designing the metrics for the process and ensuring that these provide the necessary information to judge the effectiveness and efficiency of the process
• Ensuring that the process is documented, that this documentation is available to those who require it, and that it is updated as needed
• Where the process has changed, ensuring that the process documentation is updated and the changes communicated to the process practitioners (those who actually carry out the process steps)
• Auditing the process activities to ensure adherence to the correct process
• Ensuring that the required resources are available to carry out the process and that the staff members involved have been trained to carry it out
• Communicating to the process practitioner the importance of adhering to the documented process and explaining the implications for IT and the business of nonadherence
• As part of continual service improvement, reviewing the process strategy and the effectiveness of the process itself to identify possible improvements
• Where improvements to effectiveness or efficiency are identified, having these included in the CSI register and working with the CSI manager to review, prioritize, and implement them as appropriate

The process owner role is critical to the success of the process. In organizations where no such single point of ownership exists, those carrying out the process may decide to drop or amend steps in the process, and there is no one with the overall authority to prevent this. In global organizations, this can mean the process may develop regional variations. In addition to the danger of losing focus on the purpose of the process, this may invalidate the reporting from the process, because each area may be inputting data differently.

Without a process owner, there is no one with the responsibility of ensuring consistency in applying the process, and there is no one to ensure that the process output still matches the process objectives. Process documentation may not be updated, because the responsibility for its upkeep would be unclear. Finally, there would be no one to assess the process and identify improvements.

Process Manager

The process owner is accountable for the success of the process but may often not be responsible for actually carrying it out. The responsibility for managing the day-to-day implementation of a process belongs to the process manager. In large or geographically spread-out organizations, there may be several process managers responsible for managing the implementation of the same process, each with a regional or infrastructure responsibility.

The process manager is accountable for the following:

• Liaising with the process owner to ensure that the process is implemented across all lifecycle stages as the process owner intended
• Ensuring the right numbers of staff are assigned to the various roles within the process and that they understand what is required of them
• Working with other process managers and service owners to ensure the services are delivered as required
• Monitoring the process metrics to confirm the process is working as designed
• As part of continual service improvement, reviewing the process performance to identify possible improvements
• Where improvements are identified, having them included in the CSI register and working with the CSI manager and process owner to review, prioritize, and implement them as appropriate

The role of process manager is important, because it is the process manager who ensures that the process is carried out correctly day-to-day. The process owner may be distant from where the process occurs (working in the head office while the process takes place in branch offices, for example). The process manager, or managers, will ensure that the staff members understand what is required of them and have been provided with the right resources and training to carry out the tasks. Because process managers are close to the process execution, they are in an ideal position to identify issues and possible improvements. The success of any improvement initiatives will depend heavily on the enthusiastic involvement of the process manager in ensuring that staff members adopt the improved process.

Process Practitioner

Depending on the process, there may be one or more people carrying out the process activities. In a small organization or for a simple process, this may be a single person, who is also likely to be the process manager. For a large organization or for a complex process, there may be many people, each carrying out parts of the process. The people involved in carrying out the process activities are the process practitioners.

The process practitioner is usually responsible for the following:

• Completing process activities to the required standard
• Understanding the importance of the process and their role within it, and how they contribute to delivering the service
• Working with all the process stakeholders to ensure the process inputs, outputs, and interfaces are working properly so that the process delivers the desired result
• Producing evidence that the process activities have been carried out correctly, in the form of records
• Identifying necessary improvements to the process or supporting tool

The process practitioner role is responsible for actually delivering the process activities. Under the guidance of the process manager (unless these roles are combined), the practitioner is responsible for carrying out the process as designed, consistently and efficiently. It may be tempting to believe that the practitioner has nothing to contribute other than carrying out the activities; this is far from the truth. As a practitioner, the staff member will experience firsthand any issues with the process, such as tools that do not support the process effectively, bottlenecks in the process flow, or ambiguities in the documentation. The process manager and process owner should therefore seek out the views of practitioners when attempting to identify possible improvements.

Each role has its own purpose. Even where the roles are carried out by the same person, that person should attempt to consider each aspect of the roles. The practitioner has the advantage of daily interaction with the process but may be too close to it to see it objectively; the process manager is judged on the outcome of the process and so has a particular focus on the resources required to deliver these effectively and efficiently. They will monitor the process metrics closely to ensure that the outputs are being delivered on time and within budget. The manager will see only their own part of the process delivery, however. The process owner has the advantage of seeing the overall picture, comparing the delivery of the process in different locations and under different process managers. By understanding the strengths and weaknesses of each perspective, a complete picture of the process delivery can be achieved, and improvement initiatives can be gathered from each level.

Summary

This chapter covered the value, purpose, and objectives of the operational support and analysis processes and how they deliver value to the organization. We looked at the processes within the context of the service lifecycle and considered the fundamentals of the operational support and analysis processes. We covered which processes from other lifecycle stages require service operation action. We also considered the generic roles applicable to the processes, including that of service owner, with which the processes have a significant interaction.

It is important to remember that the generic roles will apply across all lifecycle stages and service management processes.

In the following chapters, we will be examining the service operation processes of incident management, problem management, access management, request fulfillment, and event management.

Exam Essentials

Understand the value of operational support and analysis processes. These processes form the core of the service operational activities and how the service operation lifecycle stage adds value to the business.

Understand the place of operational support and analysis processes in the service lifecycle. Understand the impact each of the other lifecycle stages has on service operation. Know the inputs from these other stages into service operation processes and the outputs from service operation into the rest of the lifecycle.

Understand the responsibility of service operation to deliver the services in line with the SLAs that have agreed with the business. The transition stage should have validated the SLA targets through testing and piloting the service; it is the responsibility of service operation to continue to meet the SLA targets during the operational stage of the service lifecycle.

Understand the role played by operational support and analysis processes in ensuring that the services deliver business value. By delivering the services efficiently and to agreed service targets, service operation ensures that the business benefits from the service as planned.

Understand the key processes of service operation. Be able to name the five service operation processes: incident management, request fulfillment, access management, problem management, and event management.

Understand the generic roles associated with the processes of service operation. Be able to name and explain the significance of the roles associated with all the processes in service operation.