SS

Current monitoring solutions result in the capture of only a small percentage of failure s. 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 process es. 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 provider s 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 service s. The links were based on direct causality. Only those event s 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 threat s. 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 cost s of underserved market space s 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 threat s 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 operate s 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 performance metric s 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 cost s 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 objective s.

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 / project risk management and operational service 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 . Risk s flow both ways (Figure 9.4). For example, by maintaining and operating service asset s so that customers do not have to, the service provider is assuming risks associated with those assets. Customer s 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.