STEM has its origins in the modelling of voice and data networks where the cost of investing in an expensive network is balanced by the subsequent revenues accruing from services for hauling traffic via the long-term, persistent capacity of network resources.
Classic network dimensioning is usually done in terms of the expected maximum instantaneous requirement for capacity in a relevant busy period, whereas there are more general modelling situations which may demand relationships based on aggregate demands or flows, such as the number of call minutes in a month. This is particularly the case in the context of detailed opex models in which you may wish to calculate a volume of tasks in a given period or a demand for consumable resources such as spares.
In an annual model, the distinction between a volume of tasks in a year and the equivalent instantaneous annual rate is academic, but this cannot be ignored if you want a model to run in quarters or months.
In versions of STEM prior to 7.3 it was possible to model certain regular operational events working always in terms of an annual rate, but this was much harder to get right for an incremental basis such as one-off setup tasks when a resource is first installed. Moreover, the results program would always consolidate the output of a transformation using an end-of-year value rather than aggregating over quarters or months. Hence it was really impractical to work with any explicit measure of actual events in a period.
In addition, as resources were originally designed to represent persistent capacity, a resource to represent a capacity of tasks per year would persist for at least a year even if a network set-up was completed in only three months; therefore you had to be careful to only work with costs based on used capacity to avoid incurring costs when the initial activity was complete.
These issues only began to be understood after the shorter time period functionality first introduced in STEM 6.0 had been in circulation for a while and it has taken a further two years of more recent conceptual wrangling to implement a comprehensive solution. STEM 7.3 finally allows for aggregate demands to be properly classified and correctly consolidated in the Results Program, and it also implements a
consumable resource
concept in which costs are generated as the demand aggregates in a period (such as spares required), causing the capacity of such a resource to be ‘used up’, period by period. A simple example of such a resource would be actual power being consumed in any given period. A more complex treatment exists for cases such as a supply of spares bought in packs of 100 (or whatever) where there is a disconnect between the cashflow impact of purchasing the spares and the recognition of the cost at the time of consumption for accounting purposes.