# Mathematical subtleties of modelling opex

28 January 2010

At least 50% of a service provider’s costs relate to operations and maintenance, as opposed to basic capital expenditure. Sadly, many business models are left with rough estimates for these aspects – often estimated as a rule-of-thumb percentage of the capital cost – rather than being modelled explicitly via any kind of task analysis.

In fact, the STEM resource concept is just as readily used to capture activity costs, such as spares or staff costs, as it is to represent capital costs. There are just some areas where care has to be taken when mixing absolute and incremental quantities, and when switching between annual and quarterly results.

This article illustrates some of these points through a series of examples which may serve to stimulate existing thinking on the topic, and also offer specific techniques for those actively involved in this kind of modelling. It also highlights one specific area of confusion, and suggests a potential solution which could be added into STEM to round out this capability.

Consider a Switch resource which requires regular maintenance to attend to recurring faults or typical unplanned incidents.  Since this is driven from the total installed base, this is relatively easy to model, using two basic ingredients:

• a transformation combines user data assumptions for the annual rate of fault incidence and the average number of hours required to correct a fault, to calculate an annual fault hours result (which you can think of as an instantaneous annual rate)
• an Engineer resource derives its capacity (as a matching instantaneous annual rate) from user data assumptions for weeks per year, hours per week and effective utilisation.

Matching estimated task hours to engineer capacity

This approach works fine, even in a quarterly context, because only a quarter of the salary cost is charged each quarter.  An increasing salary can be modelled with a cost trend; and a learning curve effect could be modelled within the Average Correction Hours per Fault input, factoring in a floor and (decreasing) multiplier. The engineer may also be shared by different types of equipment.

Annual task hours and required engineer capacity

An engineer working 48 × 37.5 hours a year, at a utilisation of 80%, could result in some of the 1440 annual hours being left slack. Alternatively, if the engineer is shared from a company pool, then you could use a lower hours-per-week assumption to define a lower capacity. Or, if the engineer is sub-contracted, it might be more appropriate to define the costs as an operations cost that would only arise from actual usage, even if the hourly rate might be higher for this kind of ‘pay as you go’ approach.

The traditional flaw of this kind of modelling approach is its direct sensitivity to the fault rate assumption, but scenarios may be used to estimate best and worst-case requirements.

## Adding dependent staff and support assets

The standard technique of using a transformation with a basis of resource installed units can be used to model a variety of dependencies from the engineer, such as administrative support, manager and vehicle resources, each of which may be characterised with a capacity measured in (supported) engineers. In a more complicated model, these secondary support resources might be shared by different types of engineer, or the engineer resource might be shared by different types of equipment. Some of these resources may need to be separately based at more than one physical location, readily modelled with the usual STEM deployment concept.

Secondary support resources and opex breakdown

## Handling short-term contracts

One potential issue, which arises if demand is falling, is that a STEM resource has a defined lifetime (currently not less than one year), and so you may end up with an engineering cost for a few quarters after a switch is no longer required. The same issue would apply to customer support staff resources if demand was falling each quarter.

One obvious fix for this would be to allow a lifetime less than one year – though it is not clear how this would work in a model running in years. But it might be preferable to be able to say that a resource could be a ‘transient asset’ which would disappear as soon as it is not required (perhaps equivalent to setting Redundant Unit Decomm. Prop. = 1), or better still, to have a release time which could capture notice-period effects.

Another approach would be to think of the capacity of a resource in terms of an absolute number of tasks that need to be done in a period, and for such a resource to only ever exist within one period (of whatever size). This idea is explored in more detail below in the more general context of incremental effects.

## Quantifying installation engineer time in an annual model

So far we have been looking at activities related to total demand or installation, as these can be readily matched to an instantaneous annual effort rate. If we constrain our attention to models running exclusively in years, then it is also straightforward to model equipment installation rates and required manpower levels, again in two stages:

• incremental units of the same Switch resource can be scaled by hours per installation to calculate the annual hours required, which can be used as the capacity of an installation engineer
• an Engineer resource derives its capacity (as  a matching instantaneous annual rate) from user data assumptions for weeks per year, hours per week and effective utilisation (just as above).

Installation-rate and annual fault-rate transformations

But the implicit assumption that the incremental units can be matched to annual capacity falls to pieces in a quarterly or monthly context, as we shall see in the following examples.

## Interpretation issues for incremental quantities in a quarterly or monthly model

Consider two cases: one unit installed in each quarter versus four units all installed in Q1. In the first case, if we want to match to a resource with a capacity specified as an annual rate, we would need to scale up by factor of four in a quarter to get the same share of a permanent resource; i.e., to say that we need 40 hours in a year if we are to have 10 hours in each quarter. (Bear in mind that only a quarter of the salary is charged each quarter.) This can be achieved by using the periodLen() function in a formula for the multiplier.

In a case where all the incremental units are in the first quarter, then this would be fine if the resource capacity did not persist beyond the quarter. It makes sense that 40 hours would be required in that quarter: potentially more staff are being employed on a shorter contract.

But how should the Output result be consolidated (i.e., presented in annual format when a model has been run in quarters or months)? In general, it is assumed to be instantaneous (as per most demands in STEM), and so we take the value from the final period in a year; but this would completely hide the transient in the case of everything being installed in Q1. So STEM is currently coded to accumulate an incremental units basis during a year specifically to avoid this problem. But then this leads to too much capacity of the resource being required in later quarters, if the periodLen() approach is used to scale up the demand in Q1.

Alternative representations of quarterly incremental demand

## A potential solution for comment

Suppose instead that we were to introduce an aggregate-mode transformation (or output), which would not cumulate over the year, and which would be consolidated by summation. This would not be able to use the periodLen() approach, as the output for a quarter should relate only to the increment in that quarter (and would be summed across quarters on consolidation), but STEM could understand that the periodLen() scaling should be built in when matching such an aggregate demand to instantaneous capacity of a resource. That is, the demand (derived from incremental units) would be 10 hours in the quarter, and this would turn into a requirement for 40 hours per year instantaneous capacity of a resource. (Or we could also introduce an aggregate-mode resource whose costs would be associated with aggregate demand in the current period only, and not scaled as a proportion of a year – this is the concept of a ‘transient’ resource mentioned above.)

Matching incremental output to annual capacity required

For the Results program to know how to consolidate such an output, we could have two types of transformation; or, more manageably (and with much more general clarity), we could add a second, Incremental Output basis for transformation outputs. So you would choose which basis was being used when linking from a transformation.

Transformation output bases and related consolidation modes

For single input transformations, you could infer the mode from its input; whereas an expression transformation would have to specify the user’s intention. The resource Incremental Units basis would be an aggregate input, as would service traffic (volume) and revenue (as opposed to the currently scaled Annual Traffic and Annual Revenue bases).

Either the ‘other’ mode would be left at zero; or perhaps more usefully, a standard output could be cumulated from incremental output within a year as per the current incremental units basis, and an aggregate mode could be inferred as a delta of two consecutive periods?  This needs more thought.

However, separating these two outputs and classifying them properly would enable STEM to make more meaningful and reliable calculations which would make sense in both annual and quarterly contexts, and more generally any combination of periods which might be required.