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 reference system 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 around the world is often faced with a major question in the choice of its management control tools (platforms for budgeting, forecasting, monthly closings, etc.). Indeed, should subsidiaries be forced to use centrally selected tools and applications developed by the group, or should they be left free to carry out their IT projects locally? In fact, these questions are all the more relevant as both approaches have their advantages and disadvantages.
More global coherence...
The first school of thought, that of centralizing management solutions, has clear advantages. The information systems defined by headquarters and shared by the subsidiaries support the implementation of cross-functional processes. They guarantee the sharing of KPIs (key performance indicators) and promote the consistency of analysis within the group. In addition, adopting a single software solution for the entire 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, the subsidiaries can concentrate on their core business, instead of being dispersed in the management of IT projects and the maintenance of information systems.
...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, counterbalanced by the advantages of the second approach, namely the implementation by subsidiaries of their own management solutions . On the one hand, the local specificities of the IT markets, such as the predominance of a particular software or a particular publisher in a particular country, are taken into account. This allows the subsidiary to better adapt to its ecosystem, while benefiting from better support. On the other hand, 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 the country's 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.
