SOFTWARE

THE ENGINE OF ABC

There are more than a dozen software products on the
market developed around the basic concepts of activity-based costing.
Here are the considerations to help you select the right one.

by Murray Best

Why buy ABC modelling software at all? Armed with the fundamentals of ABC and powerful spreadsheet software, such as Excel or Lotus 1-2-3, can't the management accountant create his or her own ABC analysis? Yes, for very small "what if" models, this might be the right answer -- but with an extreme note of caution. Developing any spreadsheet involves programming, no matter how small. Programming that must encompass considerations of data input, manipulation, and output, combined with the troublesome part -- documentation. All four elements require design, coding, and testing, plus ongoing support. This extra effort is diverted from the ABC analysis and, in the case of all but the smallest of models, it adds considerably to the time line for completion of an ABC project. Spreadsheet software development never ends. As new thoughts emerge, more and more calculations and report formats evolve. Ultimately, the development cost of the spreadsheet model far outstrips even the most expensive ABC modelling software.

There is a place for spreadsheet software in doing ABC, but it's not at the core. Spreadsheets are wonderful tools to format data for input to the ABC model, preparing management reports from the results of the analysis, and for formatting data gathering working papers. Spreadsheet software becomes an invaluable tool to compile much of the 75 per cent of the model data needs that lie outside of the general ledger accounting system.

Expectations of the model

The most important consideration is management's' expectation. ABC is a decision-support analysis, not an accounting system. If management expects to implement an ABC accounting system, none of the current software will meet this expectation. Some general ledger software companies claim that they do have ABC in their accounting software. They might think they have ABC, but it is treated as an accounting exercise. The general ledger provides only financial data which is the smallest portion of the total data requirement to do ABC. The majority of the data is operational or non financial, such as number of cheques cleared, number of set-ups on a machine, number of orders shipped, etc. The vast majority of ABC information comes from operational databases and involves data management routines that are not suited to a general ledger.

Beyond the false expectation that ABC is a new accounting system, the benefits of ABC for operational analysis and management control are well documented. The real question is: Will the software generate the analysis and information needed to gain the expected insight to the operations being studied? The following guidelines look at ABC model designs that need to be reflected in the software.

Software design features

Terminology used in the software for ABC should comply with the Glossary of Activity-Based Management prepared by CAM-I (Computer Aided Manufacturing-International, Inc.). These terms have become standard to ABC and have been incorporated into most training programs and technical literature. Some software developers, for proprietary reasons, create new terminology that is unique to their product. But, the use of product-specific terms for ABC often becomes confusing to new users who have recently learned ABC and are just starting out to develop their first application.

As ABC evolved, it was recognized that the analysis capability is more than just a means to cost products accurately. Capabilities go far beyond simple compilation of activity costs and tracing of the costs to the products produced. Based on ABC's methodology (see article on page 24 for more detailed discussion on this), activities are assigned to appropriate cost objects based on activity drivers. Therefore, the software must have the capability to network cost objects to support the assignment of cost through multiple dimensions (e.g.: product, service, customer, market, channel, business-sustaining activities, and outputs of the organization).

The majority of activities are consumed by cost objects, while others are resource inputs to other activities, which are termed enabling activities. The ability to define an activity as a resource to other activities is an essential part of the software design. This feature simplifies the assignment of resource costs (such as payroll processing, human resources, building occupancy, etc.) in support of activities that are consumed by cost objects.

Results analysis

The critical core of the ABC model is the analysis and reporting of activities and cost objects. Within the multi-dimensional capability noted above, this core should contain the data fields and attributes necessary to gain the expected value from the model. The analysis begins with the entry and assignment of resources (see Figure 1).

Figure1: Multi-dimension cost analysis

Resource level data elements of the model should be unlimited in number and reflect the general ledger account structure for simplicity. Optional methods to assign resources to activities for each resource account include: a dollar assignment; a percentage assignment; or an assignment that is proportional to a resource driver quantity. If an object of the model is to analyze the deployment of staff to activities, a means to enter full-time equivalent employee counts, and the mathematics to compute and trace the assignment of employees to activities, needs to be incorporated into the software. For each resource record, there needs to be a method to enter budget amounts, for building "should-cost" analyses.

