Chapter 4

Thinking It Through: Service Strategy

In This Chapter

Having a strategy for your services

Understanding what the customer wants

Managing your entire collection of services

Bringing together financial management

Knowing the demand for your services, and how to supply

When you start a new project at home – decorating the bathroom, clearing out the garage, tidying the garden – do you just jump in head first? I suspect you sometimes do. Perhaps you regret doing so and ask yourself why you didn’t sit down first and plan your project. Most things work better if you plan them first. And a good plan starts with a good strategy.

Many IT organisations grow their IT services organically. They just respond to business needs as and when they occur and implement other good ideas suggested by IT staff. Over time, organisations discover that they have a set of services. I think this is somewhat haphazard. You gain a lot by sitting down and doing a bit of planning – Rome wasn’t built in a day. Building a good set of services takes time and effort.

This chapter provides an overview of the ITIL service strategy stage in the service lifecycle, as described in the ITIL service strategy book. When you have a strategy for your IT services, you use it as a guide to direct your IT organisation to build up a set of IT services that support the business and make best use of your IT assets.

The ITIL service strategy book describes five processes. Four of them I explain in this chapter: service portfolio management, financial management for IT services, demand management and business relationship management. The final process, strategy management for IT services, I explain in Chapter 11.

Understanding Strategy

What is a strategy? Think of a strategy as a high-level plan to achieve something.

Put simply, a strategy is a plan that outlines how an organisation will meet a defined set of objectives.

The definition implies that first you must know what your defined objectives are. So, in any piece of work, deciding what you want to achieve so you can then set a plan in place to achieve it is common sense. By laying down your strategy you make it easier to tell others about your plans and get support for them.

Not only does defining strategy make you consider what you want to do, but it also prompts you to consider why you should do things. Sometimes an IT department blindly implements what management tells it to do, without much thought. Stopping and asking why you’re doing something can lead to better, more innovative solutions.

Some people run screaming from the room at the mere mention of the word strategy. But don’t be afraid. In this chapter I just prompt you to think about having a plan for deciding which IT services you should offer to your customers or organisation. This inevitably means talking about money, because developing services costs money. It also involves thinking about whether a strong demand exists for the service.

An organisation without a strategy has no idea of how it will achieve its goals. It’s groping around in the dark. Things may happen accidently and turn out right – but can you take the risk?

The activities you use to create a strategy for your IT service are described by the ITIL process called strategy management for IT services. I describe this process in Chapter 11.

Understanding the Purpose of the Service Strategy Stage

The service strategy stage sets the strategy for your IT services. This stage helps you decide who your customers are and what IT services you want to offer them. This allows you to define the complete set of IT services that you want to provide. This complete set of services is known as a service portfolio.

The strategy you create provides a sense of direction for all your service management activities. Your strategy will influence all the activities you perform in other service lifecycle stages. (In Chapter 3, I describe the service lifecycle; Figure 3-1 shows the service lifecycle, with service strategy at the centre.)

The purpose of the ITIL service strategy stage is to allow you and your organisation to make decisions such as:

What services should we offer and to whom?

How do we differentiate ourselves from competing alternatives?

How can we create value for our customers?

How can we make a case for strategic investments?

How should we define service quality?

Thinking about strategy gets you thinking about how to use service management as a strategic asset, that is how to use service management to the benefit of the organisation, either to the organisation’s competitive advantage in the marketplace or to achieve the organisation’s business goals. IT services and systems are ever more relied upon by businesses to help them do what they do.

For example, some companies must respond quickly to their customers in order to win business, and therefore a fast and reliable email service may be the difference between winning and losing an order. In another organisation, a sales quotation IT system may contribute to quickly offering customers a good deal and thus winning business. These are both examples of achieving a strategic advantage.

When the strategy is set, in the service strategy stage you put policies and standards in place that make it easier for the organisation to achieve the strategy and hence the strategic goals. I like to think of this as putting signposts in place that direct you towards your goal or destination. The policies and standards help prevent you and your colleagues reinventing the wheel each time you do something to your services. It’s a little like saying, ‘We’ve done it before and here are the things that we discovered that should make things easier for you.’

Take a simple example of going on a journey. Say you have to travel a hundred miles to a major city. I’m your boss, and your strategic objective is to reach the city. An example of a policy may be: ‘Take the train. We find that you arrive fresh and ready to do business as opposed to enduring a stressful drive.’ Or the policy may be: ‘Travel the evening before, because train travel is cheaper in the evenings than during the morning peak hours.’

Understanding Some Basic Principles

In order to identify and manage a strategy there are couple of aspects of your services and your organisation that you must understand and identify.

The value proposition

The value proposition helps you understanding how your customer gets value from each IT service. The value proposition refers to the little equation:

Value = utility + warranty

