STEM newsletter

How does cost allocation work?

30 July 2002

This article on the cost-allocation mechanism in STEM is written as one in a series of how-to articles intended to raise both awareness and understanding of the tool, emphasising the immediacy of the results, the scale of the calculation addressed (compared to a spreadsheet), and the surprising detail generated by the system and its latest developments.

STEM is designed to model the economics of network dimensioning

Real-life services offered to customers and the underlying network assets and functions are modelled with the familiar STEM Service and Resource elements, providing a consistent framework for the accounting of revenues and drill-down into capital and operating cost streams. These financial elements are related through a series of causal relations, in which the demand from a Service is mapped onto a Resource on the basis of either connections, peak traffic or (occasionally) traffic volume (when considering interconnect costs). Complex and secondary relationships are implemented via Transformation elements which may generate multiple layers of cost.

Where a single Service or Transformation requires multiple Resources, STEM ensures the straightforward accumulation of these costs in order to calculate the total cost of provision. The issue of cost allocation must be addressed where multiple Services require a common Resource, e.g. sharing the backbone network, or where a Transformation aggregates several separate demands. Here we capitalise on the description of a STEM model in terms of its structure rather than its formulae. The calculation framework for demand (which is generated at run-time by inference from the relationships defined in the Editor) also forms the basis for the cost-allocation mechanism.

Where a Resource Requirement causes demand to be mapped from a Service (or Transformation) to a Resource, a record is kept of the Service’s ‘total use’ of the capacity of the Resource. It is this usage, as a proportion of the total capacity used by all Services or Transformations, which defines the proportion of costs arising from the Resource which should be allocated to the Service. Where an Expression Transformation aggregates demand from multiple inputs, any Resource costs allocated to this Transformation are sub-allocated between its inputs in equal proportions by default, with options to:

  • weight the allocation according to the respective scale of the demand inputs
  • weight the allocation according to another basis, such as revenue
  • assign specific proportions to each input.

Weighting backbone cost allocation by service revenue

Because this all happens ‘automatically’, the STEM framework delivers an immediate awareness of service unit costs; and because the approach is systematic, the modeller can have absolute confidence in the integrity of the results.

DIY is more than twice the effort

In order to understand how this all works, it is instructive to consider how you would ‘do it yourself’. Conceptually, the process is (and must be, for auditing purposes) quite straightforward, but while a single measure of demand may drive the effective requirement for equipment, there are many facets to the complementary cost allocation.

Firstly, each Resource may contribute multiple costs under various headings: depreciation and maintenance for fixed assets, or connection, rental and usage costs for leased assets. While allocated in the same proportions, these must be manipulated separately in order to preserve the overall accounting separation at the Service level.

Secondly (and optionally in STEM), if you have taken the trouble to model the lifetime costs of an asset to reflect its age, e.g. a unit maintenance cost which ‘switches on’ at the end of a three-year manufacturer’s warranty, then it may be preferable to pass this age distinction on to the service level, so that new equipment installed specifically for a new service may present a ‘new equipment’ cost rather than a cost averaged over the existing network. In order to achieve this goal, not only must the costs of different installation ages be calculated separately, but of course they must be allocated separately too. In STEM this is a natural extension of the ‘use record’ methodology outlined above; the spreadsheet equivalent is left as a mental exercise for the reader.

Allocating multiple cost streams, ages and classifications

Thirdly, some key distinctions will be made between the allocated cost of equipment capacity which is used directly by a service, and slack capacity which exists either as planned redundancy or as a natural consequence of equipment unit capacities. In order to compete on price, it is imperative for an operator to determine the cost of the ‘efficient’ network, and thus, at the very least, to distinguish between the allocated costs of used and slack capacity (see below for more detail).

So for each line of demand calculation in a comparable spreadsheet, a far bulkier paraphernalia will be required to implement the required cost allocation for each layer of a model. Not only must you work out how to do it, and invest the time to do it, but then you must also take the time to verify that the outcome is as intended, and that the results calculated add up.

The depth of analysis is being actively extended

