In part 1 I covered some of the basic terminology of Activity Based Costing. In this entry, I'll apply these principles to storage costs.
First, some general observations.
Making Costs Manageable
To make costs manageable, it's desirable to be able to predict, for every volume of output, the needed costs to support that output. Do nothing; costs nothing. Do X; costs Y, And ideally, if I do 2X, it costs no more than 2Y.
To do that, we need to get rid of fixed costs and turn them into variable costs. (See part 1 for definitions.) The difference between a fixed cost and a variable cost is one of time period; taken over the long run, all costs begin to look variable. Shorter time periods, and they tend towards fixed. I'd suggest a sensible window here; say 3 years (although in the current economic climate, that feels like a very long time indeed).
Fixed costs, especially indirect fixed costs, are the enemy of good cost management. In general, we want to turn fixed costs into variable and indirect costs (a cost not associated with a specific activity) into a direct cost.
We also want our variable costs to act "sensibly". So, for instance, we want 2X to be less than cost 2Y; we want to achieve economies of scale.
[That leads into a separate issue, one not covered here.
"Thus, while a decision to increase its scale of operations may result in decreasing the average cost of inputs (volume discounts), it could also give rise to diseconomies of scale if its subsequently widened distribution network is inefficient because not enough transport trucks were invested in as well."
The effect is well known to IT capacity planners and performance analysts; remove a bottleneck (for instance, IO bandwidth on a SAN) and it simply pops up somewhere else down the line (network bandwidth to deliver the data).]
Storage Cost Drivers
- Capacity; the request for space
- Performance; IO bandwidth the need for speed
- Availability; access frequency and times of access to the data
- Activity; writing and reading the data
- Reliability; Recovery, Backup & Restore
- Archive; retaining the data
That's a high level list, but there's one thing to note here; these are from the consumer's perspective. These are activities that drive your costs, so management of storage isn't included here, because it's not a driver. Users don't care how you manage, and it's not something they measure.
This is a pretty simple model. For instance, the category Archive might be broken out into sub-categories, which I won't do here.
Cost of Storage Example
Let's take a simple example.
Department X requires to store and retrieve engineering drawings. They've estimated the following;
- Capacity. Files are on average 10MB in size, with an initial requirement of 2TB of space. Growth is anticipated at 20% per year (400GB).
- Performance. Low to medium requirement. CAD software loads one file at a time. Engineers will wait for several seconds for a file load or save. No IO requirement while it's being edited.
- Availability; access to current and the last 30 days versions of drawings is required during normal weekday work hours
- Activity; anticipated 10 CAD workstations with a new or modified existing engineering drawing every 20 minutes.
- Reliability; 30 days backup, 1 hour granularity, self recovery preferable.
- Archive; every engineering drawing and version must be archived for at least 10 years.
The next in the series will take this example and map the drivers to the costs.
