SS - читать онлайн бесплатно полную версию книги . Страница 55

Organizations have long understood the Deming principle: if you cannot measure it, you cannot manage it. Yet despite significant investments in products and processes, many IT organizations fall short in creating a holistic service analytics capability. When combined with a disjointed translation of IT components to business processes, the results are operational models lacking in proactive or predictive capabilities.

Performance measurements in service organizations are frequently out of step with the business environments they serve. This misalignment is not for the lack of measurements. Rather, traditional measurements focus more on internal goals rather than the external realities of customer satisfaction. Even the measurements of seasoned organizations emphasize control at the expense of customer response. While every organization differs, there are some common rules that are useful in designing effective measurements, as shown in Table 9.1.

Principle

Guidance

Begin on the outside, not the inside of the service organization

A service organization should ask itself, ‘What do customers really want and when?’ and ‘What do the best alternatives give our customers that we do not?’

Customers, for example, frequently welcome discussion on ways to make better use of their service providers. They may also welcome personal relationships in the building of commitment from providers.

Responsiveness to customers beats all other measurement goals

Care is taken not to construct control measures that work against customer responsiveness.

For example, organizations sometimes measure Change Management process compliance by the number of RFCs disapproved. While this measurement may be useful, it indirectly rewards slow response. An improved measurement strategy would include the number of RFCs approved in a set period of time as well as the percentage of changes that do not generate unintended consequences. Throughput, as well as compliance, is directly rewarded.

Think of process and service as equals

Focusing on services is important but be careful not to do so at the expense of process. It is easy to lose sight of process unless measurements make it equally explicit to the organization. Reward those who fix and improve process.

Numbers matter

Use a numerical and time scale that can go back far enough to cover the explanation of the current situation.

Financial metrics are often appropriate. For non-commercial settings, adopt the same principle of measuring performance for outcomes desired. For example, ‘beneficiaries served’.

Compete as an organization. Don’t let overall goals get lost among the many performance measures

Be mindful of losing track of overall measures that tell you how the customer perceives your organization against alternatives. Train the organization to think of the service organization as an integrated IT system for the customer’s benefit.

Table 9.1 Measurement principles

Measurements focus the organization on its strategic goals, tracking progress and providing feedback. Be sure to change measurements as strategy evolves. When they conflict, older measurements will beat new goals because measurements, not strategic goals, determine rewards and promotions. Crafting new strategic goals without changing the related measurements is no change at all.

Current monitoring solutions result in the capture of only a small percentage of failures. Practice shows that monitoring discrete components is not enough. An approach that integrates with service management and promotes cross-domain coordination is more likely to afford success. Unfortunately, the common techniques are not completely satisfactory. They work well in restricted problem domains, where they focus on a particular subsystem or individual application; they don’t work as well in a service management context.

The holy grail of monitoring is often referred to as ‘end-to-end’ visibility. Yet most of the IT organization has no visibility into the business processes. One cannot exist without the other. Indeed, the endpoints in ‘end-to-end’ are often misunderstood. Imagine the increased relevance that IT would gain if they could answer questions like the following:

 What is the delay, together with business impact, on the Supply Chain due to an IT problem?

 How long does it take to process procurement orders, and where are the worst delays?

 When is more than £1,000,000 worth of orders waiting to go through the distribution systems?

It is not uncommon for the business or senior managers to ask ‘How?’ and ‘Why?’ when the monitoring solution can only answer ‘What?’ and ‘When?’ Most IT organizations have deployed analytic technologies that primarily focus on the collection of monitoring data and while they are extremely effective at data collection they are ineffective in providing insight into services. This condition leads to statements such as:

‘We want better Event Management so we can predict and prevent service impacts.’

The statement is a logical fallacy: one thing follows the other, therefore one thing is caused by the other. No amount of Event Management will ever provide predictive qualities; it will only give a better view of the crash. To understand why, it is helpful to borrow a construct from Knowledge Management called the DIKW hierarchy, Data-to-Information-to-Knowledge-to-Wisdom.

Case example 14 (solution): The DIKW hierarchy and BSM

The problem was solved through a form of the DIKW hierarchy. The multiple service providers received data and information generated through instrumentation and Event Management techniques, allowing them to perform monitoring and diagnostics.