Briefly, utility refers to what the service does; a service that does this is fit for purpose. Warranty refers to an assurance that the customer receives the appropriate levels of availability, capacity, security and continuity for the service; a service that provides warranty is fit for use. (For a more detailed explanation of these terms, have a look at Chapter 2.) Your organisation must understand how the customer derives value from each and every service the organisation provides. This is part of the high-level business requirements of the service.

The level of utility and warranty the customer requires affects the assets you use to provide the service. Two types of assets exist: resources and capabilities. (I describe these assets in more detail in Chapter 2.) For example, if a customer demands higher availability, say 22 hours a day with no failures, you have to use up a lot of knowledge to design a more resilient service, and you have to spend money to acquire additional hardware and software and possibly support staff. So the value the customer gets from the service is linked to the assets needed to deliver the service.

Understanding what the customer wants

Value is linked to the business outcomes that customers want to achieve. Customers don’t necessarily want to use your IT services. But they recognise advantages exist to using IT in general. Using a PC is often faster, more accurate and less labour-intensive, but users expect the software applications to be easy to use and focused on their needs. Additionally, they expect the IT services to be there when they need them and to work at the right speed. In other words, they expect the IT service to be a help not a hindrance.

A vehicle roadside recovery organisation is discussing how IT can support its business needs. The business states that an important business outcome is the ability to despatch the nearest available driver and vehicle to a stranded customer at any time of day or night. The IT service provider discusses the basic levels of utility and warranty to fulfil this need and provide the value that the customer requires.

Service providers

You can’t set a strategy for your IT services unless you know what sort of IT provider you are. ITIL suggests three provider types:

Type I – internal service provider: A provider embedded within the business unit it serves. For example, the research and development department of a pharmaceutical organisation has such specialised IT needs that it employs an IT department to provide IT services exclusively to that business unit.

Type II – shared services unit: A single function that provides services to the whole organisation. This is a common form of internal provision. An example is a central IT department that fulfils the needs of all business units in the organisation. In this case, IT is often bundled with other departments such as HR and finance, and they work as a combined, shared-services unit.

Type III – external service provider: An organisation that provides services to external customers. A commercial business.

Overview of the Service Strategy Processes

As I explain in Chapter 3, a process is a set of activities coordinated to achieve a specific outcome. What follow are descriptions of many activities that are required to set and manage the strategy for your IT services. You don’t perform each process in isolation; you coordinate the processes to achieve an overall aim. Take a look at Figure 4-1 for a quick overview of the processes of service strategy.

The processes are:

Strategy management for IT services (see Chapter 11)

Service portfolio management (see the later section ‘Knowing Your Services: Service Portfolio Management’)

Financial management for IT services (see the later section ‘Managing Your Finances: Financial Management for IT Services’)

Demand management (see the later section ‘Identifying the Demand: Demand Management’ and Chapter 11)

Business relationship management (see the later section ‘Getting Friendly with Your Customers: Business Relationship Management’)

Knowing Your Services: Service Portfolio Management

Does everyone in your IT organisation know what IT services you’ve got? Do they know what new developments are in the pipeline? Does your organisation spend money in the right places? Do senior management have the right information at their fingertips to make good investment decisions? Put simply, service portfolio management is the process (set of activities) that manages your portfolio (the complete set) of services.

Defining some service portfolio management terms

No doubt you’re keen to know what service portfolio management entails. . . . The following sections give you the low-down, starting with an explanation of the service portfolio.

What’s a service portfolio?

According to the ITIL books, ‘The service portfolio is the complete set of services that are managed by a service provider’. A service portfolio isn’t just a list of services; it’s usually a set of software tools and databases you use to manage your IT services throughout the service lifecycle. The service portfolio is used to manage the entire lifecycle of all services, and includes three categories of service:

Service pipeline: This includes the services you’re thinking about, and those that are proposed or in development. So these are the services that are in the early stages of the service lifecycle, in the service strategy stage or possibly the service design stage. (See Chapters 5 and 6 for details on the design stage.) Services that are still in the service strategy stage are those that are proposed and have a business case created for them. Therefore a value proposition has been created and a cost–benefit analysis has been developed, but the decision about whether to approve and charter the service for introduction into the live environment has not been made. (For more on business cases and cost–benefit analyses, head over to the later section ‘Business case’.)

Service catalogue: This includes the services that are currently live plus those you’re preparing to go live: the services that are live or available for deployment. So the service catalogue contains services that have been chartered (approved and with money made available to develop them). Some of these services are live; others may still be in the service design or service transition (see Chapter 7) stages of the lifecycle. The service catalogue is often managed as a separate entity – see Chapter 5 for details of the service catalogue management process.

When your organisation starts to develop services, do you keep quiet and not tell anyone? Hopefully not. With any luck, you communicate your plans to the rest of the IT department and to the business or customer in order to prepare it for the new service. Think of the service catalogue as a selling aid in the same way that you go into a car showroom and the salespeople show you the catalogue (or brochure) of all the cars that are available for you to buy. Some of the cars may be sitting on the forecourt, and you can drive them away today, and some may have to be ordered for you, and you may have to wait. In fact, for new models, the car manufacturer may start advertising the new vehicle and take orders well in advance of the date when the car will be available. The IT service catalogue works in a similar way: some services are available now, some are available for deployment, and others can be ordered for delivery some time in the future.

