Activity Based Costing

Introduction

The other two papers in the series cover an Introduction to Activity-Based

Cost Management and Practical Applications of Activity-Based Costing.

All three papers in the series, as well as additional reference material on ABC

and other related subjects, are available from www.algsoftware.com.au 

When you implement activity based costing (ABC), remember that you won’t be

the first organization to do so! Many other businesses have already adopted an

activity-based approach to their management process, and their experiences

have shown that a number of considerations and issues have to be faced.

This paper discusses the most frequent of those issues.

This paper is part of a series of three developed to help you understand activitybased

costing (ABC) and activity-based cost management (ABM). This, the

second of the series, discusses the major issues that often face ABC

implementers.

Number of Activities

One issue often faced – ironically, usually by those who have embraced the ABC

concept most enthusiastically – is the temptation to build an activity list that

goes down to too fine a level of detail. There are practical problems associated

with modeling too many activities: models take longer to calculate, maintaining

the activity list is an administrative nightmare, and classifying activities to

identify wasted activity becomes a more onerous job.

But more importantly than that, adding more detail doesn’t give betterinformation. When a model contains thousands of activities, it’s difficult to hone

in on the pertinent information; you can’t see the wood for the trees. Many of

the activities will have insignificant amounts allocated to them. All in all, it’s

better to consider how the activity analysis is going to be used before the

activities are defined, and then to choose a level of detail that is appropriate.

For a strategic analysis, it is probably sufficient to work with as few as 20 or 30

activities (though in reality these would probably be at a high enough level to be

classified as processes rather than activities). Simple division of the process cost

by a suitable driver gives a measure, which can be used to compare the same

process in other companies or for investigating possible outsourcing decisions.

And if you subsequently decide that you want to expand the analysis to, say, 50

or 75 activities, then it’s reasonably easy to do that without fundamental

upheavals in the model.

For tactical modeling, you need to work at a more detailed level. This is a must

for investigation of wasted cost, because it becomes necessary to analyze

activities related to error correction, duplication and waiting. It’s also needed for

product, customer and channel costing, because you need the detail so that you

can apportion different activities to different combinations of activities using

different cost drivers. A typical tactical model might analyze between 200 and

300 activities and perhaps 10 or 20 drivers.

Business process improvement requires activities to be analyzed at a low level –

perhaps down to task, or, more likely a combination of task and activity level. If

the whole business is to be examined, this sometimes results in over a thousand

activities.

Figure 1 sets out the possible applications of activity cost information at the

different levels of detail.

One starting point is to develop a relatively simple strategic ABC model, which

can point management in the direction of areas that need attention. More

detailed modeling exercises can then be run, focusing on those areas of concern.

If you are interested in cost effectiveness, however, then at some point you need

to be modeling at the tactical (activity-based) level, because otherwise you can’t

identify those activities that add value and those that don’t.

Selection of Activity Drivers

One of the most difficult parts of ABC implementation is the identification and

selection of suitable drivers. One of the reasons for this is that what drives a

particular activity may not be immediately apparent. For example, the driver for

the chase customers on telephone activity could be the number of overdue

invoices, the value of overdue invoices, the number of calls, or some other

measure. Furthermore, although the obvious driver to this activity might be the

number of overdue invoices, the root cause might be faulty goods causing

customers to delay payment.

As a general guideline, using the “root cause” driver usually gives management

the most useful information.

Especially in the early phase of ABC implementation, it may not be clear which

driver is most significant. It often does not become clear until after the activity

cost has been calculated, but if your software solution is flexible enough, it is a

simple enough job to switch an activity from one driver to another. So this

needn’t be a problem, but you need to be open to the idea that you may, and

probably will, have to change your assumptions about driver assignments, and

should choose a solution that allows this easily.

Another potential pitfall is that, even where a driver is clearly important, the

driver data may not be easily available. The data may not be recorded

anywhere or there may be no resource available to extract it from the IT

systems, so you must be prepared to compromise and perhaps use a different

driver, even if only temporarily, until the appropriate data can be extracted or

can start to be collected. To alleviate this somewhat, it is often advisable to

start driver collection early. Experience shows that getting hold of the driver

data is often a bottleneck in ABC projects, and starting early not only minimizes

the risk of this but may also allow the business to start collecting data that it

doesn’t currently track.

You can maximize the benefit of your work by adopting a few simple principles

when it comes to choosing activity drivers. Firstly, try to limit the number of

drivers. You can probably choose 10 or 20 that fit most activities, especially the

most costly activities. For a few low cost activities, the benefit of spending a lot

of time and effort getting data for a few esoteric drivers isn’t likely to be worth

