Service Operation Introduction

Different type of functions in service operation:

Strategic objectives are ultimately realized through service operation. ITIL Service Operation provides guidance on how to maintain stability in service operation, allowing for changes in design, scale, scope and service levels. Organizations are provided with detailed process guidelines, methods and tools for use in two major control perspectives:

• Reactive

• proactive

New models and architectures such as shared services, utility computing, web services and mobile commerce to support service operation are described.

Service Operation Goals & Objectives

The purpose of the service operation stage of the service life cycle is to coordinate and carry out. The activities and processes required to deliver and manage services at agreed levels to business users and customers. Service operation is also responsible for the ongoing management of the technology that is used to deliver and support services. It is a critical stage of the service life cycle. Well-planned and well-implemented processes will be to no avail if the day-to-day operation of those processes is not properly conducted, controlled and managed. Nor will service improvements be possible if day-to-day activities to monitor performance, assess metrics and gather operational data are not systematically conducted during service operation.

Staff involved in the service operation stage of the service life cycle should have processes and support tools in place, that allow them to have an overall view of service operation and delivery. Rather than just the separate components, such as hardware, software applications and networks, that make up the end-to-end service from a business perspective. These processes and tools should also detect any threats or failures to service quality. As 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 should be extended to encompass external aspects of service provision. When necessary, shared or interfacing processes and tools should be deployed to manage cross-organizational work flows.

The objectives of service operation are to:

1. Maintain business satisfaction and confidence in IT through effective and efficient delivery and support of agreed IT services.

2. Minimize the impact of service outages on day- to-day business activities.

3. Ensure that access to agreed IT services is only provided to those authorized to receive those services.

4. Select and adopt the best practice as recommended in this publication will assist organizations in delivering significant benefits.

Adopting and implementing standard and consistent approaches for service operation will :

1. Reduce an unplanned labor and costs for both the business and IT through optimized handling of service outages and identification of their root causes

2. Reduce the duration and frequency of service outages which will allow the business to take full advantage of the value created by the services they are receiving

3. Provide operational results and data that can be used by other ITIL processes to improve services continually and provide

4. Justification for investing in ongoing service improvement activities and supporting technologies

5. 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

6. Provide quick and effective access to standard services which business staff can use to improve their productivity or the quality of business services and products

7. Provide a basis for automated operations, thus increasing efficiencies and allowing expensive human resources to be used for more innovative work, such as designing new or improved functionality, Defining new ways in which the business can exploit technology for increased competitive advantage

Service Operation key Terminology Impact is the Measure of effect of an Incident, Problem or Change on Business Processes. Impact is often based on how Service Levels will be affected. Urgency is the measure of business criticality of an Incident, Problem or Change where there is an effect upon business deadlines.

-Time required for actions to be taken is known as Priority.(Priority is a function of Impact & Urgency.)Priority = Impact X Urgency

-Service Request is the user requesting information for a change or access to an IT Service

-An Event is a notification created by a service, CI or monitoring tool.

-An Alert is a warning or notice about threshold, change or failure that has occurred.

-An Incident unexpected interruption or reduction in quality of an IT service.

-A Problem is a cause of one or more Incidents.

-A Workaround is a temporary means to resolve issues or difficulties.

-A Known Error is a Problem that has a documented Root Cause & a Workaround.

-A Known Error Database (KEDB) is a storage for previous knowledge on requests and known errors.

Balance Internal IT view versus external business view

The most fundamental conflict in all stages of the service life cycle is between the views of IT as a set of IT services (External view) and the view of IT as a set of technology components (Internal view). The external view of IT is the way in which services are experienced by its users and customers. They do not always understand, nor do they wish to care about the details of what technology is used to manage those services. All they are concerned about is that the services are delivered as required and agreed. The internal view of IT is the way in which IT components and systems are managed to deliver the services. Because IT systems are complex and diverse, this often means that the technology is managed by several different teams or departments.