The decision to move services from the service pipeline to the service catalogue is often made on a case-by-case basis – it’s a good idea to have a policy for how you make the decision in your organisation.

Retired services: This includes the services that you used to offer but have now withdrawn. It can be useful to keep information about these services in case they’re needed again in the future. As part of the service portfolio, the section for retired services allows you to manage the withdrawal of services in a controlled manner and also provides information about any assets (resources or capabilities) that have been released and can be redeployed elsewhere.

You may have come across the word portfolio in different contexts. Maybe you invest in shares in the stock market. If so, your portfolio consists of all of the companies you invest in. I suspect you also maintain information about the companies you’re planning to invest in, in order to decide on the right time to invest. You may also keep information about the companies you used to invest in, in case you want to reinvest. In other words, you keep information about your complete set of investments.

Figure 4-2 shows a picture of the service portfolio. It illustrates how developments to a service can be managed through the lifecycle by recording their status in the service portfolio. For example, when the new version of the sales service is moved into the live environment, it will be given the status of ‘operational’.

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

What’s service portfolio management?

The ITIL service strategy book describes service portfolio management as a dynamic method for governing investments in service management across the enterprise, and managing them for value. Sounds a bit grand!

In simple terms, service portfolio management enables your IT organisation to manage all your IT services as a complete set. This means you can understand where your assets are being used and which services consume most assets, both resources and capabilities.

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

Service portfolio management enables you to answer questions and make decisions about the entire set of services. What questions would you want to ask? Well, the service portfolio (see the previous section) should contain adequate information for you to be able to answer the following questions:

Why should customers buy these services?

Why should customers buy these services from us?

What are the pricing or chargeback models?

What are our strengths and weaknesses, priorities and risks?

How should our resources and capabilities be allocated?

Having answered the questions, you can now use the service portfolio to:

Make investment decisions

Prioritise investments

Manage resources

Approve the movement of services from one lifecycle stage to the next

The boundaries between the three parts of the service portfolio can represent milestones, or gateways, where the project stops and senior management make a decision about whether to continue, based on estimates of the time and cost involved.

Figure 4-3 is a suggestion of one of the outputs of a service portfolio – in this case, an overview of the services recorded in the service portfolio. I include the figure to give you an idea of some of the information that’s in the service portfolio. Please bear in mind this is just a rough sample; the service portfolio should contain a lot more information to help you manage your services.

Note how the payroll service is in the service portfolio twice. Each is a different version. So you can manage upgrades and new releases by using the service portfolio.

As a lot of service portfolio management is about making investment decisions, there are a couple of important aspects to take into account:

Financial aspects: You must look at the financial case. This involves reviewing the business case and looking at the return on investment (ROI). In other words, is it a sound investment financially speaking? In making this decision you use the financial management for IT services process. (See the later section ‘Managing Your Finances: Financial Management for IT Services’.)

Demand for the service: You must consider what the business need for the service is and understand how the business will use it. This can constitute a risk. If you don’t have a clear understanding of the frequency, duration and volume of use of the IT service, you can end up buying lots of expensive equipment or acquiring specialised resources only to discover that it’s not used. In investigating this issue you use the demand management process. (See the later section ‘Identifying the demand: Demand Management’.)

Based on ITIL® material. Reproduced under licence from The Cabinet Office.

Looking at the activities of service portfolio management

The following activities are normally performed in the service strategy stage of the service lifecycle. You can perform them on your complete set of services or just one service. These activities take the service to the stage where it has been approved and the resources identified and made available. Once the service has been chartered, it moves through the other stages of the service lifecycle.

In the service portfolio management process, the decisions to move the service through these subsequent phases – to approve the design (see Chapters 5 and 6) and promote the service to service transition (see Chapter 7) – must be made by senior management. Whenever management make such a decision, you update the service portfolio to change the status of the service and to allocate the necessary resources in the service portfolio.

The following sections look at each activity of the service portfolio management process in turn.

Initiate process

Because service portfolio management is the main means of managing new services and changes to existing services, and prioritising these investments, you must have a formal method of triggering these activities. Service portfolio management can be initiated in many ways such as:

Strategy management for IT services: This is the process that defines the strategy for your IT services. The strategy will provide guidance on which services you introduce, modify or retire. Deciding to act on your strategy will trigger the service portfolio management process. (See Chapter 11 for more about strategy management for IT services.)

Business relationship management: This process maintains a relationship with your customers and so will receive requests from them for new services or changes to services. (See the later section ‘Getting Friendly with Your Customers: Business Relationship Management’.)

Continual service improvement (CSI): CSI will identify initiatives for improving your services and processes; the investment will require authorisation. (See Chapter 9 for more about CSI.)