the trouble. For those, assign the “best fit” driver from the remaining list, or

accept that the activity has no relationship with customers or products and treat

it as unallocated.

On a similar tack, when collecting data, prioritize your time so that you

concentrate on the drivers of most cost.

If you need to, it’s quite valid to estimate the most important drivers. Where a

driver is in the top 10 but data is not immediately available, use the experience

of the management team and staff to estimate the volumes, or if appropriate

you might sample the data for a short period to provide an estimate of the

annual driver volume. Although estimates and samples are less than 100%

accurate by definition, it is better to have information, which is useful and nearly

right rather than no information at all. As long as managers and staff who are

close to the process are involved, the estimates will prove to be remarkably

accurate and certainly good enough to produce a reasonable allocation of cost to

customers and products.

Design of the Activity Dictionary

The activity dictionary is more than just a list of activities; it also acts as a

template for collecting the time spent by staff on activities. So in addition to

providing an input to the model building, it becomes a valuable resource during

the data collection stage. This section discusses the various principles that

govern the construction of a useful activity dictionary.

A design workshop should be held where key managers meet to discuss and

agree a set of processes and activities that are to be modeled. This is extremely

important, not only because it allows the project to benefit from the business

knowledge and experience of those managers, but also because it educates the

managers in the methodology and allows them to appreciate the reasons for the

project, thus encouraging their full participation and cooperation with the

conclusions of the analysis.

During the workshop, you should remember what we discussed in the previous

section about the number of activities, and limit the level of detail to what is

required and what will provide the necessary results at the end of the analysis.

More detail than is necessary will result in a cumbersome model that is hard to

maintain and from which conclusions will be hard to draw. Also remember the

salient points about identifying activities that are related to process failure. If

you want to make process improvements as a result of the ABC analysis, it is

important that the activity dictionary includes waste activities such as error

correction, duplication, waiting, checking, and transportation.

Getting hold of good quality activity driver data is a frequent obstacle to

successful ABC modeling. The design workshop should carry out an initial

allocation of drivers to activities and then attempt to reduce the number to a

maximum of, say, 20. Get all managers involved to review the original choice of

drivers to agree whether it is really the cause of the activity.

Sometimes you won’t be able to obtain the right information for your first choice

driver, so you should be prepared to compromise. Where a lot of activities are

known to be caused by a driver for which data will not be available, and no

alternative “best fit” is available, the activity can be split by customer/product

group in the dictionary and managers asked to estimate the split when

completing the dictionary. This is illustrated in Figure 2 on the next page.

 

Choice of Modeling Tool: Spreadsheet or ABC Software

There is, simply, no getting away from the fact that some sort of software

solution will be necessary. The first question is whether an investment in a

dedicated ABC tool should be made, or whether it’s possible to get away with

building your own spreadsheet-based solution.

For a high-level, strategic model, it’s just about possible to get away with a

homemade spreadsheet solution. For a prototyping, proof-of-concept exercise,

aimed at establishing the methodology and making the case for ABC, dedicated

application software might not be necessary.

However, once the project moves forward to more detailed levels, or when adhoc

queries start to be required on the data, or when the model needs to be

maintained, the spreadsheet solution starts to look more problematic. Take the

issue of data volumes, for example. A typical strategic model might have 20

departments, 30 accounts, 50 activities, 50 customer/product groups and 10

drivers. You will appreciate this is not a hugely detailed model, but this can

result in 1.5 million calculation entities. Any spreadsheet will take a long time to

recalculate following even a simple data change and there is no ability to trace

back costs in simple report form to determine source.

A bigger risk is that the spreadsheet solution becomes extremely complex and

difficult to maintain, even for the person or persons who originally built it. If

those staff should leave, then experience suggests that the model either has to

be rebuilt or falls into disuse, because no one has the knowledge or confidence

to unravel the complex interrelationships that the spreadsheet contains.

For these reasons alone, reliance on spreadsheet models is not recommended for

the medium or long-term development of ABC.

A number of ABC software tools are available which make the process of model

building, data capture and analysis of the results much easier, both in the initial

building phase and during the ongoing life of the project.

A common misconception is that adoption of an ABC system implies the rejection

of the existing costing system and investment of large amounts of capital and

effort in the new system. In fact, the most successful ABC implementations are

where there are already good systems to provide reliable data and a good

costing discipline in the organization, and it is more likely that ABC will become

integrated into the existing system rather than replace it.

For more articles go to www.activitybasedcosting.com.au 

For information on ABC software go to www.algsoftware.com.au

For information on ABC services go to www.bestrane.com.au

Tags: , Activity Based Costing, Activity based costing implementation, Activity based costing implementation issues, Activity based costing issues