Digital Transformation » Technology » Financial Software Decisions – Global implementation

During the past decade, many FDs have been caught in an uncomfortable dilemma. As their businesses have globalised, they’ve had no option but to try and implement global systems to manage them, even though they know from bitter experience that these systems won’t always deliver the hoped-for benefits.

A year ago, PA Consulting Group found that a staggering 92% of companies were dissatisfied with their ERP systems, which are one of the most common global applications. Small wonder, then, that many FDs shrug their shoulders and expect a big bill and few benefits when the IT guys start talking global roll-out.

But it doesn’t have to be that way. Behind the headline disaffection, a few companies are beginning to discover the secrets of implementing global systems successfully. One is Rio Tinto, the minerals and mining giant with interests on just about every continent.

Graham Otter, the company’s head of information systems and technology, leads a strategy group that makes IT recommendations to the Rio Tinto main board.

He says that, when Rio Tinto implemented ERP, it first developed common business processes for the relevant applications. Then it turned those processes into a template which all business units could use as ERP was implemented throughout the company. “We got a lot of input from the different business units and agreed the common approaches that were going to be encapsulated into the package,” he says.

The implementation team also worked with individual business units to identify gaps which might be missed by the common template. “There were some local variations, particularly in the HR part of the implementation,” says Otter. But, in general, only about 10% of the implementation needed tailoring to local needs.

Significantly, Rio Tinto created a clear control structure with a standard-setting body that passes its conclusions on to steering committees that roll down through product groups and business units, so common messages and implementation processes can be communicated to all parts of the company.

“The cascading concept is the important principle behind this,” says Otter. “Without it, there would be too many touch points to control from the centre.”

Peter Lumley, head of enterprise-wide solutions UK at PA Consulting Group, has been helping multinationals implement global software projects for six years. Too often, he sees situations where management teams are planning a project but can’t spell out clearly enough the benefits they expect it to deliver.

He recalls a project involving three centres – UK, Denmark and the Far East – where managers’ different approaches were sending the plan off the rails. The problem was that each centre was coming at the project from a different direction. The UK team were bullish and wanted to move quickly, the Danes only wanted to progress by consultation and the Asians were desperate to do something and keen to grab any technology that might help.

“We had to step back from the different geographies and discover what was really needed. We found somebody in the company who was senior enough to provide a unifying driving force for the project – namely, the need to reduce costs by 20%,” he says. That provided the common focus all three centres needed in order to work to the same objectives.

Lumley believes that senior management too often doesn’t agree the central principles behind a global software implementation. Even when it does, it still needs to spell out the specific benefits each part of the company will be expected to deliver when the system goes live. “If you tie somebody down with a target and expect them to deliver, they take their responsibility more seriously,” he says.

A constant problem with global software projects is that every country wants something different. Lumley argues the key to avoiding this problem is to understand the principles behind package-enabled change. “It’s largely about sticking to the vanilla processes,” he says. He points out that most major packages provide processes that will work in many industries.

Lumley uses a storytelling technique – describing a company’s business processes in narrative form – to show how they have common features with the proposed software package. This approach also helps managers identify features of their business processes which don’t add value and which can either be removed or telescoped into adjacent processes before the software is implemented.

Studying the processes may also stimulate some lively debate about how to organise specific tasks throughout a global company. For example, increasing numbers of companies are moving towards shared services, where they create a centre of excellence for, say, accounting. It is vital to get agreement on these strategic issues before any software is rolled out.

Lumley believes a key problem with many global software roll-outs is that managers haven’t agreed on the principles that will be used. He says it’s important to keep the central kernel of the software – which is responsible for at least 80% of the functionality – standard, and to take a firm decision not to change any of it until at least halfway through the roll-out.

This approach will prevent the need for scores of small changes as the first local managers use the new system. But there should also be what Lumley calls a “local envelope”, which can be tailored to local circumstances.

