Large corporations sometimes argue that their SAP implementations did not deliver the benefits they expected and that the software is too rigid to support continuous improvement. The experience of Deloitte has shown that the perception is largely due to SAP’s high degree of integration. However, it is not supported in practice. Integrated solutions and flexibility are not mutually exclusive. In a fully integrated SAP environment, most improvement efforts will naturally have enterprise-wide ramifications, which often take time to resolve. However, system integration is frequently used in enterprises for political ends, in order to centralize strategic functions beyond SAP really requires. The resulting centralized departments often behave with the inefficiency and disregard for quality and client satisfaction that frequently characterize monopolies. Blaming the software under these circumstances, however, is like blaming the car for an accident when the motorist was driving recklessly.
Short-term cost reduction . . .
A couple of real-life examples may shed some light on how these problems occur. A large European bank decided to replace its complex landscape of accounting, consolidation and group reporting systems with SAP. The idea was to hold the G/Ls (General Ledgers) and related functions of all its subsidiaries in a central SAP R/3 solution from which the group consolidation and reporting systems would be populated. In the past, the local G/Ls, the group consolidation and reporting systems, and the Excel sheets they used as their main planning device had not been integrated technologically and, as a result, required a lot of manual work, including “by hand” data transfers and reconciliations. Nonetheless, the system worked because their support teams were typically local (often physically close to the end users), knowledgeable (many had also “fathered” the systems they were maintaining), and non-bureaucratic. Because one of the key advantages of the new SAP solution was its integration, it made sense to create a large “center of expertise” to support it, with the expectation that the resulting synergies would reduce the overall cost of support.
However, things did not go exactly as planned. Because the support center was so large, its leadership became a power center in itself. Soon, there was a political push to centralize support functions that would have been more effective had they remained close to the end users, whatever the underlying software.
. . . at the expense of long-term performance
Also, the center’s leadership aggressively pursued cost reduction, which was one of the most visible drivers of change and one of the most politically rewarded performance factors. To do this, management hired very unqualified – and therefore relatively inexpensive – personnel. Unable to depend upon these resources to perform their jobs efficiently, the center’s leadership instead relied on a heavy bureaucratic structure to keep the system moving. This approach was applied to other cost items, such as machine sizing, for the same reasons: the cost of the system was highly visible while the cost of poor system performance at the end-user level was not.
The two prongs of this strategy, cost reduction and bureaucracy, supported each other, at least for a while. Perhaps luckily, the leaders of the support center were too aggressive in their pursuit of short-term cost reductions at the expense of long-term performance. Eventually, end-user complaints became so loud that they reached the highest levels of the organization. This led to an external audit of the “center of expertise,” after which its leader was invited to leave, scarcely three years after the system had been put in place.
A global chemicals firm decided to implement SAP worldwide. At the time, however, it was wrestling with internal political issues, including the desire of the European headquarters to reign in a large US subsidiary that often acted independently. Partially due to this political consideration, the company decided to push standardization to the lowest levels of the global design, especially within the financial area. Thus, the global guidelines demanded centralized definitions of the group’s operating chart of accounts (CoA), the dimensions for profitability analysis, the activity types – even the names of the cost centers. In many cases, these tight rules resulted in an unnecessary bureaucratization of the accounting process.
Perhaps the most dramatic example of this complexity was the global operational CoA. In such a large diversified business, it was inevitable that every site and business area would have its own unique requirements for specific G/L accounts. Thus, very soon the CoA grew to include several thousands listings. The enormity of the chart soon posed a problem to the team maintaining it. For every new request to open an account, they could either go through the painstaking process of analyzing all of the existing accounts and then discussing and negotiating any changes with the requesting site, or they could simply add the new account regardless of any overlap with existing ones.
Since people often made new account requests at the period-end financial close, there typically wasn’t a lot of time for discussion. This encouraged the team to take the latter option more frequently. Gradually, the chart of accounts grew even more immense, ultimately becoming unmanageable for reporting and other purposes. As a result, reporting, in particular, had to rely on very complicated, manually-maintained hierarchies or on small, local system developments that – patchy and inefficient as they were – at least allowed for relatively effective Management Information analysis for the local sites.
Taking full advantage of SAP integration
Fortunately, there are both technical and organizational ways to avoid these traps and to still take full advantage of SAP integration. The first and most important element of a solution is always the recognition of the problem and its real causes. Once this is done, the following elements of technical and organizational advice can be helpful:
SAP’s high degree of integration is one of its most powerful characteristics. However, the need for standardization that it imposes is often overemphasized at the executive level, especially in the finance and controlling area. For example, SAP allows each company code within the group to have its own operational CoA as well as to share a unique group CoA to which all the local accounts are mapped many-to-one. FI transactions using the group accounts can even display down to each individual posting, while the local end-users still post using their own operational CoAs. Thus, as long as the local sites are required to accurately map each one of their local accounts to the corresponding group ones, there is enough flexibility for them to manage their own CoAs.
Similarly, one should remember the distinction between the CO (controlling) and EC (Enterprise Controlling) modules. In many instances, it makes sense for the group to define the profit centers within EC, for example, and to allow the local sites to define their cost-center structures in CO as they wish. This sort of approach gives the sites sufficient independence to manage most daily issues by themselves, while enabling the group to maintain full drill-down capabilities from the highest level to the lowest.
Organizational approaches to avoid over-centralization
Over-centralization, and the bureaucracy it usually entails, is a serious danger, especially in very large organizations. The support organization should always include a “Tier 1” support level at the sites. This team should be empowered to resolve a large number of day-to-day issues, such as writing a new report, or creating an operational account and mapping it to an existing group one. Sometimes, cost implications can limit the size of this local support level, especially if one of the driving factors behind centralizing the support function was to move it to a lower-cost location. This challenge can often be overcome by training and authorizing local “expert users” to provide “Tier 1” support in addition to their business-related jobs, thus greatly minimizing costs.
Similarly, the “Tier 2” support level should also be as straightforward as possible. Ideally, the same support person, or small team, at the center of expertise should be assigned as the primary contact for every site, so that users do not need to reiterate the context every time a new issue pops up.
System support linked to business
In addition, the system support function should ideally not be separate from the business but subordinately linked to it. The reason should be obvious from the examples above: if the IT support function is separate from the business it supports, the center of expertise can be tempted to behave as a monopolistic service provider with a captive customer base. Therefore, if it cannot increase the price, it will reduce the service level. This is one of the reasons why outsourcing contracts have such a high failure rate and why external vendors are much more successful at curbing costs than at improving service quality: there is not much difference between an internal monopolistic IT department and an external semi-monopolistic vendor. In our experience, the service quality is much improved when the provider reports directly to the function it supports.
Because SAP is an integrated system, there will always be functions that will need to have a high level of centralization. However, organizations should try to keep centralization to a minimum, rather than to expand the areas under consolidated control to their limits. Moving ahead, keeping things simple will be an important guiding principle for any company that wants to get the most from their SAP investments.