One intention of this article has been to clarify the extent to which cost allocation is a natural and intrinsic part of the STEM calculation cycle. In fact, STEM has performed these calculations for Services for over a decade, and cost allocation was a critical part of the specification process when Transformations were introduced in the early 90s. However, the development process is always ongoing and we are currently implementing a number of extensions specifically designed to enhance the cost-allocation analysis.

Direct cost results

The existing used and slack cost results in STEM distinguish between the costs of used and slack capacity of a Resource. For example, the Used Maintenance Cost result for a Service is the share of maintenance costs from the used portions of all Resource capacities allocated to that Service. This represents the cost of equipment which, if removed, would directly compromise the network's ability to carry that Service, as opposed to the cost of slack capacity, which reflects the combined cost of planned redundancy and network inefficiency. The sum of these used and slack costs represents the fully-allocated cost of providing the Service.

However, the concept of used capacity depends partly on perspective and the local context within a model. Suppose that one connection for a Service requires one port on a 100-port switch, and that each switch requires a single-switch management interface (MI). With a demand of 50 connections, a single switch will be 50% utilised, but the single MI will appear to be 100% utilised if it is dimensioned on the basis of unit capacity with respect to installed units of the switch. It is certainly true that, without the MI, the network will not function, whereas the network would be fine with fewer ports on the switch.

So, the MI used cost will be the same right up to 100 customers, whereas it will be more useful to understand the underlying cost per connection when considering how the costs of the network will scale as demand grows. We are therefore now implementing a new class of cost results, labelled ‘Direct Costs’, which are a refinement of allocated used costs to allow for the utilisation of equipment generating a secondary cost. In this example, the full used cost of the MI is allocated back to the switch, but only 50% of this is then allocated back to the Service as a ‘direct’ cost. These new direct-cost results are more closely variable with the underlying service demand and will provide a better indicator for long-term tariffing decisions.

Used and direct costs compared

Intermediate slack results

As this article has explained, the allocation of used costs is implemented through each Transformation in a chain of demand in a model. Rather than mirror this framework for the costs of slack capacity, a Service’s responsibility for the slack capacity of a Resource is calculated according to its direct and indirect historical usage of that Resource, and then the slack costs are passed directly to the Service in proportion to the comparable responsibility of other Services. Thus slack results are only available for Services.

Where a network is modelled in several natural layers, e.g. service offerings mapping down onto service capabilities, perhaps mapping further down onto network functions and underlying transport, then it may be insightful to measure fully-allocated (i.e. used plus slack) costs at an intermediate level. We are now trialling an extension in which a Service could replace an intermediate Transformation in order to generate intermediate slack costs, while retaining the Transformation behaviour of allocating costs back to the primary services. This would reflect a kind of internal value-chain; but whereas the existing value-chain feature in STEM is designed to model the re-sale of an external commodity, mapping secondary revenues on to primary costs, this would be naturally interpreted as an internal cross charge.

Intermediate Resource / Service pairing defines internal cross-charge boundary

Note: the algorithm for allocating slack capacity is described in the feature entitled Cost Allocation in the Model Features volume of the STEM User Guide.

Breakdown of Service results by Resource

The primary goal of these cost-allocation mechanisms is to calculate the most pertinent unit cost for external service offerings, but a secondary initiative will be then to analyse the breakdown of these costs by Resource in order to identify the best targets for cost-reduction measures. This has been a longstanding objective for STEM, and one delayed partly by concerns over the potential size of the Service / Resource results set, and the challenge of a workable user interface to restrict it.

However, some recent analysis suggests that in fact it may be possible to infer a manageable and sparse subset of this space from the typically sparse set of Resource Requirements defined within a model, and we now hope to produce a prototype system in the next few months which would produce the following key results for a Service:

  • breakdown of separately allocated costs by each Resource directly or indirectly required by the Service
  • breakdown of sub-total allocations by each Resource directly required by the Service.

In a model where intermediate Resource / Service pairs are used to define layers, then such a pairing would limit the scope of the separately allocated breakdowns to a single layer.

Determining the scope for Service cost breakdown by Resource

© Implied Logic Limited