If you asked a restauranteur how much of their costs were represented by power and light, you’d almost certainly get a confident and accurate answer. Similarly, ask a train operating company how much they pay to network rail for the use of the track and stations and you would also expect to get a knowledgeable answer.
But ask an insurance company how much their IT-based CRM system costs and you might be surprised at the vague response. Ask a food retailer how much their warehouse management IT system costs and they might have an indication but are unlikely to have a reliable number.
For clarification, we are not talking here about how much is spent on IT or how much is the CRM application licence fee – this is known. No, it’s the lifetime cost of the SERVICE that includes the licence fee, the amount spent on people support from the application maintainer to the service desk, the cost of servers and databases, etc.
In our experience, surprisingly few organisations have even attempted to cost their services; are we the only industry unable or unwilling to do so?
The Service Costing Challenges
The reason why we aren’t doing this is firstly because the value of doing so is largely unrecognised and secondly because it is actually quite hard to do. Let’s look at the challenge of service costing first.
There are two pre-requisites: having a service catalogue and a configuration management system. Our estimate is that only 5-10% of in-house IT departments have produced a business service catalogue (rather than a technology architecture map masquerading as a service catalogue). Then we are pretty sure that fewer than 5% of organisations can, hand on heart, say with any confidence that not only have they recorded information about their IT assets, but have mapped the relationships between them and the services they support in a configuration management system (CMS) – and have it up to date.
The reason why the catalogue and CMS are necessary is to be able to separate and apportion the costs of shared technology assets such as the network to specific services.
What is a Service?
The definition of a service is, ‘A means of delivering value to customers by facilitating outcomes they want to achieve without the ownership of specific costs and risks’ (ITIL). This ability to deliver value is a function of all the service assets used to manage and deliver the service. If we take just one asset category, hardware, this would include the server(s) that host the application and databases, the network components including the LANs and WANs, the PCs belonging to the application maintenance team, etc.
On the assumption that you have successfully defined your services (that’s the relatively easy part: the author wrote the Philips Electronics service catalogue in 1988!) the approach to service costing is straightforward enough. On a spreadsheet, put the services across the top then identify the service assets on the vertical axis. The assets are likely to be represented in a multi-level model, i.e. level 1 = hardware, level 2 = network, level 3 = router or switch.
This will result in a table similar to the simplified example below:
Next, you need to apportion the cost across each of the services that uses the asset. This is NOT an exact science, at least as far as shared assets go. You will have to make assumptions about what proportion of the asset(s) should realistically be attributed to a particular service.
By way of an example, take the cost of the people on the Service Desk. You might propose that the proportion of their costs that you attribute to a particular service be dependent on the number of calls and emails associated with that service – a realistic approach. But someone might suggest that calls associated with this service typically take longer to handle than those associated with another service. In this case you might therefore have to look at call minutes.
As you can imagine, it is relatively easy to achieve paralysis by analysis. The good news is that the apportionment of costs by service has only to be realistic and based on defendable (and documented) assumptions, rather than accurate to three decimal places. Remember you are only trying to achieve a realistic apportionment of a known total spend (the IT budget).
Why Service Costing?
Here are five reasons why you might want to consider putting in the effort of costing your services.
- Establishing the Value of IT
- Achieving ISO/IEC 20000
- Improving control of IT Costs
- Supporting Capacity Management
- Knowing when to retire or replace a service
With regard to the first reason, let’s assume you work for an electricity utility. If the profitability of the utility is 10% of turnover and each IT employee costs on average, £50k per year to employ (salary plus overheads) then the utility needs to sell a staggering £½ million of electricity simply to cover the cost of one IT member of staff. Can that staff member say what they’re doing to help generate, distribute and sell that electricity?
If not, how is IT adding value to the business? This is one of the most common challenges we hear from IT leaders. Of course, from our earlier comment, the value of IT is defined by the services that IT provides. But it also depends on the cost of those services in relation to the value that the business receives from them. The service catalogue can identify the services, the cost apportionment can identify the service cost. This is therefore the basis for understanding and quantifying the value of IT.
Achieving ISO/IEC 20000
The ‘ITIL Standard’ as its colloquially (and incorrectly) known, mandates service costing. Quite simply, unless you can demonstrate to the auditor the basis of how you cost services, you won’t achieve or maintain the Standard. For an organisation that differentiates itself on the Standard or for whom it is a pre-requisite for winning business, service costing is not an option.
Improving Control of IT Costs
The basic equation used to calculate IT spend couldn’t be simpler:
Volume x Rate = Spend
The rate is set by the service provider (the IT department) and can be validated through benchmarking or market testing as being competitive. The volume represents the business’s use of the service, but to be meaningful, needs to be expressed in units that the business can understand. For instance, in terms of processing, this might be an online order transaction (rather than the number of processor cycles). In terms of storage, it might be a sales record recorded (rather than the number of bytes). In terms of printing, it might be an invoice printed (rather than the number of print lines or pages).
With service costing in place, we can therefore show each business department how much it spends on IT in a far more meaningful way than by the number of people or PCs it has. Service costing allows the IT department to provide a dummy or ghost invoice showing the spend per department per service.
We therefore need to add to the service costing table the definition of a unit of service consumption to be able to calculate the cost per unit of consumption. With IT usage measured in business rather than technology units, this then provides each business department with the ability to control and predict its IT costs; typically one of their biggest challenges.
Supporting Capacity Management
Once the units of consumption have been defined in a way that the business understands, each business department can forecast how its use of the IT services will vary over the coming accounting period. For instance, if the intention is to acquire new customers, every new customer acquired will result in an additional CRM record and increase the number of sales transactions.
The costing spreadsheet or model can then be used in reverse by capacity management to determine which assets are needed to support these activities, when asset capacity will be reached and how much more of it will be needed and when.
Incidentally, applying a rate to this prediction will form the basis of the budget and each departments’ own budget, further improving cost control.
Knowing When to Retire or Replace a Service
One of the challenges IT has faced since it came about was knowing when and being able to retire a service. Classically, this was almost impossible even if there was only one remaining user of the service. With service costing, we have the ability to apportion the costs of a service to the department or departments using the service. As the usage decreases, the business incentive to retire or replace the service increases in proportion to the unit cost of consumption and can be compared to the equivalent cost for a new or replacement service.
The obvious benefit for the IT department is that retirement or replacement becomes a business decision, not an imposed IT decision.
Infrassistance is a consultancy and training company specialising in IT service management. We work with organisations of all sizes around the world and in all industry sectors, helping them optimise the management of IT services and the corresponding business benefits.