Other service management processes: Each service management process identifies options that need investment. Often these are initiated through change management. However, if significant investment is required, this should be handled through service portfolio management.

Define

As the name suggests, the define activities of service portfolio management define the IT service. You should maintain a standard set of information for each service, so that each time you add a new service to the service portfolio you collect the same set of information.

One key task is to establish a business case. Every service in the service portfolio must have a business case: the high-level business requirements of the service and a cost– benefit analysis that helps to establish the ROI of the service. (For more details, check out the section ‘Business case’, later in the chapter). The high-level business requirements include a description of the value proposition. (See the section ‘The value proposition’, earlier in this chapter.) The business case describes how the business will get value from the service in terms of utility and warranty.

For more information about defining IT services, have a look at Chapter 11.

Analyse

The analyse activities of service portfolio management analyse the service to establish its alignment with your strategy for service management. (The earlier section ‘Understanding the Purpose of the Service Strategy Lifecycle Phase’ covers establishing a strategy for your IT services.) You compare each IT service with your strategy to establish how well the service contributes to the achievement of the strategy. This provides a way of establishing the relative priority of each service, and enables you to carry out an investment appraisal of each service.

Approve

Based on the analysis of each service (see the previous section), you can decide whether to invest in the IT service now, or delay or reject the investment. If the answer is ‘invest now’, the service is approved and the service and resources are authorised.

The service portfolio management ‘approve’ activities will include a regular review of all services in the service portfolio, including those in the service catalogue. (There’s more on the catalogue in the earlier section ‘What’s a service portfolio?’.) For existing services, the outcome of the review falls into one of the following six categories:

Retain: Keep the service as it is.

Replace: Replace the service.

Rationalise: Make better use of the assets required to provide the service.

Re-factor: In cases where some of the functionality of the service can be better achieved by removing it to a different service.

Renew: A service that may require some technical updating.

Retire: Retire the service.

Approving change proposals

Having decided the general approach, when investing in new services or major changes to existing services, a change proposal should be submitted by Service Portfolio Management to Change Management for authorisation.

A change proposal is a document that includes a high level description of a potential service introduction or significant change, along with a corresponding business case and an expected implementation schedule.

The change proposal allows change management to assess the impact of the proposed change on other services and on the availability of resources. It also provides change management with advanced warning of the change (if it is authorised) and warns them to expect a number of requests for change (RFCs) to be raised to manage the introduction of the service and its constituent components.

Change management will assess the proposed design and resource requirements in order to discover if the new or changed service is feasible. This is only high-level work at this stage – the full design of the service will commence once the service has been chartered. The result of the assessment is either the authorisation or rejection of the change proposal.

Charter

Having made the decision to approve the service and commit the resources and capabilities necessary to develop it (see the previous sections), you must now communicate the decision and get the ball rolling. A charter is a document that contains details of the new or changed service and is used to communicate the steps, and the costs and benefits, to the organisation, and to plan to implement the approval. In many cases the ‘approve’ and ‘charter’ steps are similar to your project approval and project initiation activities.

Managing Your Finances: Financial Management for IT Services

IT isn’t free! Someone has to pay for it, or at least account for it. Do you budget in your personal life? You may think me sad, but I’ve been known to sit down and write a list of what I spend and what I earn. After I’ve done the calculations, I decide how much money I have left to spend at the pub.

The IT department never seems to have enough money, so you have to make sure you spend what you have wisely.

The purpose of the financial management for IT services process is to secure the appropriate level of funding to design, develop and deliver services that meet the strategy of the organisation.

Financial management for IT services acts as a gatekeeper to ensure that an IT provider does not commit to a service it cannot afford. To do this, financial management for IT services identifies the balance between cost and quality of service, and maintains the balance of supply and demand between the service provider and the customer.

Financial management for IT services provides the business and IT with the quantification, in financial terms, of the value of the IT service. To do this, it must quantify, in financial terms, the value of the assets that make up your services.

An organisation needs to know the cost of its services so that it can secure the funding for them. If your organisation is a commercial organisation, it recovers the cost of the services by charging for them, and hopefully makes a profit. If you’re an internal provider delivering IT services to other people in the same organisation, you must forecast what it will cost to provide the IT services and you must ensure that the budget is available.

Financial management for IT services provides data and information to enable the forecasting of the operational costs associated with providing and operating the IT services – it aggregates financial information. This means that financial management for IT services is like a sponge. It collects and soaks up, from across the organisation, information about the costs of providing and managing the IT services. It then slices and dices the information into an understandable format so that it can be used by all of the IT department to make decisions about how to provide better management of the IT services.

Creating a cost model

A cost model is a framework which allows the service provider to determine the costs of providing services and ensure they’re allocated correctly.