Each of which is focused on achieving good performance and availability of ‘its’ systems. The whole point of service management is to balance these views to meet the objectives of the organization as a whole. It is critical to structure services around customers. At the same time, it is possible to compromise the quality of services by not thinking about how they will be delivered. Both views are necessary when delivering services. The organization that focuses only on business requirements without thinking about how they are going to deliver will end up making promises that cannot be kept. The organization that focuses only on internal systems without thinking about what services they support, will end up with expensive services that deliver little value. The potential for role conflict between the external and internal views is the result of many variables, including the maturity of the organization, its management culture, its history etc. This makes a balance difficult to achieve, and most organizations tend more towards one role than the other. Of course, no organization will be totally internally or externally focused, but will find itself in a position along a spectrum between the two.

Balance Stability vs. Responsiveness

No matter how well IT service has been designed & no matter how good is the functionality of an IT service, it is worth nothing if their individual IT components are not performing as per their agreed levels and not delivering the desired value.

Stability is to: Develop & refine standard IT management techniques & processes. Service components needs to be available & perform consistently. Responsiveness is the: Ability to respond to changes without impact to other services. Ability to take care when agreeing to required changes - Consider all requirements and impact of delivering change. Example: A Business Unit requires additional IT Services, more capacity and faster response times. To respond to this type of change without impacting other services is a significant challenge. Many IT organizations are unable to achieve this balance and tend to focus on firefighting! Building an IT organization that achieves a balance between stability and responsiveness in service operation will require the following actions:

1. Ensure investment in processes and technologies that are adaptive rather than rigid.

2. Build a strong service level management (SLM) process which is active from the service design stage to the CSI stage of the service lifecycle.

3. Ensure proper mapping of business requirements to IT operational activities and components of the IT infrastructure by integration between SLM and the other service design. This will ensure that both business and (IT operational requirements can be assessed and built or changed together.

Balance Quality of service vs. Cost of service

Service Operation is required to consistently deliver the agreed level of IT service to its customers and users, while at the same time keeping costs and resource utilization at an optimal level. Achieving an optimal balance between cost and quality is a key role of service management. Every organization will have different range of optimization, depending on the nature of the service and the type of business. Determining the appropriate balance of cost and quality should be done during the service strategy and service design life cycle stages. Although in many organizations it is left to the service operation teams. Unfortunately, it is also common to find organizations that are spending vast quantities of money without achieving any clear improvements in quality. Again, CSI will be able to identify the cause of the inefficiency, evaluate the optimal balance for that service and formulate a corrective plan. Achieving the correct balance is important. Too much focus on quality will result in IT services that deliver more than necessary, at a higher cost, and could lead to a discussion on reducing the price of services. Too much focus on cost will result in IT delivering on or under budget, but putting the business at risk through substandard IT services. There is no simple calculation to determine when costs have been cut too far, but good SLM is crucial to making customers aware of. The impact of cutting too far, so recognizing these warning signs and symptoms can greatly enhance an organization’s ability to correct this situation.

Reactive vs. Proactive

Action which takes place when prompted by external driver is known as Reactive. Proactive is always looking for ways to improve current situation- Continually looking for potentially impacting changes,can be expensive, better to manage proactively. A reactive organization is one which does not act unless it is prompted to do so by an external driver, e.g. a new business requirement. An application that has been developed or escalation in complaints made by users and customers. An unfortunate reality in many organizations is the focus on reactive management mistakenly as the sole means to ensure services that are highly consistent and stable. Actively discouraging proactive behavior from operational staff. The unfortunate irony of this approach is that discouraging effort investment in proactive service management can ultimately increase.

To achieve balance between reactive and proactive we require:

1. Formal, Integrated Problem and Incident Management processes

2. Ability to prioritize technical faults and demands. Data from Configuration and Asset Management.

3. Ongoing involvement from Service Level Management in Service Operations.

While proactive behavior in service operation is generally good, there are also times where reactive behavior is needed. The role of service operation is to achieve a balance between being reactive and proactive.