Achieving Balance in Service Operation

Services are viewed differently by the providers of the service (the internal view) and those who use them (the external view). Users neither understand nor care about the details of what technology is used to deliver or manage the services. All they care about is the service meeting their requirements (utility and warranty).

It is the responsibility of IT operations to care about the way the IT components and systems are managed to deliver the services. It is also important for service operations to understand why and when a service is valued by the customer. Due to the increasing complexity of IT, this often leads to multiple teams managing their own areas of the total solution. They concentrate on achieving good performance and availability of “their” systems. This approach is commonly represented by teams specializing in specific technologies, such as the network support team or a specific application support team. We need to support an approach that allows for a balance between the external and internal focus (Figure 33.1).

Both the external and internal views are valid, relevant, and necessary. It is important to achieve a balance between the two because an organization that focuses on one extreme or the other will not achieve value. Too far to the right and often promises are made that can’t be met; too far to the left and expensive technical solutions are delivered, which results in little value for the customer.

In Table 33.1, you will see examples of extreme internal and external focus.

It is a very common occurrence that operational departments have to respond to sudden requirements for changes, sometimes under extreme pressure. In Figure 33.2, you can see the balance between stability and responsiveness.

An area of the business may suddenly require additional IT services, more capacity, and faster response times, perhaps due to winning new business. Service operation must be able to respond to this type of change without impacting other services. This is a continual balance for most IT departments because being responsive will often make services unstable, but not responding is perceived as being a block by the business. Many IT organizations are unable to achieve this balance and focus on either the stability of the IT infrastructure or the ability to respond to changes quickly.

In Table 33.2, you will see some examples of the extremes of focus.

Another guiding principle for IT departments is balancing cost and quality, which is a common concern for organizations. What are the consequences of being too far one way or the other? In Figure 33.3, you can see the balance between cost and quality.

Different services will require a different balance. For example, the busines s may wish to prioritize high availability on a mission-critical service over that of an administrative tool. Service operation has to understand what is the correct balance for each service. Achieving the correct balance is important. Overemphasizing quality results in IT services that overdeliver at a higher cost and may lead to pressure to reduce the price of services. Overemphasizing cost may mean that although IT delivers on or under budget, they are risking the business through substandard IT services. In Table 33.3, you can see some examples of extreme focus on quality and cost.

Figure 33.4 shows delivering to an optimal level while balancing cost and quality.

Early improvements in quality may be achieved at relatively low cost, or savings may be made that do not affect quality. Once these have been made, however, further quality increases or cost savings get increasingly difficult to achieve—improved quality becomes very expensive, or savings have a big impact on quality. Consider the costs involved in improving availability from 90 percent to 95 percent as opposed to improving it from 95 percent to 99 percent, or think about the effect of cutting costs by reducing staff below a critical level. It must be a business decision to take on the cost of improving quality, so engagement with the business is vital. Think of the example of an Internet shop with no high street presence. The cost of high availability might be expensive, but at certain peak times of year, the amount of trade completed online may be worth the expenditure.

A reactive organization does not act unless it is prompted to do so by an external driver, for example, a new business requirement, an application that has been developed, or escalation in complaints made by users and customers. By then it may be too late to deliver the change in the required timescale. In Figure 33.5, you can see the balance between being reactive and being proactive.

A proactive organization is always looking for ways to improve the current situation. It will continually scan the internal and external environments, looking for signs of potentially impacting changes. This is often shown by monitoring thresholds, identifying the potential risk of failure, and looking for a preventative approach to issues. Proactive behavior is usually seen as positive, but being too proactive can be expensive and can result in staff being distracted.

Table 33.4 shows examples of extremely reactive and proactive behavior.

Providing Good Service

It is important to remember that a user’s experience is not solely based on the technical aspects of service provision. Service operation management must consider the service as well. When highly technical staff are impatient with users, the overall service is perceived as poor in the users’ eyes. Polite, helpful staff will not fully compensate for a deficient service. Being polite and helpful is essential, but a vacuous “have a nice day” approach that is not backed up with a quality service is of no use either.

Operational Involvement in Service Strategy

IT operation staff play an important assistance role in supporting service strategy activities. Assistance activities might include, for example, identifying and communicating current operation capabilities, workforce levels, and operational staff skills to those developing IT strategies along with identifying existing operational risk. It will also include gathering and identifying IT operational costs and the high-level impacts of chosen IT strategies on current operational activities. Service operation should also be involved in identifying operational constraints that may impact IT strategies, such as workforce union restrictions or inadequate physical environment capabilities and the operational risks for IT strategies being considered.

Operational Involvement in Service Design

One key to achieving balance in service operation is an effective set of service design processes. These will provide IT operations management, technical management, application management, and the service desk with a clear definition of IT service objectives and performance criteria. It will enable linkage of IT service specifications to the performance of the IT infrastructure and the definition of operational performance requirements.

Service design will also provide a mapping of services and technology and the ability to model the effect of changes in technology and changes to business requirements. Design will also deliver appropriate cost models (e.g., customer or service based) to evaluate return on investment and cost reduction strategies.

