Transnet Freight Rail (TFR) is South Africa’s sole provider of railway freight services. The company moves about 180 million tonnes of goods over its 17,000km of track every year and has an annual turnover of R16.5bn (£1bn). It has successfully developed what I have termed a network activity-based costing system (NABC) from scratch over the past three years.
NABC is based on the standard principles of activity based costing, but it has been necessary to apply them specifically to costing in a network. Many other systems strive to obtain historical operational data, whereas NABC recreates simulated data from the company’s outputs – ie, it “reverse-engineers” the inputs.
Networked industries – for example, telecoms, shipping and postal services – are particularly difficult to cost and produce profitability and efficiency reports for because of the shared nature of their operations. A further complication is that it is often very hard, if not impossible, to recreate historical network transactions because there are often millions of them – if not billions, in the case of a telecoms network. All these transactions flow through the same network but each takes its own individual route.
A number of railway costing systems depend on extensive operational data, which is often very difficult or impossible to obtain. This data is not necessary in NABC, since it obtains what it needs from the existing invoicing figures and relatively static master data – ie, the service routes. Even if this data is available, railways then have the tough task of spreading costs over the whole network.
NABC provides a novel method of recreating and simulating all this operational data from invoicing information, using only a limited set of operational master data. This allows for the creation of a complete set of almost infinite activity data, which otherwise would not be feasible to track. The system uses this readily recreated activity data as a basis for better allocations of costs to smaller sections of the network, which are used together with the already created activities for rate determination.
These determined rates are then used for costing services. NABC has given us a practical and economical solution to costing network businesses and producing profitability and efficiency reports. This is because the system can self-generate rates and activities from an invoicing file. As a result, once the initial master data (which can readily be updated annually) has been established, little updating is required to make the system self-sustaining and comparable from period to period. The detailed recreation of rates and activities allows users to reconcile both regional and customer views of profitability at extremely high levels of detail, making the system a crucial tool for network management.
Thousands of trains travel over TFR’s network every month. Other railway costing systems have tried to trace such movements and accurately reproduce what occurs on the network. Assuming that this could be done, you would then have the difficult task of reconciling these consignments back to billable freight. This is made onerous by the fact that the same consignment can move on three or four trains before it reaches its destination. Then you have the further complication of empty returning trains running on the network with no direct billable freight. To compound matters, in order for any costing system to be credible, the data has to be accurate and applied consistently across the network.
Taking account of these complications and the immense information systems required to reconcile and monitor all movements, we set out to create a practical model for determining all these individual consignments and their concomitant activities on the network. The key to developing our NABC was to use the invoice file – ie, the output of the entire network – to derive the inputs. By its very nature, the file accurately reflects the individual consignments travelling over the network. Knowing these outputs, we merely had to recreate the steps giving rise to them in retrospect. The advantage of using outputs to recreate network movement is that the invoice file’s revenues (and, by implication, the activities) always reconcile back to the financial statements.
Once the invoicing file was uploaded, we had to link the outputs to the individual activities that made up those outputs. The inputs were recreated using the railway’s service codes, which divide each route into geographical sub-routes (nodes) and stipulate how a consignment moves over the network. Any one consignment will use only a small portion of the total number of nodes (about 4,000 in TFR’s case), since it won’t travel over the entire network. The service codes don’t change too often because the train routes are relatively stable, which enhances the system’s reliability. With the data from the service routes and invoicing file, we were able to work out wagon kilometres, gross tonne kilometers and other key activities across the network. We could then devise a process for allocating revenues using the activities we’d determined.
The next step was to allocate cost centres to “buckets” of costs and then to “cost collectors”. Railways may have thousands of cost centres, each covering different buckets of costs – eg, overheads, staffing and energy. Much effort is required in determining where each of the cost centres undertakes their work and which cost categories they fall into. The expenses, which were already divided into general ledger items such as depreciation were, therefore, placed in various categories that were relevant to TFR’s operations. The buckets were then allocated across the network using the various activities determined above. We were able to allocate costs at a micro level of detail to each of the cost collectors and nodes.
The activities were, therefore, used both to allocate costs from cost centres to nodes and to calculate rates for activity-based costing. Without the use of these derived activities, every cost centre would have had to be divided among the 4,000 or so cost collectors on a percentage basis using estimates, resulting in arbitrary and probably inaccurate allocations. This would have made the costing system hard to control and keep consistent, since the exact split among the nodes would be difficult to estimate. For example, how would you break up the costs of a train driver cost centre to, say, 120 of the 4,000 nodes if you couldn’t use activities to apportion these costs?
Once we’d allocated costs and activities to every node, our next step was to determine rates and efficiencies at each level of the network – eg, the rate of marshalling a wagon at a specific marshalling yard. We can now use NABC to work out efficiencies using the determined costing rates at each section of the network.
This provides a method of comparing efficiencies among business units and periods. Since the system creates activities on a consistent basis across the network, we use these activities as a basis for performance management. For example, we can compare how many wagon kilometres were done in a specific section against what should have been done.
Since individual service codes – eg, a consignment movement between Johannesburg and Cape Town – comprise a series of activities occurring at different locations, these activities multiplied by the rate equal the consignment cost at each point on the network. The sum of the individual nodes for a specific consignment can be added together to give the total cost for that consignment. Consignment costs can then be cascaded upwards into reports by customer, sector, industry and so on. And, since every leg of the consignment is linked to a specific geographical point, these locations can then be cascaded upwards into area, regional or “corridor” reports.
NABC has allowed us to integrate and report on the marketing/customer view and the geographical view. Both individually and in combination, these views are essential for a railway company – and indeed other networked businesses. As well as the revenue and cost view, generated activities can be overlaid. Given that activities are recreated across the whole network and costs are allocated to detailed areas of the network and to customers, we can extract reports at any level of the network at the highest level of detail. This makes the system useful to any network where the inputs may not be readily available. Data can be extracted from over tens of millions of lines, allowing for any required permutation of report by customer and/or region.
Without NABC, it would be very hard to track network movements and concomitant activities and to apply these to their costs in order to determine costing rates. A bottom-up recreation of activity would be almost impossible to achieve in certain industries because of the sheer number of transactions, so it’s desirable to use the output of network operations, which is accurate and complete, to recreate the activities making up the input rather than building these activities from the historical inputs. Once activities are recreated, rates can self generate and costs can be allocated fairly to regions and individual services, which may span many regions. At all times NABC reconciles back to the financial cost and revenue view of the business. The data produced can then be subdivided to produce a matrix of geographical and customer reports, measuring efficiencies at any geographical point for any customer.
As can be seen, NABC provides a practical solution for dealing with the complexity of network costing, profitability and efficiency measurement. It affords managers at all levels a masterful tool to help them with pricing, capital evaluation, performance management and strategy.
Luis Gillman CA(SA), AMCA is a Senior Manager (Investment Portfolio) at Transnet.
This article first appeared in Financial Management (CIMA, UK) and is reprinted with permission.
