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
