WHITE PAPER

Author: Richard Barrett and Jim Robinson

Contributors: Chris Grundy, MaryLouise Meckler, Jing Zhao
Audience: CFOs, fnancial controllers, fnancial managers, and cost accountants.
EXECUTIVE SUMMARY
This paper is the second in a series of three developed to help you understand
activity-based costing (ABC) and activity-based cost management (ABM).
This paper discusses the major issues that often face ABC implementers.
The other two papers in the series are An Introduction to Activity-Based Cost
Management, and Practical Applications of Activity-Based Costing.

ACTIVITY-BASEd CoSTIng
IMplEMEnTATIon ISSUES
A Guide to Successful ABC Solutions
ConTEnTS
2 Introductioin
4 Selecting Activity Drivers
6 Designing the Activity Dictionary
8 Choice of Modeling ToolSpreadsheet
or ABC Software

When you implement ABC, remember that yours wont be the frst organization to
do so. Many other businesses have already adopted an activity-based approach to
their management processes, and their experiences show that a number of considerations
and issues must be faced. This paper discusses the most frequent of those issues.
nUMBER of ACTIVITIES
One issue analysts often faceironically, usually by those who have embraced the
ABC concept most enthusiasticallyis the temptation to build an activity list that
goes down to too fne a level of detail. There are practical problems associated
with modeling too many activitiescalculating the model takes longer, maintaining
the activity list is an administrative nightmare, and classifying activities to identify
wasted activity becomes a more onerous job.
But more importantlyadding more detail doesnt give better information. When a
model contains thousands of activities, its diffcult to home in on pertinent
informationyou cant see the forest for the trees. Many activities will have
insignifcant amounts allocated to them. Its best to consider how you will use
the activity analysis before you defne the activities, and then choose a level of
detail that is appropriate.
For example, if youre preparing a strategic analysis, its probably suffcient to
defne as few as 20 or 30 activities. In reality, these activities probably would be
at a high enough level to be classifed as processesfor example, a series of related
activities that compose the customer sales order processrather than the individual
activities that form a part of that process, such as take customer order by
telephone. Dividing the process cost by a suitable driver, such as number of
customer sales orders, gives a measure that 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, its reasonably easy to do so without fundamental upheavals in the model.
For tactical modeling, you need to work at a more detailed level. This is a must when
investigating wasted costs, because it becomes necessary to analyze activities
related to error correction, duplication, and waiting. More detail is also needed for
product, customer, and channel costing, so 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
levelperhaps down to task or, more likely, a combination of task and activity level.
If the whole business is to be examined, business process improvement sometimes
results in over a thousand activities. Modeling at such a level could prove to be a
InTRodUCTIon
Business objects. Activity-Based Costing Implementation Issues 2
complex and lengthy procedure, and the need for such a detailed approach would
greatly depend upon the organizations circumstances and its need for such information.
Table 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
points management in the direction of areas that need attention. More detailed
modeling exercises can then be run, focusing on those areas of concern. However,
if youre interested in cost-effectiveness, at some point you need to model at the
tactical (activity-based) levelotherwise, you cant differentiate between those
activities that add value and those that dont.
Table 1. Applications of Different Levels of Activity Costing
Level Typical Number of Activities Applications
Strategic 20-75

Business Pperformance Measurement
Benchmarking
Forecasting and Planning
Strategic Pricing of Services
Intrabusiness Charging
Departmental Performance Measurement
Identification of Wasted Activity
Value-Added Analysis
Tactical 75-300
Task 300+ Individual Performance Measurement
Business Process Improvement
Business objects. Activity-Based Costing Implementation Issues 3
One of the most diffcult parts of ABC implementation is identifying and selecting
suitable drivers. One reason is because its not always immediately apparent what
drives a particular activity. For example, the driver for the activity chase customers on
telephone 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 that faulty goods cause customers to delay payment. As a general guideline, the
root cause driver usually gives management the most useful information. However,
you wont always know what the root cause is.
Especially in the early phase of ABC implementation, it may not be clear which
driver is most signifcant. It often doesnt become clear until after the activity cost
has been calculated, but if your software solution is fexible enough, its a simple
enough job to switch an activity from one driver to another. This neednt be a
problem, but you need to be open to the idea that you mayand probably willhave
to change your assumptions about driver assignments. Choose a solution that
allows you to change assumptions easily.
Another potential pitfall is that even when a driver is clearly important, the driver
data may not be easily available. Possibly the data isnt recorded anywhere or
resources arent available to extract the driver from the IT systemsso you must be
prepared to compromise and perhaps use different drivers, even if only temporarily
until the appropriate data can be extracted or start to be collected. To alleviate this
somewhat, its a good idea to start driver collection early. Experience shows that
getting hold of the driver data is often a bottleneck in ABC projects. Starting early
not only minimizes the risk of a bottleneck but may also allow the business to start
collecting data that it doesnt currently track.
SElECTIng ACTIVITY dRIVERS
Business objects. Activity-Based Costing Implementation Issues 4
Maximize the beneft of your work by adopting a few simple principles when it
comes to choosing activity drivers. First, try to limit the number of drivers. You can
probably choose 10 or 20 drivers that ft most activities, and those related to the
most costly activities. For a few low-cost activities, the beneft of spending a lot of
time and effort on getting data for a few esoteric drivers likely wont be worth the
trouble. For those few low-cost activities, assign the best-ft driver from the remaining
listor 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 you concentrate on the most costly drivers.
If you need to, its quite valid to estimate the most important drivers. When a driver
is in the top 10 but data isnt immediately available, use your management team
and staffs experience to estimate the volumes, or if appropriate, sample the data
for a short period to provide an estimate of the annual driver volume. Although by
defnition estimates and samples are less than 100% accurate, its better to have
information that 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 accurateand certainly good enough to produce a reasonable
allocation of cost to customers and products.

