Why cost alone is a weak measure
Central functions such as IT, finance operations, HR, procurement and facilities rarely sell anything. Their budgets show up as overhead, which makes them an easy target when savings are needed. Cost is simple to measure and easy to compare, so it dominates the conversation.
The difficulty is that cost says nothing about what the money buys. A low-cost function might be efficient, or it might be under-resourced and quietly passing problems to the business units. A high-cost function might be wasteful, or it might be handling complex work or reducing risks that never become visible. Cost needs company.
Three layers to describe
It helps to separate three things.
- Inputs: the money, people and tools the function uses.
- Outputs: what the function produces, such as tickets resolved, invoices processed, people hired or purchase orders placed.
- Outcomes: the difference this makes for the organization, such as less downtime, fewer payment errors or quicker onboarding.
Cost is an input. Volumes are outputs. Value is mostly found in outcomes, which are harder to measure and often depend on factors outside the function’s control. A good description of a function uses all three layers rather than only the first.
Measuring the cost side honestly
Even the cost side takes care. Questions worth settling:
- Which costs are included: salaries, software, shared facilities, a share of management time?
- How are shared costs allocated across functions? Different allocation rules can produce very different numbers.
- Are one-off project costs separated from running costs?
- Is the comparison over time on the same basis?
Many organizations use total cost of ownership thinking for systems and apply a similar mindset to services. Where an organization allocates costs to its internal customers, chargeback and showback approaches can make usage and cost visible, though they bring their own debates about fairness and administration.
Ways to describe value
There is no single formula that captures the value of a central function. Several complementary approaches are in common use. Each has limits, and combining them tends to be more convincing than relying on one.
Unit cost and volume. Cost per transaction, per user supported or per employee served shows how efficiently routine work is done. It works best for repetitive, countable activities. It is less useful for work that varies in complexity, and a falling unit cost can simply mean lower quality.
Service levels and quality. Measures such as timeliness, accuracy and rework rates show whether the function delivers to an agreed standard. Internal service levels that people actually use give these measures a common reference.
Stakeholder feedback. Surveys and conversations with internal customers describe how the service feels to the people who rely on it. This is subjective but important; internal customer feedback also reveals problems that operational numbers miss. Be cautious with low response rates and with a single score used alone.
Risk and continuity. Some value is in what does not happen: fewer security incidents, fewer compliance findings, faster recovery. Such value is real but difficult to quantify. It is usually better described in plain terms, such as what the exposure would be without the function, than given an invented monetary figure.
Enabling effects. A function may allow others to work faster, such as a finance team that shortens approvals or an IT team that enables a new product. Attributing business results to the enabler is tricky, so treat any claim as an estimate and show the reasoning.
Comparison. Comparing against past performance, against similar functions elsewhere in the organization, or against external alternatives such as outsourcing can provide perspective. Comparisons need like-for-like scope, or they mislead.
An illustration
The figures below are invented to show the thinking, not to suggest benchmarks.
Suppose an internal support function costs 600,000 per year and handles 12,000 requests. Dividing gives 50 per request. Next year the cost is 630,000 and requests are 14,000, giving 45 per request. Unit cost has fallen, which looks like good news.
But a fuller picture asks more: Did the average time to resolve change? Did satisfaction change? Did more requests get reopened? Did the mix of requests change? If simple requests grew while complex ones shrank, a lower unit cost may reflect easier work. Cost per request is a starting point for questions, not a verdict.
Pitfalls
- Single-number scoring. Reducing value to one score hides trade-offs and invites argument over the formula.
- Invented return figures. Claims of precise savings, built on assumptions nobody can check, damage credibility. Describe assumptions openly and use ranges where you must estimate.
- Rewarding cost cutting. If the main target is a lower budget, quality can erode in ways that appear later. The article on target side effects explains how this happens.
- Ignoring the cost of centralization itself. Central functions can add layers, slow local decisions and create dependency. A fair assessment includes these, and may conclude that some work is better done locally.
Keeping it practical
A workable summary for a central function can fit on one page: what it costs, what it produces, how well it performs against agreed standards, what its internal customers say, and what risks it manages. Reviewing that page on a regular schedule, alongside operations metrics selection and honest discussion of trade-offs, usually does more good than a complex valuation model.