A month in the life of a consumable resource

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 …

1. Cake that must be eaten up today

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.

Figure 1: Aggregate monthly requirement for cake and corresponding capacity in slices

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.

Figure 2: Increasing cake efficiency, at least until a third cake is required each month

2. Cake that may last for a few months

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’.

Figure 3: Residual slack capacity is used up ‘next month’ before the next cake is purchased

3. A bigger cake may supply several months at a time

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.

Figure 4: Residual slack capacity is used up ‘next month’ before the next cake is purchased

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.

4. Having your cake and eating it – again and again …

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.

A radical re-think on STEM pricing

We announce a new freemium strategy for accessing the STEM software, including a free and fully-functional demo system for small projects and study as a taster for an innovative minimal-support subscription to the Conventional STEM (C-STEM) desktop solution at just GBP 330 p.a..

Read the article

STEM User Group Meeting 2017

Our annual customer forum on 27–28 September 2017 will see us build a generic business case from scratch, comparing the approach of a fixed resource base with a more agile, driver-based approach. We will generate all the essential technical and financial outputs while exploring the impact of varying levels of service activity.

Read the article

Vision for the forthcoming STEM 8.0

As part of our vision for a more intuitive way of working that bridges previous mental leaps wherever possible, we preview another two features of the forthcoming STEM version 8.0 – direct-draw connect mode and more flexible user data – that form part of a joined-up approach to fulfilling this dream.

Read the article

Win a student group subscription in our quarterly competition

We are now offering an affordable package for educational groups to access the fully-fledged C-STEM platform which will enable teaching staff to connect their students with the issues of scale and complexity that they will face in real life, as well as a quarterly competition to win an annual subscription for the most interesting modelling proposal.

Read the article

Using a partition to ease discovery of a model

A collection is a neat way to group elements and provide systematic aggregation across all results available for those elements, and can be nested to form an element hierarchy. We are working on a new partition concept which checks a hierarchy for completeness and uniqueness, and enables a top-down results navigation where you can expand and drill-down into individual branches.

Read the article

Tracing drivers with smart results in the Editor

Suppose it were easier to connect results with what you can see in the Editor, or that STEM could anticipate which results would be of most immediate interest. Soon you will be able to display results from the context menu for a selection of elements in the Editor. A new Trace command will draw the most pertinent graphs to explain the calculation flow for a series of elements.

Read the article

Exploring cost-breakdown results in conjunction with template replication

The interface for drawing graphs has been streamlined in STEM 7.5 with dimensional selection as the norm, and more specific Linear Selection of individual combinations when required. We consider the complexities of notation, selection and spareseness, and show that STEM is the go-to application for handling cost allocation and controlling organisational spending at scale.

Read the article

STEM User Group Meeting 2016 proceedings

Our 21st customer event was held on 05–06 October at King’s College, Cambridge, UK. New and regular users alike engaged in animated debate on two dominant themes of network virtualisation, as well as further game-changing developments in the STEM platform. The full proceedings of the 2016 event are now available for download. Next year’s event will run 27–28 September 2017.

Read the article

       Buy SSL

© Implied Logic Limited