A BSM model was crafted that linked infrastructure components to business services. The links were based on direct causality. Only those events that passed the ‘causality test’ were passed on to the manufacturer allowing business leaders to work off knowledge (impact) rather than information (events).

9.5 Risks

‘The number one risk factor in any organization is lack of accurate information.’

Mark Hurd, Chairman and CEO, HP

Risk is normally perceived as something to be avoided because of its association with threats. While this is generally true, risk is also to be associated with opportunity. Failure to take opportunities can be a risk in itself.43 The opportunity costs of underserved market spaces and unfulfilled demand is a risk to be avoided. The Service Portfolio can be mapped to an underlying portfolio of risks that are to be managed. When service management is effective, services in the Catalogue and Pipeline represent opportunities to create value for customers and capture value for stakeholders. Otherwise, those services can be threats from the possibility of failure associated with the demand patterns they attract, the commitments they require and the costs they generate. Implementing strategies often requires changes to the Service Portfolio, which means managing associated risks.

Decisions about risk need to be balanced so that the potential benefits are worth more to the organization than it costs to address the risk. For example, innovation is inherently risky but could achieve major benefits in improving services. The ability of the organization to limit its exposure to risk will also be of relevance. The aim should be to make an accurate assessment of the risks in a given situation, and analyse the potential benefits. The risks and opportunities presented by each course of action should be defined in order to identify appropriate responses.43

For the purpose of analysis, it is sometimes useful to visualize the positive type of risks associated with opportunities, investments and innovation to the negative type from failure to take advantage of opportunities, not making enough investments, and neglecting innovation.

Case example 15: Inbound call centre service

A service provider operates the IT infrastructure of an inbound call centre for a business unit. A major system failure (asset impairment) leads to a reduction in the number of available call centre agents. The load for the functional on-duty agents quickly increases. As peak hours arrive, the increased traffic combined with sluggish response leads to further delays.

Increasingly frustrated by long wait times, callers become agitated. The rate of abandoned calls increases rapidly. Call centre agents observe their performancemetrics plummet and respond by attempting to reduce the average length of calls. For the business unit, this drives down caller satisfaction metrics and increases opportunity costs from lost sales.

How could this have been avoided?

(Answer at the end of Section 9.5.2)

9.5.1 Definition of risk

Risk is defined as uncertainty of outcome, whether positive opportunity or negative threat. Managing risks requires the identification and control of the exposure to risk, which may have an impact on the achievement of an organization’s business objectives.

Every organization manages its risk, but not always in a way that is visible, repeatable and consistently applied to support decision making. The task of management of risk is to ensure that the organization makes cost-effective use of a risk framework that has a series of well-defined steps. The aim is to support better decision making through a good understanding of risks and their likely impact. There are two distinct phases: risk analysis and risk management (Figure 9.3).

Risk analysis is concerned with gathering information about exposure to risk so that the organization can make appropriate decisions and manage risk appropriately.

Management of risk involves having processes in place to monitor risks, access to reliable and up-to-date information about risks, the right balance of control in place to deal with those risks, and decision-making processes supported by a framework of risk analysis and evaluation.

Figure 9.3 Generic framework for Risk Management43

Management of risk covers a wide range of topics, including Business Continuity Management (BCM), security, programme/projectrisk management and operationalservice management. These topics need to be placed in the context of an organizational framework for the management of risk. Some risk-related topics, such as security, are highly specialized and this guidance provides only an overview of such aspects.

9.5.2 Transfer of risks

Services reduce risks to the customer’s business but they also transfer risk to the service provider. Risks flow both ways (Figure 9.4). For example, by maintaining and operating service assets so that customers do not have to, the service provider is assuming risks associated with those assets. Customers compensate service providers for these transferred risks in many ways. First and foremost, the burden of risks can be accounted for in the pricing of the services.

While this may not be possible for some Type I providers it is best practice as demonstrated by their peers elsewhere. Type I providers should engage their customers in dialogue on compensation for risks within the framework of corporate policy.

When it is not possible to account for the burden of risks in pricing of services, as in the case of some Type I providers, it should nevertheless be highlighted for the customer. Customers compensate for risks also by assuring patterns and periods of demand that mitigate the risk of investments made by the provider in offering a catalogue of services.