The activity section of the model should be rich in capabilities to analyse and validate ABC costing. It is important that there be no limit on the number of activities that the model can contain. Thus, a model could be created using a micro-level of activities, especially if the model will support process management and analysis. The micro-activities would be accumulated at a macro-activity level to simplify attachment to cost objects by the appropriate activity driver. Although the capability needs to be there, exercise caution that the model does not get too big, because the effort required for data collection and analysis will be too cumbersome. Better to start macro and go micro if needed.

Analysis of activity details is meaningful when a model contains attribute fields. Attributes record information about an activity including: cost drivers, cycle time, capacity, performance measures, cost type, activity type, business process, activity centre, and possibly others. These attribute fields need to be present, and, preferably, some of the fields are user-definable.

Activity attributes assist in the grouping of activities by characteristics of the activity, or by the cost objects to which the activity is traced. Optional attributes or summarizing techniques are required to assist in the grouping and analysis of activity costs. Use of activity attributes aids in model building since the user does not have to pre-define the activity sequence to produce reports. Figure 2 shows how the attribute, activity type, creates a summary report.

Analysis of activities requires an understanding and insight into the origin of resources consumed by an activity, and the immediate destination of the cost accumulated in the activity. This forms a basic audit trail of information from the input resources through activities to cost objects. A means to trace detailed resource inputs to an activity, and the consumption of the activity, must be readily available in the model for reconciliation.

If the model is adapted to analyse business processes, a means of assigning activities to, or summarizing activities by, a process identifier is required. Performance measures utilized for processes should be separate from performance measures reported for the individual activities.

To produce cost object profitability reports, it is necessary to have a means of entering revenue data for each dimension of product, customer, and other dimensions, in appropriate combinations.

Certain costs may be traceable directly to cost objects. Additional fields in cost-object records are needed to input directly traceable costs, such as material, freight, commissions, etc. Complex applications require a means of entering and costing an itemized bill of material to build up product cost objects.

Within the multi-dimension network of cost objects, a feature to assign cost data from one dimension to another is necessary. This feature drives activity cost traced to the product dimension to a different dimension of the model, such as customer and/or market channel. The method of driving cost to another dimension must not be per cent of revenue, as this would defeat the whole purpose of ABC cost tracing. Alternatives, including quantity of goods sold, or per cent of cost as a surrogate when a quantity count cannot be determined, are appropriate measures. When cost is driven to other dimensions, cost origin details are required for proper analysis.

Organization of cost object data in a large model is improved if attribute fields are available to the user. Attaching attributes to cost objects is useful in sorting or selecting products, or customers, by any of: class; type; distribution channel; market channel; geographic area; or, other form of grouping required to generate meaningful output.

Results reporting

A good ABC software system contains a standard set of output reports covering raw database information, along with detailed and summary activity, and cost object results. To organize and present the model results in a meaningful manner requires a complete set of standard report formats as outlined in Figure 2.

Availability of standard reports improves the initial implementation by focusing effort on developing the ABC model, not reporting formats. Ideally, standard report formats provided with the software should be open to modification to meet specific identified needs, without having to employ the software provider to make the adjustments.

Integration capability

The power of ABC comes from using a large amount of data to trace the cost of resources to cost objects. Since the model needs a large amount of data to meet its goal, there must be simple, efficient methods to import data from existing systems, preferably in existing formats.

The formats could be text reports, database files and/or spreadsheet files with an unlimited variety of layout. The strength of a software product comes from its ability to effectively utilize the various sources of input in their native format. When this feature is present, it eliminates having to write complex programs to interpret and organize the data in terms that are acceptable to the model.

Features for data export from the model should be available so that results data can be used by other systems, such as cost accounting, pricing, inventory management, and "what-if" simulation. The format of data export should also be user-definable.

Usefulness of model data is improved if other software products can link directly to the ABC database. These links provide data from the results of the ABC analysis to other systems as inputs or to other modelling applications. Connection to executive information systems (EIS) tools is becoming more important for companies, thus, links need to be available to access model data with an EIS facility.

