15 May 2012

More on our recurring theme of ‘consumption’!

The new consumable resource concept, implemented in STEM 7.3, adds a new dimension to the range of costs which can be modelled in STEM. Conventionally, a resource had a persistent capacity which could be used in an ongoing sense from one period to the next, such as the maximum bit rate of a broadband link, whereas now you can also model more transient items whose capacity gets used up – literally consumed – as time goes on.

Many operational quantities, such as power consumed or engineer hours required, can now be modelled more intuitively in absolute terms rather than obliquely in terms of an equivalent annual rate, so the STEM paradigm can also be applied to a wider range of production-based industries in addition to the more static infrastructure-based businesses such as telecoms.

This slightly tongue-in-cheek example, inspired by a client birthday at last year’s User Group event, nicely illustrates the difference between eating a slice of a consumable cake once (at most) and ‘having a persistent cake resource and eating it’ – again and again and again …

Consider a requirement to host a monthly celebration at which cake must be served to a certain number of guests that might vary in time. Based on an average size of slice, a cake may be characterised in terms of the number of slices it offers, and the demand may be estimated in terms of an average appetite measured in slices per guest.

To keep the numbers very simple, our example imagines for now that each guest requires precisely one slice of 12 from a €20 *Chocolate Cake*, and that there are 15 guests at the first event, increasing by a factor of two over the first year.

In the following results you can see that, initially, two cakes are required and consumed each month, and that the leftovers are written off as it really wouldn’t do to keep a chocolate cake hanging around for a month.

If the participants are concerned about their waistlines and general health, then they may very well not have another slice of cake ‘just because there is some left’. So we may want to worry about the fact that, in general, there may be a portion of cake left over after any one of these monthly events.

Even though the STEM model engine is designed to cope with run periods as short as a single day, the current user interface offers a month as the shortest period length which may be simulated. Thus we will have to consider a fruit cake like Stollen for this residual capacity to be still appetising! If we substitute a resource with a three-month lifetime (another new option) at the higher unit cost of €25, then you can see that STEM keeps track of the capacity that has been already used up (literally eaten up!) and only buys the next cake when the first is all gone, resulting in zero write-off if there is sufficient ‘turnover’.

Now we replace the 12-slice Stollen with a 60-slice Large Stollen at the more efficient price of €100 (25% cheaper per slice, equivalent to the cost per slice of the Chocolate Cake). With the same number of guests, a cake bought in January is good for February and March too, with only the leftovers discarded at the end of their ‘shelf life’ in March necessitating the purchase of a new cake in April. By the time we get to September, all of the current cake has been consumed and a new one must be purchased ahead of time.

The cake resources illustrated are set with the new input Capacity Mode = Consumable to signify that their capacity gets consumed on a one-off basis according to aggregate demand in the current period.

Surprisingly, this example would have been virtually impossible to simulate in earlier versions of STEM, principally because the original resource concept was for persistent capacity (such as the bit rate of a broadband link) which could be used non-destructively from one period to the next.

The established workaround was to think in terms of a rate of cake consumption; to consider the requirement from a service in terms of slices of cake per annum, and to define a cake resource in terms of the cost of consuming a certain number of slices per annum. Thus if our service requires 15 slices of cake in the first month, then the equivalent rate would be 180 slices per annum. For a 12-slice cake expecting to be consumed once each month, the equivalent persistent resource would have a capacity of 144 slices per annum, and sure enough we would get two installed units in January … and the same two units would still be there in February servicing the slightly higher demand. A third unit would then be required when the annual rate required exceeded 288, as it would in the October modelled.

With unit cost inputs defined at twelve times the original monthly cost, you would get the correct results scaled back as STEM would only charge one twelfth of the nominal annual input per month. However, if you wanted to capture the cost of the leftovers, you would need to use a fully-allocated maintenance cost; but then you would end up paying for the cake all year even if the demand subsided. And even if you had previously been allowed to define a one-month lifetime, what if you wanted to run your model in quarters?

The problem is that, intrinsically, a cake is not a facility (which you can eat and eat again) but a transient thing which you consume and then it is gone. As there are many operational costs with similar characteristics, such as power consumed or sub-contracted engineer hours required, we have taken the trouble to extend the STEM paradigm to allow for consumable resources to be modelled explicitly and for their supply to be matched to an aggregate demand flow.

These more orthodox examples are covered in the new documentation supplied with STEM 7.3 Beta 2, and we will make an extensive showcase of this new functionality at the next STEM User Group Meeting in October 2012.

Our 21^{st} business-modelling event featured a reference framework for
modelling the IT value-chain in a web-scale enterprise, as well as a menu of operational
tasks around SDN/NFV written on a matrix of skillsets and pay grades.

© Implied Logic Limited