Charting the IT chains of value

7 Mar 2013 •

In this latest post on a service-oriented operating model for IT I will cover mapping out the IT value chain. There are quite a few steps which lead up to this point so start here if you want a reminder and don’t forget these warnings.

So let’s get started with:

what are IT value chains all about,
why you need to take the time to map them and
how do you use them.

What is an IT value chain?

The concept of value chains has been around for a long time and the ideas are not specific to IT. At its most basic level a value chain is a model of a business unit’s functions, connected by processes which transforms raw inputs into products and services which are delivered to customers. The classical representations of value chains are based upon manufacturing businesses but the idea can be applied to any organisation including the IT department, as in the example below.

The original reason for looking at value chains was to analyse how costs and value flowed in order to optimise the business as a whole system. Extensions to the basic approach explore value chains beyond the target organisation to include the value chains of suppliers, partners, competitors and customers. Although it is now common practice the first manufacturers who moved into leasing and financial services were taking advantage of their analysis to take a greater share of the value available in these extended chains.

In IT we also want to look at the extended chain and not just model functions which are normally associated with IT. In general, IT activities do not generate any value in isolation so we need to map out how they support the value generating functions in the wider enterprise. In practice, it is quite hard to extend this model to include suppliers, partners and external customers but they do need to be considered, especially if your end products and services are digital or delivered digitally. We will also want to capture the interfaces between the functions as this is where we will find the services which will form the basis for our service-oriented operating model. As mentioned in my earlier post there are a wide range of modelling techniques available so feel free to use the ones that your team are comfortable with as long as you make sure they model your extended value chain and expose the key interfaces or services.

Why map IT value chains?

There are several reasons for doing this kind of work:

Value chain mapping helps confirm what the IT services should be and the context in which they will be provided. Without the chain model there is a danger of defining services around existing IT functions or organisation structures which may be convenient for the IT department but less than optimal for the enterprise as a whole.
Including the wider enterprise helps to identify what changes outside of IT’s direct control are needed to make the new operating model work. The value chain will often include feedback loops and mutual dependencies such as the need for demand forecasting and joint planning which will require business changes to be coordinated with the changes to IT.
Just as in classic value chain analysis the model helps make well informed priority decisions by linking IT services to business outcomes even if, initially, these are qualitative links rather than quantitative. The priority decisions that are needed may be about the long term allocation of resources to IT services or about how best to phase the transition to the new operating model.
In common with other types of modelling the value chain mapping will expose key assumptions about how IT works, help evaluation of alternatives and capture explicit decisions. A typical example concerns how IT services are shared, or not, between business units or regions in a large enterprise.

How should you use an IT value chain?

The are many potential uses for value chains but the key areas in the context of designing the IT operating model are:

Stakeholder engagement
Preliminary testing
Service enumeration
Sourcing strategy
Future change management.

A common element in each of these series of blogs is stakeholder engagement and once again this is a key focus of value chain mapping. Collaboratively building the model with stakeholders will make sure that the IT team understand how the IT services they provide impact the wider business and will help the consumers understand how IT services support their critical operations.

Good practice process or system modelling techniques will support a degree of desktop or conference room testing. While mapping out the current (as-is) situation this testing will help make sure the set of functions and the links between them are complete. Later the value chains for the new operating model (to-be) can be tested to help make sure they are robust and will be able to cope with the demands that will be placed upon them.

It is at this stage that the full list of IT services becomes clear and these will be the foundation for the later stages of detailed design. It will become clear where different regions and business units will share common services or where specific variants are required. Value chain analysis will also expose where several related services need to be coordinated to meet a requirement. A common example is where project or case work is required to fulfil a business request.

Value chain mapping will expose requirements and options that will form inputs to the sourcing strategy. There will be some services and products that few organisations will consider delivering internally such as supply of commodity equipment and standard support for off the shelf software. There will be further candidates where individual services or packages of services could be provided by internal resources, outsourced or obtained through some kind of partnership. Finally, there will be services where some internal capacity is provided to cover the baseline level of demand and external resources are used to address peaks in demand or specialist requirements. Demands from project work is a common example where this kind of hybrid sourcing is chosen.

The value chain map will provide a foundation for much of the work required to design and transition to the new operating model. Once the changes have been implemented it would be wise to maintain the map to support future changes. In the event of significant business changes, such as mergers or expansion into new markets, an up to date value chain map will provide a short cut to establishing how IT needs to the change too.

From services to materials

In the next post I will explain how we move from the conceptual model provided by the IT value chain to the more concrete IT bill of materials. In the meantime, add a comment to let me know what you think or use the Twitter button to let me know what you think.

Related Blog Post: Strategic value chain mapping by @swardley (Worth browsing the series not just this example post)