Today's controller is confronted with two developments: on one hand, increasing usage of mobile applications for all employees, steady growth of IT-supported operational resource planning systems and the hype towards Big Data result in an increasing volume of direct business information. On the other hand, more and more detailed accounting standards and higher requirements for compliance and governance enforce heavier control activities.
In order not to miss the step into an effective business partnering and to be able to co-decide with line managers, however, a new form of tools based on IT developments should focus on business decision-making and deliver direct proposals for taking measures to line managers. It therefore requires new "decision-delivering" instruments as well as customized profiles for the future "Performance Manager".
The notion of "business partner" is becoming increasingly common in the discussions on strategic developments of finance departments. The aim is to steer the business together with line managers at equal responsibility. This often entails the idea of taking a "challenging role" across the line functions in order to critically illuminate measures and impacts, thus increasing the quality of the decision-making process. In principle this is not wrong, but a finance department may not believe that this makes already the way to becoming a business partner.
A true partnership means that decisions are developed jointly and it doesn’t mean a critical challenge from the sideline. Similar to marriage: Who would like to have a partner who simply relaxes, watches, and at the end, after a lot of work, begins to cast critical remarks. Who would not want to have a partner with whom one can constantly discuss, taking decisions together and who actively participates in the common work-load? Considering a finance department, it means that it is not enough to look at an EBIT or KPI figure and then ask some critical questions, or to notice that these figures should be better compared to a really good company.
This not only provokes discomfort and frustration but also leaves line managers “in the rain” without any effective contribution to what should be done or be optimized. There is a danger that the finance organization - perhaps even unintentionally - will persist in a pure control function and thus be logically avoided by the business if possible. Or even worse, you are drifting off as a finance department and assume the role of a therapist, who considers the line manager as a patient, who must be told what "correct and good" business steering consists of. Of course, this also generates a dependency relationship, but surely not on a partnership level.
As already said, a challenging or control function isn’t always a bad thing. Finance departments have been strongly oriented to such a role over the past decades, including instruments such as financial accounting or the classic instruments for management accounting where there are even specialized trainings - such as the CMA. The fact, that accounting and management accounting systems have become more and more complex and that more and more experts from large audit firms have to be approached directly to solve upcoming questions, increases the risk for a finance department to deviate more and more from effective business needs and to miss the developments in connecting and usage of business data.
2. Disadvantages of classical management accounting
To discuss the ideas, we consider SBB Cargo AG, the Rail freight subsidiary of the Swiss Federal Railways SBB, which operates so-called single-wagon load traffic in the Swiss domestic freight market. This means that a customer, if he has a track connection, orders a wagon, loads it and sends it over the network of SBB Cargo to its final destination.
Schematically, this network is constructed as follows:
- Several shunting yards (SY) with daily long-distance trains connecting them
- Several team stations (TS) with near train connections to the shunting yards
- Starting at the team stations there are several last-mile tours, which bring the individual wagons from and to the loading places (LP) of the customers. The specialty is, however, that the last mile tours normally aren’t circular tours, but tours using the same way back and forth
- In the shunting yards, the team stations, as well as the loading, places the individual wagons are shunted as required.
The classic management accounting follows a standard industry logic:
How much costs the last mile tour, how much the shunting activities at the team station, how much the transport from the team station to the shunting yard and so on. On each of these service components or cost blocks, it is determined how many wagons are handled and then the costs are allocated proportionally to the number of wagons on the responsible shipments. If finally, a customer with all its shipments is evaluated, then one sees, in addition to the sales, the corresponding proportionally allocated costs of the individual service components.
If we look for example at the work of a shunting team on the last mile, the cost elements can be divided into the train path costs, wagon costs, costs of shunting staff and costs of the shunting locomotives. Schematically, it works as follows:
Direct primary postings on the customer order in SAP are the revenues triggered by the order itself and services purchased specifically at a third party.
In SAP this cost allocation scheme requires 3 complicated layers of internal posting processes:
- Allocating auxiliary costs on the specific service centers.
- Allocating the service centers on the specific customer orders
- Processing customer orders into the profit calculation scheme.
The basis for the allocation process is previously determined standard cost rates.
Thus, the classical management accounting provides margin contribution and profitability calculations for each customer and each of his corresponding shipment. However, the following disadvantages are associated with such a system:
- The costs allocated to the shipments really exist, but no statement can be made about which of the cost blocks can be effectively reduced after the loss of a customer. If, for example, a typical customer gives up his shipment from A to C, that does not mean that the corresponding pick-up or delivery route B - D can really save costs, especially as there are other customers at the loading stations B and D. This problem always occurs when several customers or products are managed via common networks, machines and so on. In order to really know the effects of such changes, supplementary analyzes and clarifications are always necessary, which is time-consuming and costly.
- The same applies, of course, if a customer wants to send a new shipment from C to A. Out of the management accounting system, a cost calculation can be made based on the standard rates, but whether there is still free capacity on the trains / tours, or whether additional resources have to be inserted, is not clear from the calculation.
- A finance department with such an instrument can exercise a "control" function by challenging “unprofitable” shipments, but direct solutions as a business partner can’t be submitted without extensive additional analyzes.
- The SAP system itself is highly inflexible, complex and expensive to maintain
- And finally, it is difficult for business managers to plug in directly into the core SAP system.
Normally there’s a need for translating results by customized and understandable reports.
3. Development of a decision delivering steering system
With modern steering systems, the disadvantages of classical management accounting will be solved. The ideas of DdS are based on the following principles:
- Use of today's IT technologies for handling large amounts of data
- Use of today's mathematical methods to generate concrete recommendations for action plans
- Increased use of existing operational information
- Eliminate complex company internal clearing and billing processes to generate a static management accounting
- Constant focus of all steering instruments on concrete decisions
- Interactive linking of all employees especially area staff with the relevant steering pieces of information and with the possibility of giving direct recommendations
The following chapters should describe the steps to implement the different building blocks of a DdS system.
4. DdS.1 – Maximum Value Pricing
Pricing is only about what a customer is willing to pay. Of course, this finding is not new but is logically linked to the beginning of a decision-delivering steering system.
Let us take a customer who sends x wagons from place A to place B. If this customer decides to transport his goods by rail, then the added value for him is the displacement of his goods (depending on the weight) in a suitable wagon over the distance from A to B. How often and for how long the wagon has to be shunted, does not interest him, on the road this doesn’t happen. The price function (simplified) is thus given by Price = P (industry, wagon, distance, weight, possibly type of goods, ….)
This means that the price is calculated by default from a factor for the industry, the number and types of wagons used, the distance and the weight.
An important element here is a direct comparison with the prices of the other railway competitors and the road price, where goods are also transported from A to B. The goal of benchmarking must be to maximize the willingness to pay or to know where to beat the market price.
The second element in the customer's willingness to pay is the added value that could be offered in comparison to road transport or to another competitor. In particular, the following
points can be named:
- Cost reductions for the customer due to less area space using rail-bound wagons compared to lorries operating on the factory premises.
- Cost reductions for the customer by means of an additional "storage area", if the freight wagons remain on place for a certain time.
- Cost reductions for the customer when loading special wagons compared to the loading of trucks.
- Cost reductions for the customer through the possibility to order spot-capacities.
- Cost reductions for the customer to be able to transport goods quickly overnight.
Such points can directly increase a customer's willingness to pay and shouldn’t be forgotten in the pricing and also in the negotiations with the customer.
5. DdS.2 – Calculation of “perfect production”
The DdS-calculator or optimization tool is intended to optimize both acquisition and resource usage in the single wagon load network of SBB Cargo by calculating a perfect production situation.
The tour of a shunting team is perfect, for example, if the team runs constantly with the maximum possible speed, the shunting locomotive transports the maximum number of wagons, no empty wagons have to be moved around and employees work as much as allowed without generating empty times.
If we switch to the network itself, we mean the transport of the wagons from the team stations to the large shunting yards and vice versa. Here the elaboration of the perfect production is more difficult.
As a first attempt it should be mentioned that in principle the following should apply:
- A wagon that has to be moved from A to B should not cause more rail-path costs due to possible detours than would be expected due to the shortest routing between A and B.
- A wagon that has to be moved from A to B should not remain in the system for more than some hours due to the possible speed on the optimal routing.
This means that the reloading and stopover of the wagons at the customer site should be as short as possible.
- Empty wagons, loco trains and shunting activities are to be avoided where possible.
- The locomotives should be used in a maximal way, ie constant with the possible maximum speed and the maximum load and 24 hours in use.
- The same applies to the drivers whose driving time should be on a maximum level.
Since it is fundamentally not possible to optimize all points at the same time nor to detect the perfect production state by simply analyzing some figures, it requires intelligent mathematical algorithms and simulations that weigh different states with their costs.
The goal is to develop an optimization algorithm in the direction of optimal production, which delivers proposals, how to change the network. We call such an instrument a “DdScalculator”.
To dive a bit deeper we describe the steps in programming such an algorithm:
Step 1: Definition of “Decision Quants”
In the classical approach, a shunting team (for an example, we focus on this part of the production) is controlled, for example, by means of a KPI such as utilization, which measures the effectively productive time in relation to the total working time. For example, a utilization rate of 70% means that the marshalers have "empties" of 30%. The setting of target sizes, however, becomes more difficult. While looking at a large number of shunting teams there’s a good chance to increase the measured average utilization rate from 70% to perhaps 71 or 72%, in the consideration of a single shunting team the cost blocks always change only in jumps. In fact, the costs of a shunting team can only be changed by the following factors:
- Number of marshalers
- Number of shunting locomotives
- Type of shunting locomotive, small, medium or heavy
Therefore a variable like the utilization - analogous to the cost blocks - always changes only in jumps. Instead of setting a target variable, it is therefore much more efficient to directly decide which target state is to be implemented. Instead of discussions about KPI's, concrete decisions take place.
Which decision quants do exist then for our shunting team?
The shunting team serves actually all loading places 1 – 13 without number 3 using 4 different tours. Antenna 4 with LP’s 14 – 16 is actually not serviced.
The following decision quants exist for the shunting team:
- Execution of a specific customer shipment
- Operating or non-operating a specific antenna
- Travel times according to route planning from and to loading places
And the following decision quants exist on the customer side:
- Modal choice of transport between rail and road
- Choice of wagon type
- Choice of desired and necessary departure and arrival times.
- Choice of the duration of stay for a wagon on site.
Step 2: Parameterize the production elements
The individual production elements must now be parameterized. The production elements include the customer shipment, the loading places and the individual defined last-mile tours.
As already described above, the customer shipments are displayed via S (C, Wg, LPs, LPr)
where C stands for the customer, Wg for the number of wagons, LPs the sending place and LPr the receiving station.
A loading place, in turn, LP (Wg, TtTS, TtSM). Is described by the following parameters:
- Wagons (Wg): Maximum capacity of wagons at the loading place
- Time to Team Station (TtTS): Time required to get from the team station to the loading place
- Time for shunting maneuvers (TtSM): Time required for the shunting maneuvers (hanging or appending) of the wagons on the company premises.
LP 6 (20, 120, 20) thus means that the capacity of the loading station 6 comprises a maximum of 20 wagons, that it takes 120 minutes from the loading station to the team station and the shunting maneuver takes 20 minutes.
A tour is characterized by the places it serves:
- Tour 1 (1 - 2 - 4; 4 - 2 - 1)
- Tour 2 (5 - 6; 6 - 5)
- Tour 3 (7 - 8 - 9; 9 - 8 - 7)
If you look at tour 1 and evaluate all customer shipments, which have their departure, respectively their final destination at the loading places 1, 2 or 4, then one finds the number of wagons, which are moved on tour 1. At the same time, the parameters provide the time needed for the tour.
For further discussions, let us consider the following parameters:
- Loading places 1, 2 and 4 are frequented by one customer each (customers 1, 2 and 4), each with 3 cars, both for delivery as well as for the pickup, so that the train is traveling at maximum with 9 cars.
The parameters of the charging points are:
LP 1 (5, 20, 5)
LP 2 (5, 30, 5)
LP 4 (10, 40, 10)
The time for delivery and pickup thus results in 2 * 40 minutes travel time + 2 * 20 minutes shunting activities = 120 minutes or a total of 2 hours
- The loading point 5 is frequented by one customer (customer 5) with 4 cars and the parameters are LP 5 (10, 50, 5)
The loading place 6 is frequented by a large customer (customer 6) with 15 cars and the parameters are LP 6 (20, 120, 20)
The time for tour 2 with the loading points 5 and 6 is thus 2 * 120 minutes of travel time and 2 * 25 minutes for shunting activities = 290 minutes or about 5 hours.
- Tour 3 normally comprises 12 cars and lasts 2 hours.
Tour 4 includes 14 cars and lasts 3 hours.
Step 3: Definition of production conditions – constraints of the model
The definition of conditions is the key element for the understanding of the cost incidence within the shunting team. Often these conditions are discussed by chance during visits in the
area, but systematically they are rarely addressed.
When the production processes are analyzed, the following rules (simplified) are found:
- A tour must be operated by a shunting driver and a shunter, ie 2 FTEs.
- They can work in one shift of 8 hours at a time. This means that if the total time for picking up and delivering all shipments from team station TS exceeds the value of 8 hours, at least a second shift is required (which can of course work in parallel).
- As shunting locomotives, there are 3 types to choose from, a light, medium and heavy. With the light, a maximum of 8 wagons can be moved, with the middle 14 and with the heavy 20 wagons.
- At the beginning of a tour all wagons are attached, then uncoupled successively at the loading places, and finally, in reverse direction, the wagons that were previously loaded are taken back.
- The goods of the customer can be picked up and shipped as desired within a period of one week - or the goods are time-critical and must be collected and delivered within precisely defined periods.
- The goods of the customer can be transported by any wagon - or the goods of the customer require exactly defined wagons.
- The customer can reload delivered wagons with other goods - or not.
Step 4: Calculation of production organization without optimization
Taking into account the parameters of step 2 and the conditions of step 3, the following production organization should be in place:
- 2 FTE (1 shunter, 1 driver) are working on tours 1 and 2 with a total duration of almost 7 hours and a heavy shunting locomotive
- 2 FTE are processing tours 3 and 4 with a total duration of 5 hours and a medium shunting locomotive
- The sum of the “empty” time is 4 hours. In other words, the two teams together have a capacity of 16 hours per day, which means that an empty time of 4 hours results in a utilization of 75%.
Step 6: Data supply
Data should be fully and automatically accessed out of the operating systems of Cargo and on the other hand out of publicly available external sources.
Step 7: Design of optimization algorithm
6. DdS.3 – From KPI-confusion to real potential detection
The new way and key principle for a controlling department now lie in the steering towards the above mentioned “perfect production”. In order to initiate this, it is proposed to adjust the KPI's following the results of DdS.2. In concrete terms, the KPI's should not measure the actual state but the "distance to the respectively optimal production", and therefore the possible potential for improvement.
The following examples are intended to illustrate the idea:
- If a delivery tour has unoccupied capacities and if there are any customer potentials on the route not yet acquired, this should be stated through the KPI "Unused transport potential on Tour X"
- If – in the optimal case - a tour could be completed in 3 hours instead of 6 hours this should be stated through the KPI "Waste time Tour X"
- If in the network a train-relation could be served by a small locomotive instead of a heavy one, then this should be stated through the KPI "over-motorization"
This means that the KPI logic is turned completely. Instead of a simple measurement of an actual state without an idea, whether it is good, bad or can be changed at all, the future KPIs always point to the optimal solution, which can also be achieved with appropriate management decisions.
The detection of these so-called "distances to the optimum" takes place in two ways:
- First, directly from the results of the mathematical optimizer
- Secondly, from the direct feedback of the area staff, which recognizes acquisition potentials or sees opportunities to design the delivery tours in a different way.
To ensure that these inputs are not simply ignored, the goal here is to systematically capture these inputs via an app and make them visible directly into the KPI system.
7. DdS.4 – From static management accounting to dynamic decision delivering
Using the DdS-calculator of chapter 5 the further development of management accounting is to determine the marginal resources and costs for lost or newly acquired shipments, instead of a fair but limitedly useful allocation of existing cost blocks.
For this purpose, the DdS-calculation must determine which cost items could be eliminated after a shipment has been canceled. Of course, the instrument must also be capable to combine several shipments together and to determine the same statement. In turn, the calculation must automatically provide the answer, which additional resources are required for a new shipment. Today, all such work is carried out manually and partly leads to great surprises after customer losses, as – out of management accounting – only a small amount of contribution should be lost, but in real production, no resources can be removed.
Instead of relatively heavy and expensive SAP architecture, the future IT landscape can be dynamized and simplified. It consists of the following elements:
- An intelligent DdS calculator with interfaces to
a) a simple system for financial accounting, with no need for any secondary postings,
b) the relevant operating systems with their basic data
c) app's of area workers for the collection of local conditions and potentials
And thus the future steering instruments are:
- Top-level of profitability analysis: Profit and loss statement from financial accounting – without a need for secondary postings within some complex SAP-system
- Profitability analysis of individual customers, relations, shipments carried out via the DdScalculator described above, delivering in addition to concrete measures for optimization.
The following topics can be addressed with this implementation:
- Direct steering or optimization of unprofitable shipments (MC negative)
- Review of feasibility and profitability of new shipments
- Review the impact when changing decision quants, e.g. consequences when closing a loading place.
- Introduction of optimization algorithms to deliver the most profitable situation.
Example: Dynamic calculation of margin contribution
For the delivery and collection of the wagons, the following (simplified) cost blocks are considered:
- Train-path costs: Directly depending on the weight and distance of the trains
- Personnel costs: For drivers and shunters
- Wagon costs: maintenance and depreciation
- Shunting loco costs: maintenance and depreciation
The goal of Decision-delivering Steering DdS is the mapping of a margin contribution “MC 1”, where the sales of one or more shipments are recorded against those cost blocks which are directly caused by these shipments and which could, therefore, be eliminated when the shipment is omitted.
For example, take the shipments of customer 5:
S (5, 4, LPs, 5) = customer 5, 4 wagons from departure point to LP 5
S (5, 4, 5, LPr) = customer 5, 4 wagons from LP 5 to end station
Remark: LPs and LPr are places outside the antenna’s 1 – 4.
These two shipments will be served on tour 2. If these shipments were to be omitted, then the team of tours 1 and 2 would still have to service customer 6 at LP 6. Only the time for the 10-minute maneuvering would be eliminated, empty time would increase. This means, that neither shunting staff nor shunting locos could be eliminated. In the margin contribution calculation which focuses on directly depending cost blocks, the line items personnel and shunting loco costs remain zero, the MC1 seems pretty positive.
|Shipments||S(5, 4, *, 5) and S(5, 4, 5, *)|
|Shunting loco cost||0|
Or take the shipments of customer 4:
S (4, 3, LPs, 4) = customer 4, 3 wagons from departure point LPs a to the loading place 4
S (4, 3, 4, LPr) = customer 4, 3 wagons from place 4 to destination LPr
These two shipments will be serviced on tour 1. If they were to be dropped, the team of the tours 1 and 2 would still have to serve the loading places 1 and 2. However, the time for the outward route to the loading place 4 and the maneuvering on the ground would be omitted, which would amount to a reduction total of 40 minutes. Nevertheless, as in the first example with customer 5, neither staff nor locos could be eliminated. The MC 1 stays positive:
|Shipments||S(4, 3, *, 4) and S(4, 3, 4, *)|
|Shunting loco cost||0|
Completely different the situation when viewing customer 6 with his shipments S (6, 15, LPs 6), S (6, 15, 6; LPr)
These shipments are also handled via tour 2. However, if these orders were canceled, the situation would immediately be as follows:
- The operation of LP 5 could be attached on the tour 1. It would then be 13 wagons with a duration for the tour 1 of 2.5 hours.
- Due to the number of wagons, a medium shunting locomotive is sufficient
- And it would also be possible to go on tours 1, 3 and 4 by a single team.
The conclusion is that the customer 6 with his orders binds an entire team of a heavy shunting locomotive plus 2 FTE. All line items in the margin calculation are filled out in this case, MC1 gets negative due to the fact, that many cost blocks could effectively be eliminated when giving up customer 6.
|Shipments||S(6, 15, *, 6) and S(6, 15, 6, *)|
|Shunting loco cost||300|
|MC 1||‚- 100|
Customer 6 becomes thus unprofitable, a renouncement of his orders is worthwhile.
The consideration of customers 5 and 6 together would lead to the same conclusions as customer 6 alone, but the two customers together are almost profitable
S(6, 15, *, 6), S(6, 15, 6, *), S(5, 4, *, 5),
S(5, 4, 5, *)
|Shunting loco cost||300|
|MC 1||‚+ 30|
Let us assume that a larger customer 3 asks if one can drive shipments to LP 3. The parameters are:
LP3 (20, 35, 10) = 20 wagons capacity at the LP 3, travel time 35 minutes, shunting time 10 minutes
S (3, 10, LPs, 3) = 10 wagons in the delivery
S (3, 10, 3, LPr) = 10 wagons in the collection
It is found that customer 3 can be served on tour 1. The duration is extended by 20 minutes, but the first team can still use the tours 1 and 2. As a heavy shunting locomotive is already needed for tour 2, the new number of wagons on tour 1 is no problem
|Shipments||S(3, 10, *, 3), S(3, 10, 3, *)|
|Shunting loco cost||0|
|MC 1||‚+ 300|
The very positive MC1 indicates that the new shipment can easily be run with the available resources, which greatly increases the utilization and the profitability in the system.
Example: Margin Contribution under consideration of the environment
The example above gets even more exciting, if we assume that the tours 3 and 4 no longer exist, that there are only the tours 1 and 2. In this situation, the omission of customer 6 leads to the fact that the remaining team can approach the loading positions 1, 2, 4 and 5 in a single time, but the team basically remains. What is changing is that instead of the heavy shunting locomotive a medium can be used. The margin contribution looks like:
|Shipments||S(6, 15, *, 6) and S(6, 15, 6, *)|
|Shunting loco cost||100|
|MC 1||‚+ 400|
This means that without the tours 3 and 4, it is not at all worthwhile to give up the shipments of customer 6.
Or let’s assume the following situation:
The customer 6 offers the tour 2 team the opportunity to take over the loading and unloading of the wagons and other logistical processes when they bring the wagons and pick them up. The duration of this work is 90 - 100 minutes and would be compensated with 300.
Since the team 1 with the tours 1 and 2 currently has an empty time of 70 minutes, this order can not be accepted at the moment. If, on the basis of this assumption, we examine the
contribution of the shipments of customer 4, we see the following:
If the customer's orders 4 were to be omitted, a time gain of 40 minutes would be obtained for the team 1, which would allow the additional service to be executed for customer 6. The
contribution for the shipments of customer 4 will be negative under these new environmental conditions:
|Shipments||S(4, 3, *, 4) and S(4, 3, 4, *)|
|Shunting loco cost||0|
|Lost customer orders||‚- 300|
|MC 1||‚- 230|
8. DdS.5 – New skills needed
The design and implementation of the DdS require the following essential skills, which differentiate from the typical controller profile:
- First, an in-depth understanding of the production process and effective on-site resource planning
- Second, the corresponding sales and marketing understanding of the customer's surplus-value
- Further the mathematical abilities to parameterize the production elements and to define the decision quants and constraints of the model
- At the same time, the IT skills for programming the necessary tools and / or the needed app's.
Basic education such as engineering sciences, mathematics or computer science are very suitable for the development of such skills. Furthermore, such graduate students are first likely to get involved in marketing or in the production of a company, in order to directly get the necessary "front" experience. At the same time, the opportunity to switch flexibly between marketing, performance management and operations also empowers any subsequent career.
Instead of a complex, costly, accounting-like management accounting with limited meaningfulness, a DdS-Calculator is implemented, which optimally combines the operational systems, inputs from front people and the effective cost incidence, and which generates direct optimization and decision-making proposals.
The advantages of such a solution are obvious:
- Effective bottom-line improvement of the business by generating concrete recommendations
- Elimination of large manpower for analysis of data
- Complete elimination of internal clearing costs
- Lean, affordable and flexible IT architecture
- Scalability in the direction of automation of forecasts, budgets, and multi-year planning
- Reduction of controlling specialists in favor of so-called quantitative business modellers.