Cost models can be used to allocate costs in many ways: by department, by customer, by location or by service. For example, what does it cost to provide IT services to the sales department (cost model by internal customer), or what does it cost to provide the email service (cost model by IT service)? It depends on your organisation and its policy how you do this. The cost of a service is the sum of its parts, those parts being the assets that make up the service – hardware, software, people, and so on. To understand what it costs the IT provider to deliver the services, you need to know the amount of assets used in each case. Not all assets are dedicated to a single service; some are shared. I’m sure in your organisation some hardware is shared between services, for example the network is usually used by many services. Similarly, IT staff (you and your colleagues) no doubt work on several IT services – so how will you allocate their time? Your time and effort should be accounted for and allocated to one or many services. I’m sure you’ve experienced the joy of filling in time sheets!

To make things easy, classify your costs as:

Direct costs: those that are used exclusively for a service or customer. For example, the server hardware that is used only for the email service will have its cost allocated to the email service.

Indirect costs: costs that cannot be allocated to a single service are shared costs. For example, the service desk costs are shared among the services or customers that use the service desk.

Classifying costs in this way makes it easier to understand where each asset is used and how it should be accounted for. These costs are inputs to your cost model. Another classification is used to separate out the day-to-day costs from the large purchases or investments:

Capital costs: these are usually large purchases such as servers and network equipment. They are assets that your organisation keeps for a long time and which will provide value for a number of years. For this reason, finance departments usually allocate, or spread, the costs over a number of years. You’ll hear this special allocation referred to as depreciation. Depreciation is the measure of the reduction in value of an asset over its life.

Operational costs: the operational expenditure resulting from running the services on a day-to-day basis, for example staff costs, maintenance costs and overheads such as electricity. Once spent, this money is gone – it has no future value.

By far my favourite cost model is the one that calculates the cost of providing each IT service – cost by service. When you know the total cost of providing the IT service, you can decide how best to charge for the service or how best to account for it.

For example, what’s the cost of providing the email system to all your users? Table 4-1 gives an example. First you decide which components form part of the email service. You identify the assets that are dedicated to the service (direct costs). For those components or assets that are shared (indirect costs), you decide how to share the cost. Then you add up the cost of the assets to get a total cost for the email service.

Table 4-1 Calculating the Cost of Providing an Email Service

Asset	Amount Used for Email (%)	Cost Per Year (£)
Server hardware (direct)	100	40,000
Server software (direct)	100	10,000
Network usage (indirect)	25	5,000
Engineers – for technical support (indirect)	20	18,000
Service desk staff – to deal with incidents and requests (indirect)	15	12,000
Total cost of providing the email service		85,000

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

Table 4-1 is simply an example of part of a cost model; it’s not the complete model. In real life it is more complicated.

All this calculating could become very complicated. However, think about what happens if you get the calculations wrong. If your organisation is a commercial supplier of IT services, and someone miscalculates the cost of the services, your organisation may not recover its costs and could lose money. Not a good thing.

Creating a business case

ITIL describes a business case as a business support and planning tool. A business case is usually a document that describes the reasons and costs involved in a course of action. Organisations use a business case to justify the expenditure on a project. The main section of a business case is the cost–benefit analysis: an analysis of the costs and benefits of the project.

As an example, the sales department has asked the IT department to develop a new customer relationship management (CRM) service. This involves a new software application along with the related hardware and support. Have a look at Table 4-2, which shows what this cost–benefit analysis might look like.

Table 4-2 Example Cost–benefit Analysis

Benefits	Improve ability to identify customer needs £100,000 per year increased sales from identifying new customer opportunities
Costs	£50,000 cost of developing new software application £30,000 cost of hardware upgrades £20,000 per year additional support costs
Risks	Software not completed on time Lack of expertise of related technology Availability of business staff to identify requirements

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

Here’s a suggested outline for a business case for a new or changed IT service:

Introduction: Set the scene and link the project to the business objectives.

Methods and assumptions: Provide the scope of the project.

Business impacts: Describe the benefits to be gained and the costs that will be incurred: a cost–benefit analysis.

Risks and contingencies: What may go wrong, and how you can get around it.

Recommendations: Give specific actions.

In the service portfolio management process (which I discuss in the earlier section ‘Knowing Your Services: Service Portfolio Management’), one of the main activities is to decide which services to invest in. One of the main inputs to this decision is the financial cost of the service. For each new service or significant change to a service, you must calculate the costs involved and the financial benefits. You produce a business case so that the service portfolio management process can compare the financial aspects of various proposed investments and help senior management make a decision.

Looking at the activities of financial management for IT services

The main activities of the financial management for IT services process are:

Budgeting: Getting hold of the money. You predict how much money you’ll need next year to provide the IT services, and then you try to secure the money. Your cost models provide a useful structure for predicting costs.

The budgeting activity can turn into a bit of a game, with each department in the organisation competing for its share of the corporate pot. So you must have a clear understanding of what it costs to provide your services, and how costs may change in the coming period. This means you must find out what the business plans are. Does it intend to expand the business, contract the business, add more staff? Consider anything that may affect the use and cost of the IT services.