Business objects. Activity-Based Costing Implementation Issues 5
The activity dictionary is more than just a list of activitiesit also acts as a template
for collecting the time spent by staff on activities. So as well as 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 on a set of processes and activities that are to be modeled. The workshop is
extremely important, not only because it allows the project to beneft from the
business knowledge and experience of your managers, but also because it
educates them in the methodology and allows them to appreciate the reasons for
the projectthus encouraging their full participation and cooperation with the
conclusions of the analysis.
During the workshop, remember what we discussed in the previous section about
the number of activities. Limit the level of detail to what is required and to what will
provide the necessary results at the end of the analysis. More detail than necessary
results in a cumbersome modelone thats hard to maintain and from which
conclusions are hard to draw. Also, remember the salient points about identifying the
activities that are related to process failure. If you want to make process improvements
as a result of the ABC analysis, its important that your activity dictionary lists waste
activities, such as error correction, duplication, waiting, checking, and transportation.
A frequent obstacle to successful ABC modeling is the inability to obtain good-quality
activity driver data. Your design workshop should initially allocate drivers to activities,
and then attempt to reduce the number of drivers to a maximum of, say, 20. Get all
managers involved to review the original choice of drivers, so they agree on what it
is really the cause of the activity.
dESIgnIng ThE ACTIVITY dICTIonARY
Business objects. Activity-Based Costing Implementation Issues 6
Sometimes you wont be able to get hold of the right information for your frst-choice
driver, so be prepared to compromise. In cases where activities are known to be
caused by a driver for which data wont be available, and no alternative best ft is
available, you can split the activity by customer/product group in the dictionary and
ask managers to estimate the split when completing the dictionary. This is illustrated
in Table 2.
Activities % Staff Time Available Drivers Estimate
(Data Not Available)
Print & Mail Invoices
Allocate Receipts
Issue Credit Notes
Plan, Organize,
& Monitor Staff
Total
30 Number of Orders
Number of Return Notes
Number of Orders
Unallocated
600
20
50
400
Chase Customer
on Telephone
Customer A
Customer B
Customer C
100
Activity Dictionary-Credit Control department (6 employees)
29%
71%
0%
Table 2. Estimating Customer/Product Split in the Activity Dictionary
Business objects. Activity-Based Costing Implementation Issues 7
There is, simply, no getting away from the fact that some sort of software solution is
necessary. The frst question is whether you should invest in a dedicated ABC tool,
or if its possible to get away with building your own spreadsheet-based solution.
For a high-level, strategic model, its just about possible to get away with a homegrown
spreadsheet solution. For a prototyping, proof-of-concept exerciseaimed at
establishing the methodology and making the case for ABCdedicated application
software might not be necessary.
However, once the project moves forward to more detailed levels, or when users
require ad hoc queries, or when you need to maintain the model, a spreadsheet
solution looks more problematic. For example, take the issue of data volumes. A
typical strategic model might have 20 departments, 30 accounts, 50 activities,
50 customer/product groups, and 10 drivers. Although this isnt a hugely detailed
model, it can result in 1.5 million calculation entities. Any spreadsheet takes a long
time to recalculate after even a simple data change. Additionally, spreadsheets lack
the capability to trace back costs in simple report form to determine source.
A bigger risk is that the spreadsheet solution becomes extremely complex and
diffcult to maintaineven for the person or persons who built it. If the spreadsheet
creator should leave, experience suggests that the model has to be rebuilt or it
falls into disuse because no one has the knowledge or confdence to unravel the
complex interrelationships contained within the spreadsheet.
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 that 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 adopting an ABC system implies the need to
reject the existing costing system and invest large amounts of capital and effort in
a new system. In fact, the most successful ABC implementations are ones in which
organizations already employ systems that provide reliable data and a good costing
discipline in the organization. In such organizations, ABC is more likely to integrate
into the existing system rather than replace it.
ChoICE of ModElIng ToolSpREAdShEET
oR ABC SofTWARE
Business objects. Activity-Based Costing Implementation Issues 8
Notes
Business objects. Activity-Based Costing Implementation Issues 9
Notes
Business objects. Activity-Based Costing Implementation Issues 10
Notes
Business objects. Activity-Based Costing Implementation Issues 11
insight.businessobjects.com
businessobjects.com
2007 Business Objects. All rights reserved. Business Objects owns the following U.S. patents, which may cover products that are offered and licensed by Business Objects: 5,555,403; 6,247,008;
6,289,352; 6,490,593; 6,578,027; 6,768,986; 6,772,409; 6,831,668; 6,882,998 and 7,139,766. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Xcelsius,
Crystal Decisions, Intelligent Question, Desktop Intelligence, Crystal Enterprise, Crystal Analysis, Web Intelligence, Rapid Marts, and BusinessQuery are trademarks or registered trademarks of Business
Objects in the United States and/or other countries. All other names mentioned herein may be trademarks of their respective owners. August 2007 WP3077-A