Activity-Based Cost: Blocking and Tackling First

Over the past two decades, Activity-Based Cost has grown from an obscure almost novelty costing methodology to a commonly accepted cost management methodology. One evidence of this is the plethora of supposedly new variations. Most of these variations result from marketing efforts to distinguish one software or consulting provider from the pack. Yet, the common problem of any company striving to improve its profitability through better cost management is not the particular variant but failing to adhere to basic underlying principles of good Cost Management.

First, let’s review several common Activity-Based Cost variants. Then we’ll consider the violation of basic principles.

Variant number 1 – Grouping expenses. One variant is to group multiple expense accounts into one larger bucket before assigning these resources to activities. The idea is to group expenses that behave similarly into one assignment. Some would call these groups “Cost Pools”. However, I do not like this term as it evokes images of many old and very bad cost allocation practices from the past.

This variant is not really unique as most consultants and software solutions have either incorporated this ability directly or assumed that any grouping is already done before importing the cost into their application. The only places that I have observed assignments from each individual expense account have been in simple training illustrations, academic publications, and in models created by inexperienced modelers. Otherwise, they only show up in marketing presentations to show how much better their approach is in comparison.

This capability is a threshold or minimum capability. In modeling situations, we do not want to be spending too much time modeling excessive details.

Variant number 2 – Capacity considerations. Capacity considerations can be extremely important in business decisions. Knowing where excess or idle capacity is indeed important. Capacity is a topic near and dear to my heart. I co-authored the book, “Capacity Measurement & Improvement” on this topic.

However, the problem in modeling capacity is knowing when to include capacity into modeling concepts. To obtain the benefits of capacity information, additional detail and data is required to model capacity. If the organization is just starting to move into Activity-Based Costing, the additional data requirements, training requirements, and acceptance are often too much for the organization to accept all at once. This may aggravate change management considerations. So, don’t bite off more than you can chew.

Variant number 3 – Demand driven requirements. In my opinion, a cost model that is responsive or dynamic to the demand of products, services, and customer requirements is utopia. When this state is achieved, the door opens to many additional uses and decision inputs. The ultimate model is one where the volumes of products can be forecasted and the model then generates resource requirements and costs “auto magically”. Some software companies tout their ability to do some form of this.

However, to achieve these benefits, there is a modeling cost. Instead of using observable actual usage quantities, the model must incorporate consumption rates. It is often difficult to fine tune these consumption rates so that the resulting information is relevant and accurate. For example, if the demand on an activity is for one million outputs, a rate difference of .001 is one thousand. In fact, a static model is the best standard against which to calibrate a dynamic model. I could, and have, written a book on this also.

Here again, this is not an area for a first model. Keep the vision of utopia in mind but work on climbing the foothills first.

The modeling principle most often violated is to follow cause and effect. In a cost management forum, a member asked how to allocate the cost of Information Technology or IT to profit centers. Just asking the question in this manner shows that the questioner has not analyzed the work that IT does for its customers. Is their effort directed at maintaining current systems? Which ones? Is IT developing new systems? For whom? Is IT supporting personal computers? Who uses the personal computers? Are there differences in how IT’s internal customers use IT’s services? You bet there are.

Another modeling principle is to match the level of detail to the decision requirements. This one is actually a difficult balance. However, far too many modelers assume that more detail provides more information. This is false. To be information, data must be appropriate to the decision that needs to be made. Again, there is a cost to modeling excessive detail. Here it may be better to start modeling at a higher level of aggregation with less detail. Then, as the model is accepted by decision makers and their requirements evolve, add selective detail to the model. Far too many modelers start with excessive detail before they understand the cost to maintain that level of detail.

Providing good cost information to profit decisions is an art. Moving from no cost management or poor cost management to meaningful and actionable cost management is a challenge. While most variants of Activity-Based Cost are attractive, they come at a cost. If you’re just starting your journey, start simple and follow good basic principles. Then add features and capabilities once the benefit is worth the cost and you’re ready to take the step. As in learning to swim, start in the shallow end of the pool rather than on top of the Olympic diving platform.