Accounting: Calculating the costs – working out where the money has gone. You put structure in place and code the stuff you buy (and get rid of) so that you have an accurate record of what you’ve spent. The structures are often suggested by your organisation’s main finance department, but you may have to change some to suit the types of IT expenditure. Much of this structure is provided by your cost models.

Charging: Deciding whether and/or how to charge. If your organisation is a commercial one then you charge for the IT services with the intention of at least breaking even, and hopefully making a profit. If you’re providing IT services to internal customers (people in the same organisation), you don’t have to charge. In some cases the financial department does some funny stuff to account for the IT budget. In other organisations the internal IT department does charge. This helps staff and customers understand the cost of IT and sometimes influences how the business uses the IT services.

If you do charge you must have a clear understanding of what it costs to provide the service – see the earlier section ‘Creating a cost model’.

Identifying the Demand: Demand Management

Where does the demand for your IT services come from? How do you know when and how often your IT services will be used? The answer is: from the business. Your IT services are only used when the business needs them. Users only use your email system when they want to send a message. The sales department only uses the sales ordering system when one of your organisation’s customers contacts the sales department to place an order. Therefore, the IT services must work when the business needs them, not the other way around. Your users don’t use the IT services simply because they exist. They use them because they fulfil a need. So if you want to know how much of a service is needed, you have to look at the business activities that the service supports.

The IT department of a manufacturing organisation is running low on network bandwidth at the busiest times of day. In order to share the available network capacity the sales department is asked to reduce the number of sales orders it receives from customers between 10:00 and 12:00 a.m. What do you think the sales department’s response is!

If you were managing a supermarket, how would you decide how many staff to put on the checkouts each day? How do you know how many staff are required? Hopefully, you identify the busiest times for the supermarket, when most customers visit, and then match the number of staff at the tills to the ebb and flow of the customers throughout the day. Of course, what is the consequence of getting this wrong? A queue builds up. Not a problem; you may say, when a queue forms I’ll put more staff on. Well, if you don’t have spare staff in the building already, you won’t be able to cope. The queues will get longer, and some customers may not return. On the other hand, if you ask a lot of staff to come in just in case, there may be nothing for them to do.

The moral of the story is that you have to plan ahead and do your best to predict the busy times.

The purpose of the demand management process is to understand, anticipate and influence customer demand for services, and to work with capacity management to ensure the service provider has capacity to meet this demand.

Demand management gets involved in every stage of the service lifecycle to ensure that services are designed, tested and delivered to help achieve the business outcomes at the appropriate levels of activity.

Demand management provides an important input into service portfolio management by helping to decide the risks associated with investigating new or changed IT services. You can’t manufacture IT capacity in advance and store it for later use, and excess capacity generates cost without creating value. Therefore demand management:

Establishes whether demand exists for a service

Contributes to the business case for a service (see the earlier section on the business case)

Ensure that the cost of production is factored in to the cost of the service

Defining some demand management terms

Here are a couple of bits of terminology used in the ITIL books.

Pattern of business activity

In the words of the ITIL books ‘A pattern of business activity (PBA) is a workload profile of one or more business activities. PBAs are used to help the IT service provider understand and plan for different levels of business activity’.

Business processes are the primary source of demand for services, so identifying the usage of the business processes establishes patterns for the usage of the services – PBAs. You need to identify, analyse and document patterns of usage of business processes, and in doing so you identify the demands that business processes put on the IT services.

Record the following information about the PBA:

Frequency: How often this pattern occurs in the business

Volume: The amounts of activity; for example, how many sales orders are processed in one day

Location: Where in the organisation the business activity takes place – which department, building or country

Duration: How long the PBA lasts

A theatre ticket agency wants to be sure it has enough telephone operators to handle the demand for ticket requests for concerts and shows. It monitors its customer activity to discover the peaks and troughs of demand. The agency discovers that 70 per cent of customers request tickets on the first day of release, and that demand slowly decreases over time. However, the agency notes that within two weeks of the event, demand increases again. This fluctuation in demand is the PBA.

You can read more about PBAs and see some examples in Chapter 11.

User profile

The ITIL books say ‘A user profile is a pattern of user demand for IT services. Each user profile includes one or more PBAs’ (see the previous section).

A user profile is a combination of many PBAs. User profiles are based on roles and responsibilities, and are typically used to group PBAs into common activity groups. So a user profile represents a typical work profile of a user.

For example, a member of the sales team has three main business activities:

Contacting customers – for which he or she uses the customer relationship management IT service

Taking orders – for which he or she uses the sales ordering IT service

Creating invoices – for which he or she uses the financial management IT service

Each activity is associated with a PBA, which tells you how often and when the activities are performed. By combining the three PBAs you get a good idea of all the business activity performed by the salesperson and hence the demand for all three IT services. The IT department can now use this to calculate the extra load each new salesperson will put on the IT services.

Looking at the activities of demand management

Understanding PBAs helps you to plan and manage the services throughout the lifecycle:

