There are many technical approaches that promise to improve the ability of an enterprise to gain visibility of its data across the entire organisation. ERP was one such, as was business intelligence and its cousin data warehousing, and the latest is master data management.

While each have had some impact, in very few cases have they truly delivered. Despite vast amounts of effort in implementing these technologies, most firm struggle to answer basic questions about their business performance.

One reason why global initiatives can struggle, and one that is not talked about very much, is company culture. I have worked for two large multinationals, one highly centralised and head-office driven, one with a history of being decentralised, where the central office had a largely guiding and co-ordinating role.

Both were highly successful firms, yet their respective cultures had a significant impact on the likelihood of success of global IT initiatives.

In the case of a decentralised culture, there is a tension between the local operating company and central office. The local companies see the head office as remote and an unnecessary cost burden, demanding all kinds of data and imposing policies that have no use to the local firm.

The people in central office view the operating units as obsessed with their own interests at the expense of the shareholder, and unable to see the big picture. One of my ex-bosses described the problem succinctly: "The operating companies think they are freedom fighters. We know they are terrorists".

In such an environment, central office initiatives are viewed with suspicion at best, and in some cases outright hostility. Hence when someone in central office comes up with a whizzy new plan to standardise something: applications, data definitions, business processes, it can be a titanic struggle. The more impact that the proposed change has on the operating units, the harder they fight.



In the case of centralised companies things at least appear easier from the perspective of head office, and indeed if there is a culture where people are used to doing what they are told then implementing enterprise-wide change is more likely to succeed. In practice, of course, some of the underlying tensions remain, but the subsidiaries generally grumble and get on with it, while possibly running a ‘shadow' set of systems that actually do what they need.

What has this got to do with software implementation? Well, in a decentralised culture it is exceedingly hard to roll out standardised solutions. Recognising this means that it may be preferable to change the architecture of the project to suit what is more likely to succeed.

In one project of which I was the architect in a decentralised company, we deliberately implemented a data warehouse in a federated structure, where each operating unit had its own little warehouse, with a feed going back to the centre. This was more complex, but in this way each subsidiary was in control of its own warehouse, and it could be tailored to address the needs of the local operating unit. A feed of data to central office provided what was needed there. Provided that the operating company did not fundamentally alter certain core classifications, this dual-use approach could keep everyone happy: the operating unit could add local data and reports as needed, while central office got its data.

If you try and fight the company culture then things can go badly wrong. One project I can recall seeing at a decentralised company involved getting just five subsidiaries to standardise their business processes so that they could have a shared ERP system. The companies were each broadly similar sizes and on the same continent. But $120m later, they ended up with five separate ERP implementations rather than one.

Such experiences are not confined to large corporations. I was chatting this week to someone in a small international firm. They had failed for years to get standardised definitions agreed between their different regions. But they finally succeeded when someone in head office had the bright idea of appointing the most vociferous subsidiary to standardise the definitions, in a sort of poacher-turned-gamekeeper approach. The other regions, used to defending each other against central office, found it much easier to work with one of their peers, who in turn saw it as a matter of pride to show those people at central office how it should be done. The result was a unified set of definitions, for the first time.

Systems integrators and technology vendors tend to have very standardised offerings, but usually there are some choices that can be made in the way that technology can be implemented. By recognising the culture of the company, and adapting the approach to what suits that company best, there is a much higher chance of a successful project.