Here’s activity-based costing in a nutshell: outputs consume activities, and activities consume resources.
OK, here’s activity-based costing in a slightly larger nutshell. If you want to accurately cost your outputs (like products and customers), you won’t get an accurate result by allocating your resource costs directly to those outputs, because the cost of making a product or servicing a customer doesn’t depend directly on your resource costs. Actually, the cost of, say, servicing a customer depends on how much the customer consumes of what you do. “What you do” is what we rather grandly call your Activities.
In SAP Profitability and Cost Management (PCM), or any activity-based costing solution, your choice of which activities you’re going to model is key. You don’t have to get it dead right first time, but you can certainly make life easier for yourself by thinking about what you want to achieve, both in the short-term and the long-term, before you dive into building the model.
What is an Activity Dictionary?
It’s a good idea to create a repository in which you record the activities that you’re going to build into your model. This repository is called the Activity Dictionary.
An Activity Dictionary will, as a minimum, list and define each activity. The Activity Dictionary may also indicate who carries out each activity, and the driver that it uses for cost allocation. An Excel or Word document is frequently used, but don’t overlook the fact that you can enter descriptive memos to dimension members in PCM, so it’s quite possible, with a little discipline, to use a PCM model as its own Activity Dictionary. If you take this approach, you can neatly avoid the risk of the model and the documentation getting out of sync. It’s also possible to extract that information out of PCM and use Office (or similar) to format it, if nicely presented versions of the Activity Dictionary are what you’re after.
Another use of the Activity Dictionary, which comes into play later in the project, is that it can serve as a useful basis for data collection. Resource driver splits are the values the model uses to allocate resources to Activities, and represent measures of resources such as hours worked, floor space used, networks, and so on. The Activity Dictionary tells us the level of detail at which we need to capture this data.
So, once we’ve picked a medium in which to store our Activity Dictionary, the next task is to build it.
Which activities should you build?
The classic misstep is to build too many activities into your model. It’s not a disaster if you do this, but can make life difficult later on. Going down to too detailed a level makes it harder to collect the data, harder to maintain the model, and, crucially, harder to identify the most appropriate action to take based on the model’s output. One of the major benefits of an activity-based model is that it shows you how you can improve performance. With a large Activity Dictionary, the vast majority of activities are, in themselves, immaterial.
The reasons why activity-based models end up with large Activity Dictionaries are understandable. It feels safer, for one thing: it seems like you’re less likely to have missed anything if you’ve gone down to a fine level of detail.
It’s also flattering to have a lot of activities, isn’t it? Or conversely, it’s a bit worrying for one person, team or department to be thought of as only doing one thing.
However, it’s important to realise, and to communicate to stakeholders, that only having one activity assigned to you in an activity-based costing model doesn’t mean that you’re only doing one thing, or that what you’re doing isn’t important. A single activity in a high-level model can – usually does – represent something vital to the organisation, and something that actually comprises plenty of varied work, but it might be that it’s currently enough for the model to work at that high level.
For example, here’s a high-level activity, taken from an example Activity Dictionary in Lianabel Oliver’s The Cost Management Toolbox.
Depending on the type of analysis required, the first column might be a good choice for an activity. If you want to do a strategic analysis, then as few as twenty or thirty activities might be enough. This level of detail might be a bit more towards the “process” level than the “activity”, but that’s not necessarily a bad thing. Modelling at this level could give you some useful unit rates, let you benchmark your plants against each other, identify which plants are potentially areas of best practice within your organisation, and identify possible areas for outsourcing.
It’s relatively easy to add detail to the basic strategic Activity Dictionary. Using the same example as above, you could expand your original model by splitting selected activities, or indeed all activities, into more detailed items.
Splitting the activities like this can give you:
An idea of how the original activity’s costs are distributed across the new, more detailed ones
The ability to use different drivers for the some or all of the detailed activities
The ability to assign each activity to different cost objects – for example, some products may not receive any share from one of the activities, but still need a share of the others.
If none of the above are required for your model, there’s little point in giving yourself the extra work associated with maintaining and collecting the data for the extra activities.
If you’re interested in more of an operational view, where you’re looking at wasted cost or business process improvement, then typically you might have a more detailed – which means larger – Activity Dictionary. In a large organisation, with a lot of departments specialising in different disciplines, the number of activities can easily be several hundred. This extends calculation time, increases the maintenance effort required to keep the model ticking over, and makes data collection more onerous.
This point about data collection is particularly important for driver data that doesn’t exist in computerised form, and has to be collected directly from the business via old-fashioned and time-consuming methods, like questionnaires, and keying data. If this is necessary, your users will thank you if you don’t give them too detailed an Activity Dictionary to follow.
Also, such data is often subjective, with users giving their opinion as to what the splits are. Such data is never going to be very accurate, so, again, going to a very detailed level can be more trouble than it’s worth.
Where do you start?
For organisations starting off with SAP PCM, this can be intimidating, and pretty difficult to manage. A useful approach is to start at the higher level, and add detail to the model over its lifetime. This has the advantage of producing results, and benefits to the business, much more quickly than would be possible from a fully detailed, fully functional detailed model. It also allows the project team to learn quickly, and provides a foundation for later expansion. The project becomes more agile, and can be pointed in the most appropriate direction according to the requirements of the business and the outcomes of earlier activity-based analysis.
Alternatively, some organisations start with a detailed level, but only model part of the entire business. This is often the case if management feel that there is a specific area of the business that requires attention. For example, manufacturing costs might be higher than expected, or there may be problems in customer services that require work to identify best practice. In these cases, the scope of SAP PCM can be limited to a particular area, but the option is still there in the future to build out into the rest of the company.