Service strategy: Identify the services and outcomes and the associated PBAs. Using the service portfolio management process you can approve investments for additional capacity, new services and changes to services.

Service design: In the service design phase (see Chapters 5 and 6) you can optimise the design of the service to suit the demand patterns. Availability management and capacity management will identify the assets needed to meet the PBAs.

Service transition: Demand management is a valuable input to testing and validating services to ensure that they can meet the demands of the PBAs.

Service operation: Technical staff will monitor the service to ensure that service levels are met. If necessary, they’ll make better use of resources by adjusting the allocation of resources and consolidating demand.

CSI: Demand management can identify trends in the PBAs over time that may give rise to improvements and changes.

The demand management process encompasses many activities. Here is a brief description:

Identifying sources of demand forecasting: The information that allows you to identify PBAs can come from many sources including business plans, marketing plans, production plans and sales forecasts.

Identifying PBAs and user profiles: Unsurprisingly, the activities that identify PBAs and user profiles (see the previous section).

Activity-based demand management: The activities involved in identifying the capacity requirements of a service from the analysis of the business activities that are enabled by the service. So, you analyse how and when the business does what the business does, and then you use this to predict how much IT capacity you need: how much server power, network bandwidth and disk storage, and how many software licences and possibly staff to support the service.

Activity-based demand management involves:

• Identifying PBAs

• Grouping them into user profiles

• Documenting and coding PBAs so all of IT can use them to manage various aspects of the service

Developing differentiated offerings: By identifying and understanding PBAs, you may detect that your customers require different levels of service at different times of the month or year. By working with the service portfolio management process, you can identify different service packages matched to the needs of the customers.

Management of operational demand: Generally speaking, the IT organisation has to ensure that services meet the service level targets agreed with the business. However, sometimes you may use demand management at a tactical level to influence the users to use the service when you want them to use it.

Take the example of telephone service providers. You often get a deal in which evening and weekend phone calls are free. They’re giving them away! Well, the majority of phone usage is in business hours, so the phone companies have to have enough kit and staff in place to fulfil business usage. In the evenings and weekends, when most businesses have gone home, the phone companies are left with spare capacity that costs money. It’s better for them to appear to give it away for free than not have it used at all. By charging you less, or nothing at all, the phone companies hope to balance out the demand so that all in all they make better use of their resources. So, you can do the same. If you have limited capacity at certain times, you can agree with your customers that you’ll charge less if they use it at off-peak times. However, be warned: customers must agree. Customers mustn’t perceive the off-peak agreement as the IT service failing to provide a proper service.

If you want to know more about demand management, turn to Chapter 11.

Getting Friendly with Your Customers: Business Relationship Management

Business relationship management pretty much does what it says on the tin: it aims to build a relationship with the customer. Why would you want to do that? Surely customers are best kept at arm’s length aren’t they? Well, I argue that you need to know what your customers want. Service management is all about identifying what customers need, agreeing it with them and then delivering the service. So it all starts with the customers.

Business relationship management has a duty of care to customers. It makes sure that the needs of customers are taken into account in all service management activities, to ensure that customers will be happy with the outcome.

The purpose of the business relationship management process is two-fold:

To establish and maintain a business relationship between the service provider and the customers, based on understanding the customers and their business needs

To identify customer needs (utility and warranty) and ensure that the service provider is able to meet these needs as business needs change over time and in different circumstances

So the business relationship management process provides a focal point for customers in order to identify opportunities to provide value to customers in the form of services. These opportunities may be identified by the customer, such as the launch of a new business product that needs the support of a new IT service. Opportunities can also be identified by the IT provider; for example, the use of emerging technology such as cloud computing services, that may allow the customer to perform business processes more effectively and efficiently.

The service provider must understand how the customers’ needs change over time, and the business relationship management process will provide this information. Business relationship management needs to be pragmatic: it must ensure that customers’ expectations do not exceed what customers are prepared to pay for, and that the service provider can actually meet the customers’ expectations before agreeing to deliver the service.

In this section it’s important to be clear of the distinction between the customer and the user. If you’re not sure how this distinction is viewed by ITIL then have a look in Chapter 2 for more details.

A user is a person who uses the IT service on a day-to-day basis. A customer is someone who pays for the service or agrees the level of service.

Explaining the terminology

There are one or two bits of terminology that it is useful to get out of the way first.

What’s the difference between business relationship management and service level management?

You may notice some similarity between business relationship management activities and service level management (SLM) activities. (You’ll find SLM described in Chapter 5 – so go and have a quick look if you like.) But it’s more straightforward than you may imagine. Business relationship management is the overarching process. It maintains a relationship with the customer from cradle to grave and deals with many types of contact. On the other hand, SLM manages service levels. SLM gets involved once a service has been chartered, develops the service level agreements in conjunction with the customer and the business relationship manager, and ensures that the service is provided in accordance with agreed service targets.

Customer portfolio