“The challenge for the roll-out team is to stand up to the guys in France, Germany or wherever, and ensure that they don’t make early changes outside the local envelope,” he says.

It is important to re-visit each site a few months after roll-out to optimise the system. This is when local experience of using it will have thrown up ideas about how the first-cut can be improved. Again, it is vital to make sure that general improvements are rolled out across all users of the system globally, although different countries may also have changes they want to make within their local envelopes.

Lumley believes that one reason some global software projects fail is that implementation teams adopt a “hit and run” approach. They install a system on one site in one country and then decamp to the next. The solution is to leave behind a “swat squad” to deal with local problems and technical glitches. Exact numbers will vary from project to project, but typically the squad would be a couple of people for the first month after going live and one for the second. “The support side is just as important as the technology,” Lumley says.

Once the new software is in place, it is important to make sure staff use it and don’t work “off system”. Partly, staff will use the software if it delivers functionality they want. And if it supports improved business processes, users will have a strong incentive not to work off system.

Staff are also more likely to use a new system if the various change management and behaviour issues that arise at the front-end of the project are dealt with. Otter says: “The headline message is people, people, people.

You can’t do enough to get people on-side. You must get people empathising with the project and with its objectives and you must train people to leverage what you are delivering.”

One way to ensure these favourable outcomes is to make performance measurement reflect correct use of the system. “Put in measurements based around doing the right process,” says Lumley. A new publication from CIO Connect*, the forum for senior IT executives, spells out some of the measurement lessons as well as providing broader advice about harvesting value from IT.

There are key differences between managing global projects and local ones. “The key is making sure a wider group of people come together and play to the same objectives,” says Otter. Globally, this is perhaps easier said than done. But a company that succeeds will see some cynicism about IT melt as the benefits appear.

astering the Art of Juggling: achieving real value from IT investments is at


When US-owned chemicals giant Huntsman bought ICI’s global polyurethanes business, the new management decided the company needed global systems to support its growth. Managers identified real “step differences” in the systems Huntsman Polyurethanes was using in its three main trading regions – Europe, North America and Asia/Pacific.

Managers reckoned there would be a big win if each region could use common systems for key tasks such as cost and management accounting, profitability analysis and planning.

But, as Kurt de Ruwe, Huntsman’s global IT director, explains, before implementing a new system, the company wanted to make sure there was a real need for it. Twenty top managers met to assess how far the company operated common business practices. The meeting was sufficiently encouraging, says de Ruwe, to move on to a more detailed study of what would be needed from a new system.

A group of 50 operational staff then met to look deeply at the operational needs of a new system. They found that around 80% of the functionality could easily be the same throughout the world. But each region had its own peculiarities. For example, North America needed joint-venture accounting arrangements, Europe required tailoring for national VAT regulations, and Asia needed amendments to handle fiscal reporting in China and Taiwan.

The roll-out of what Huntsman called Project Atlas was planned in three phases, with Asia first, followed by America, then Europe. Huntsman hired UK consultancy Diagonal Consulting to provide project management and technical support. De Ruwe says: “To minimise the deployment period, we instigated the phases as far as possible in parallel.” In practice, there proved to be a few months delay between the phases.

Project Atlas centres on a Global Data Centre in Europe – chosen because Europe had most expertise in the SAP software being used. However, de Ruwe explains there are six functional support centres round the world.

“We set these up because people like to be close to human contact and to encourage buy-in from local managers,” says de Ruwe. “They also help to overcome the problem of dealing with staff in local languages.”

One of the key success factors in the project has been a Customer Competency Centre, with teams in each region that provide user help, and system and process improvements. “In a sense, the deployment was the easy part. Obtaining and retaining everyone’s commitment – in senior management, sales, operational and production staff – is a mighty challenge,” says De Ruwe.

The last phase of the project went live at the beginning of July. De Ruwe says that the early signs are that the programme will deliver substantial direct benefits for Huntsman.