The dilemma of international groups: centralize performance management or adopt a local solution?
By Anne Calmet, Financial Performance Manager, Micropole
The choice between a centralized approach that standardizes reporting in a common repository, and decentralized tools that are closer to the specific needs of each subsidiary, can be a difficult one.
An international group with multiple subsidiaries spread all over the world is often faced with a major question when it comes to choosing its management control tools (platforms for drawing up budgets, forecasts, monthly closings, etc.). Should subsidiaries be required to use tools selected centrally and applications developed by the Group, or should they be left free to carry out their IT projects locally? In truth, these questions are all the more pertinent given that both approaches have their advantages and disadvantages.
More global coherence...
The first approach, that of centralizing management solutions, offers clear advantages. Information systems defined by head office and shared by subsidiaries support the implementation of cross-functional processes. They guarantee the sharing of KPIs (key performance indicators) and promote consistent analysis across the group. What's more, adopting a single software solution for the whole group gives you greater negotiating leverage with software publishers and solution integrators, and also limits implementation and maintenance costs by setting up centralized skills centers. Finally, subsidiaries can concentrate on their core business, instead of spreading themselves thinly across IT project management and systems maintenance.
...or a better consideration of local specificities
These undeniable benefits in terms of global vision, consistency of tools and repositories, and cost reduction, are however outweighed by the advantages of the second approach, namely the implementation by subsidiaries of their own management solutions. On the one hand, local specificities of the IT markets, such as the predominance of a given software or publisher in a given country, are taken into account. This enables the subsidiary to better adapt to its ecosystem, while benefiting from improved support. In addition, local business needs are better addressed, thanks to the proximity of project skills and business users. In particular, the language barrier does not arise when projects are carried out locally. Finally, local upgrades and maintenance are more agile, at least if local integration resources are abundant and competent.
In short, the risks of rejection by subsidiaries are lower when solutions are chosen and implemented locally. However, the risks of failure of projects carried out directly by subsidiaries are higher, if only by a simple game of arithmetic: local projects will be more numerous, the tools more varied and the skills more diluted around the world.