Report requirements:

* Data listings of all model input tables.

* Audit, reconciliation and error-tracking reports.

* Activity reports:

* by activity and cost,

* activities selected/sorted by attributes,

* resources consumed by each activity,

* where used in other activities, processes and cost objects.

* Cost object /profitability reports:

* profitability by dimension,

* activity resources by cost object.

Technical elements

There are a few technical considerations that the management accountant can address without being a systems expert. Some of these continue to be items that are poorly addressed, or not addressed at all, by software providers.

The operating environment for the ABC software model should be PC-based. Favor PC-based software that has been developed in Windows, since these will be the products that will be upgraded in the future. It is an additional advantage if the software can be networked so that more than one user can access the model simultaneously.

Avoid software that comes attached to a consulting engagement, as you may not be getting the best combination of software technology and ABC project facilitation.

In this age of connectivity, the ABC database must be constructed on an "open architecture." Many software suppliers continue to use proprietary database designs that can only be accessed by their unique software. This limits the utilization of the database to routines included in the software, or custom routines that are only available from the supplier by purchase of additional modules or custom-designed programs. Software that uses a popular database format can be easily understood, accessed by off-the-shelf software, such as Access, Approach, FoxPro, and spreadsheets like Excel and Lotus 1-2-3. Thus the wealth of information contained in the ABC model can be readily applied to other applications.

Software should be supported by complete documentation outlining the usage of all features of the product, including examples. In the spirit of open architecture, identification and layout of all database files and tables should also be provided. The documentation, supplemented by an on-line help facility, improves the operation of the model. A text and usage-based tutorial to guide the user through an actual example aids introduction to the software.

Documentation and on-line help will support experienced model builders, but new users will require formal training programs. Be sure that training programs have been developed for the software. Where public domain sessions are not repeated frequently, optional on-site training will be required to insure that training is timely. Ask references about the quality of the training program.

Supplier organization

The traditional approach to software acquisition from a supplier, with an installed base of systems, who is willing to provide references of current users, usually provides a reasonably safe route. Occasionally, a highly innovative new supplier will emerge with a product that really appears good, but doesn't have an installed base. Be sure that the software is evaluated by an experienced ABC implementation consultant who is not committed to any particular software product. This is the only sure way of getting an impartial analysis and opinion. Don't depend on promises that have all the features you want in the next release. If the capability isn't there, wait until it has been incorporated, tested and released. Better still, choose a supplier that has the functionality already in a released, and well-tested, product. Base the choice on content, not on glittery presentation and promise.

Get feedback from the references on the responsiveness and technical ability of the supplier. Avoid software that comes attached to a consulting engagement, as you may not be getting the best combination of software technology and ABC project facilitation. Be careful about buying consulting from a software supplier, because it will make your application fit its software, rather than fitting the software to your application.

Quite often suppliers will claim that their software performs ABC, but, in reality, their software does not address the basic requirements. This is usually because the software is designed by programers who have limited comprehension and experience in management accounting.

Price/performance

The price range for ABC software is significant, from a low of $5,000 to a high of more than $21,500 for a single-user system. Higher price in this market does not assure better quality and necessary features. Some of the higher priced software choices are missing critical elements, others just won't do the job. Most important, understand ABC and your application thoroughly before buying software. Start with complete training in the principles of ABC. Develop the implementation architecture of the ABC model, and perhaps complete the activity analysis before selecting software. Talk to ABC practitioners and implementation consultants for information on their experiences with software.

The purchase of software will not insure the success of an ABC project. Success will be achieved by combining a thorough understanding of ABC, clear objectives, and appropriate software. Success will also require commitment with action to improve the business based on the information generated by the ABC analysis, supported by the model. cma

Murray A. Best, cma, is an associate of Focused Management Information Inc., and president of Profit Dynamics in Oakville, Ontario. His company specializes in profit and performance improvement, utilizing activity-based management, process re-engineering and selective automation.

Reprinted from the CMA magazine with permission from The Society of Management Accountants of Canada.