A customer portfolio is a database or structured document used to record all customers of the IT service provider. The customer portfolio is the business relationship manager’s view of the customers who receive services from the IT service provider. So the customer portfolio is a resource that provides details of all the customers to whom you provide services – a useful source of information.

The customer portfolio is defined and maintained as part of the business relationship management process.

Customer agreement portfolio

A customer agreement portfolio is a database or structured document used to manage service contracts or agreements between an IT service provider and its customers. Each IT service delivered to a customer should have a contract or other agreement that is listed in the customer agreement portfolio.

For every customer to whom you provide a service there is an agreement. Hopefully there should be a written agreement: an SLA for internal customers and possibly a contract for external customers. It’s likely that the SLM process will have some involvement in maintaining the customer agreement portfolio.

The benefit of a customer agreement portfolio is that everything is in one place. This means that a service provider can review and compare its commitments to all its customers.

The activities of business relationship management

There are two overarching activities of business relationship management which encompass all the activities of business relationship management:

To represent the service provider to its customers through coordinated marketing, selling and delivery activities

To work with service portfolio management and design coordination to ensure that the service provider’s response to customers’ requirements is appropriate; this process facilitates customer advocacy throughout the lifecycle

Funny word advocacy, isn’t it? In this context it means that the business relationship management process will ensure that the interests of the customer are represented in all service management activities.

Business relationship management is not a single end-to-end process but a number of sets of activities performed in response to a particular trigger. The type of activities these are depends on the trigger and the situation. For example, if the customer contacts the business relationship manager requiring a change to be made to a service, the business relationship manager will facilitate the completion of a request for change (RFC) and submit it to the change management process.

Initiating business relationship management

There are many triggers for the business relationship management process. However there are some important occasions in which business relationship management needs to get involved.

It’s important the customer has a point of contact for all requests, be they requests for new services or changes, or other requests. The use of the business relationship management process should provide customers with the confidence that they have a contact with the service provider and that their requests will be followed up.

Opportunities: Customers may have new needs that can be fulfilled by a service, or the IT provider may be able to offer customers an opportunity that they can take advantage of. The business relationship manager will make sure that the customers’ needs are explained well and that the IT provider gains a good understanding of the value (in terms of utility and warranty) that the customer wants to achieve.

RFCs: RFCs are one of the main methods used by service management to get things done. The RFC form (as designed by the change management process) should be easy to use. However, there will be occasions when the business relationship manager will act as a facilitator to ensure that a customer’s requirement is expressed in the clearest way and subsequently understood by the service provider.

Complaints and compliments: Both complaints and compliments provide an opportunity for a service provider. Complaints provide a possible opportunity for improvement. Compliments may provide conformation that the service provider is providing the service as required and is achieving customer satisfaction. In both cases, there should be an agreed method of handling this type of contact with the customer.

Business relationship management through the service lifecycle

The activities of business relationship management vary depending on which part of the lifecycle the service has reached. It’s part of the purpose of business relationship management to represent the customer’s interests throughout the service lifecycle. The following are just a few of the possible activities of the business relationship management process, organised by the stage of the service lifecycle:

Service strategy: Primarily identifying opportunities, but this can also involve specifying strategic requirements and funding, defining outcomes and business cases, or validating PBAs

Service design: Validating requirements; ensuring the customer is appropriately involved in design activities

Service transition: Coordinating customer involvement in service transition, in other words testing, release schedules, training

Service operation: Communicating scheduled outages, providing updates on major incidents, and providing an escalation point

CSI: Reporting service performance, conducting customer satisfaction surveys, and initiating service improvement plans

Using Technology for Service Strategy

ITIL emphasises the use of technology in helping you provide the IT services to your customers. The following sections look at two areas: the use of technology to support the service strategy activities, and the use of automation throughout the service lifecycle.

Technology to support the service strategy activities

You can use many software packages to support the service strategy activities:

Service portfolio management: With a quick exploration using your favourite Internet search engine you can discover many service portfolio management tools. These store information about your services, making it easier for you to make decisions about them.

Financial management: You can use a simple spreadsheet package to manage your finances. In larger organisations this can prove impractical. Many software packages are designed for managing finances.

Demand management: You need to understand and model the PBA. (See the earlier section ‘Defining some demand management terms’.) For simple calculations, you can use a spreadsheet. Or a quick Internet search reveals many tools designed for complex modelling.

Automation

Automation refers to the use of tools and technology to automate the activities of service management. You can use automation in many ways, from planning staff resources like shift patterns, to using network management tools that can automatically reconfigure infrastructure equipment to cope with peak business demands. Here are some other examples:

It’s possible to automate service management process flows, such as by routing incidents to second-line support.

Users can select ‘standard’ services from an electronic service catalogue; this self-help takes the load off the service desk, leading to better use of resources.

You can set up the system to automatically raise an RFC when a monitoring tool discovers an unauthorised component in your infrastructure.

Your organisation should have a strategy for how you use automation to support IT services. There may be some activities that must be performed by a person and should not be performed by a computer program. These should be decided and documented.