The nature of IT operations management involvement should be carefully positioned. Service design is a stage in the service lifecycle that uses a set of processes, not a function independent of service operation. As such, many of the people involved in service design may come from IT operations management, technical management, and application management.

Service operation involvement in service design activities should be strongly encouraged. This should include providing information and requirements for the operational phase as well as input to the operational acceptance tests and critical success factors from an operational viewpoint for sign-off. Staff should also be measured on their involvement in service design activities, and such activities should be included in job descriptions and roles whenever possible. This will help to ensure continuity between business requirements and technology design and operation, and it will also help to ensure that what is designed can also be operated.

Operational Involvement in Service Transition

IT operations management staff should be involved during service transition to ensure that service delivery is consistent and that both business and manageability requirements are met. Manageability activities might include training to learn how to operate a new service or to explain changes in how an existing service is currently operated.

It is important that service operation participates and reviews the operational acceptance tests and takes part in transition planning to identify the impact of transition activities on current operation activities.

Service operation should be involved in transition tasks such as moving applications and other components from their development environment to the live environment, and it should benefit from and engage with the provision of early life support activities for new services or major changes that have been released to the live environment.

Service operation should also take active participation in quality assurance activities such as validating operational readiness of a new service or a major change to the live environment.

Operational Involvement in Continual Service Improvement

Service operation staff should be involved in supporting CSI activities and identifying improvement opportunities for inclusion in the CSI register. There will be many instances where service operation provides support and information to CSI, such as ensuring that operational data is made available to personnel involved in CSI activities. Service operation staff will also be involved in validating accuracy of operational data used to identify improvement opportunities.

Service operation should take part in assessing the impact of proposed improvement actions on existing operation activities. The operational teams will be responsible for executing operational tasks to support service monitoring, measurement, and reporting activities. It is important that operational staff identify and promote operational issues and concerns to CSI staff and that they identify and propose improvements that can enhance the performance and quality of the IT services being delivered.

Meetings

Some organizations suffer from “meeting paralysis”—constantly attending meetings uses up time and resources and prevents real progress. As with reporting, the necessity for a meeting should be considered, and the format, duration, frequency, and attendees should be scrutinized to ensure that the meeting is fulfilling its purpose.

For example, daily or weekly operations meetings are a common method of sharing information between support teams. Departmental, group, or team meetings for a wider audience and customer meetings tailored for the nontechnical consumer audience are also typical.

Training is another important part of communication; the education and awareness of teams, customers, and users are vital for the success of system usage.

Documentation

The presence of relevant, complete, and up-to-date documentation is essential for successful service operation, ensuring consistency in the implementation of processes and a common understanding of requirements.

Having the correct level of documentation is an ongoing challenge for service operation teams. Too much and it is an unmanageable overhead; too little and it does not fulfil its purpose. Out-of-date documentation is arguably worse than no documentation at all!

Process documentation must include not only service operation processes, but other lifecycle processes where there is service operation involvement. It is essential to allocate the necessary time and resources to creating and maintaining documentation.

Designating key documentation as configuration items and using change management to make sure documents affected by a change are identified and updated ensures that documentation remains up-to-date. It also ensures that version control is maintained.

Consider the many different documents that are required in service operation, from technical manuals to plans and processes. Service operation staff should be involved across the lifecycle in the preparation of any documentation that has an impact on or engagement with service operation.

Service Strategy

An example of a service strategy process that is executed during the service operation stage is the financial management for IT services process.

Other inputs from service strategy include the strategic vision, mission, and plans. Operation will in turn provide risks and cost information to support strategic decision-making.

Service Design

Examples of the design processes that interface to service operation include capacity and availability management; these processes also rely on operational data for forecasting, planning, and monitoring. Other process interfaces include service catalog management, which identifies the live IT services that are to be delivered, and IT service continuity, which assures the recovery of live services.

Service level management drives the targets that operation needs to manage and support the required service performance. Information security management is also key when you consider the process interfaces between service operation and service design as well as guidance and policy for security incidents and access management.

The inputs and outputs to and from service operation and service design are shown in table 33.5. They include items such as service level agreements (SLAs), operational level agreements (OLAs), service design packages, and details of the required utility and warranty. Service operation provides inputs into service performance measures for availability and capacity, among others.

Service Transition

Service transition processes have close connections with service operation. For example, change management is a major process that should be closely linked to service asset and configuration management and release and deployment management. Service operation is also reliant on knowledge management, so there are close relationships between these two lifecycle stages.

Transition provides new or changed services, known errors, and change information into the operation stage. Service operation provides feedback on the success and quality of transitions as well as involvement in operational testing.

Continual Service Improvement

Continual service improvement has a close relationship with all the lifecycle stages, but service operation is where the improvement is most obviously seen, through service reporting and measurement.

The lifecycle stages of CSI and service operation provide inputs and outputs to each other. This includes the exchange of information about the results of customer satisfaction and service reports and data used to develop these reports.

Table 33.5 summarizes the service operation inputs and outputs.