Avoiding a roasting over Emu

It’s headless chicken time. With the start of Economic and Monetary Union probably only 14 months away, it is a pretty safe bet that a fair number of FDs will soon be doing a passable imitation of decapitated poultry.

Reports from the front-line suggest far too many companies have not squared up to challenges presented by the euro’s imminent arrival.

The latest heavy weight research – a survey of 485 multinational companies by Price Waterhouse – suggests, in many cases, “preparations for Emu are a long way short of complete, even in the high-impact business areas.”

Not least of the problems facing FDs and other senior members of the management team – when the time comes, it won’t only be FDs in the hen house – is what to do about IT, especially accounting software. This weighs particularly heavily on FDs for two reasons.

First, FDs more often than not carry board-level responsibility for IT.

An IT director on the board is still the exception rather than the rule.

Second, the accounting and financial management systems will bear the brunt of Emu changes. (But they are not the only systems to consider – see “The bigger picture” panel, page 36.)

Those FDs happily expecting their accounting software developers to have solved euro conversion problems are in for a nasty shock. The developers are already in the chicken run. The harsh reality is that most of the best-known and widely used accounting software cannot cope with Emu.

Worse still, the developers are still struggling to give their packages Emu functionality. But it has not been all their fault. The main providers, such as Computer Associates, IBM, JBA, Oracle, PeopleSoft and SAP, simply haven’t known what to do.

In this case the blame lies with the politicians. It was not until July – just 18 months before euro-day – that Yves Thibault de Silguy, the grandiloquently named and titled European commissioner for economic and financial affairs held a meeting with members of the European IT Services Association (EISA) to discuss the software implications of Emu.

For months, Europe’s IT industry had been seeking “urgent clarification” about what they should be doing to make their systems handle the euro.

“We had been lobbying hard for the meeting because time is rapidly running out,” said EISA president Robert Guillamot. “There remain a great many IT business issues which need to be resolved before software developers can hope to make their products Emu compliant.”

Even that, as Guillamot pointed out, was only the first step. “System integrators will then have to install and implement the upgraded systems which, even now, will leave very little time.” As Guillamot and his team trooped out of the meeting he said he was “very encouraged” by the response from de Silguy. But the encouragement proved to be double-edged.

De Silguy revealed that most of the detail about accounting and reporting rules were being left to national governments to sort out. Charles Brewer, chairman of the finance and banking group of the Computing Services and Software Association (CSSA), who was at the meeting explains: “That means individual IT companies have to seek information from each country, all of whom are working to different rules and timescales.” And, it should be added, with different levels of enthusiasm and competence.

De Silguy also delivered another nasty blow to the already reeling software industry. Quoting rule 235 of the Maastricht Treaty as his legal authority, he revealed the European Commission had decided that no cross-currency rates would be published between participating national currencies when the euro was up and running.

The IT team was hardly out the door before the awful implications of this had sunk in. It meant that the only published rates for participating currencies would be to the euro. There would be no crossrates published between, say, the French franc and the deutschemark. Moreover, the only published rates to currencies outside the single currency area would be to the euro. So if the pound is outside, it would have a rate to the euro – but not to the franc or the deutschemark inside.

“All this means that francs must be converted to euros and then from euros to deutschemarks using the published conversion rates of six significant figures,” explains Dennis Keeling, director of the Business Accounting Software Developers’ Association (BASDA). “Yen or dollars will use the cross-currency rate to the euro and then the euro will be converted to the national currency.”

This is called “triangulation”. Pythagoras would have loved it. Software developers hate it because it means none of their software can cope.

“At first glance, these seem straightforward conversions which could be handled by any multicurrency package,” says Keeling. “Unfortunately, this is not the case and every accounting software package will have to be rewritten in order to handle the intermediate euro stage.” But why should this seemingly simple regulation be causing so much trouble?

“At present, multicurrency accounting software uses a conversion table based on cross-currency rates between the local currency and foreign currency,” explains Keeling. “The Emu triangulation principle will require accounting software to hold the cross-currency rates between the local currency and the euro as well as the conversion rates between the euro and the currencies in the single currency area. This will have a significant effect on software developers.”

You can say that again. The main developers have been scrabbling round since July trying to decide how to handle triangulation. Privately, the developers admit building triangulation into their packages is “very difficult”.

This is because most use a simple two-column table to link one currency to another. The table in the first column shows the local currency, the table in the second the foreign currency equivalent.

To cope with triangulation means putting in a third column. And that is nowhere near as easy as it sounds because currency conversion routines tend to run right through the software. Multicurrency doesn’t operate only where you most expect to find it – in the sales ledger. It also appears less prominently in sales order processing, purchase ledger and other places.

If that weren’t enough, there are also other problems. For example, because each country is introducing its own legislation to define the use of the euro in different reporting situations, it won’t be possible to produce one reporting approach in the software and apply it easily across Europe.

“The situation is analogous to handling VAT,” syas Keeling. “Each country has VAT but handles it in a slightly different way.” So while government departments in some countries might require euro reporting immediately, other countries may stick with the local currency until later in the transitional period.

This brings us to one of the trickiest problems of all – when to introduce this myriad of changes into the accounting packages. The easiest way would be to get it all over in one go – the “big bang” approach. Unfortunately, that is not possible because the picture during the transitional period – lasting for three and half years until July 2002 – will be messy to say the least.

Some companies – such as Siemens and Michelin – have already signalled they will be adopting the euro as soon as possible. Others will leave it to later. Some will use euros for transactions, but retain reporting in local currencies. It means most companies need staged developments in their accounting software to handle changes as they happen. Sometimes, they will need to handle both local currency and euro in parallel.

Handling all these changes in this way is a nightmare for the software developers. No wonder only SAP and PeopleSoft were originally the only two which said they would do it. “The other developers laughed at them,” recalls Keeling.

But they have had the smiles wiped off their faces. At a key meeting of BASDA this autumn, most of the large accounting software developers acknowledged that the “big bang” approach was unworkable and that they would have to do a phased conversion. Even now, with Emu almost here, software developers are still complaining about lack of information from the EC and national governments.

“We expressed clear concerns about the lack of information or incomplete information,” says Rob Wirszycz, director general of the CSSA, who was at the meeting. “We are also worried about the readiness and awareness of the bulk of European business and the ability of the software industry to deliver appropriate products.”

De Silguy complained the EC had difficulty getting information out of national governments. Partly true, says Wirszycz. “But I believe the EC has the responsibility to coordinate and facilitate and it was heavily impressed on them that they need to take that role,” he adds.

There should be another meeting of the Euro IT Forum before Christmas.

If the EC hasn’t made significant progress, there could be fireworks.

Meanwhile, Chancellor Gordon Brown has instructed his own Emu advisory group to produce a report on IT and systems implications before the festive season. According to insiders, the reports’ findings for UK industry could well put the chancellor off his turkey and plum pudding.

All this should be causing FDs more than a measure of concern. “I am warning customers to speak to their software developers and to see exactly how far they are going with the phased approach,” says Keeling. “Don’t assume they are doing everything properly.”

He warns: “Some package suppliers will give their clients a lot of flexibility about how they convert their systems to handle the euro. Others are going to put their clients under pressure to do big-bang type conversions over a weekend and hope it works out at start of business on Monday morning.”

In other words, now is the time for FDs to start asking some blunt questions of their software providers. Keeling advises: “I would want to know how prepared the developer is for the euro. Is it taking an active interest or is it just sitting back and waiting?

“Secondly, I would like to know whether this means I have to upgrade my software yet again to meet these needs or is it already within the scope of the current version? For example, if you’re upgrading for year 2000, will Emu be in the same version of the software?”

And there is a host of practical questions about how the new software will work. Will the new version be complete or just a first phase? Will it deal with triangulation? Will it allow you to compare this year’s results with previous in euros? Will the drill-down functionality work on figures going back two or three years? Will it be possible to use euros or national currency for reporting during the transitional period? No doubt, most FDs can add plenty of questions to this list.

But at the moment there are more questions than answers. FDs need to find the answers fast if they are to avoid the inevitable fate of most chickens, headless or otherwise.

Well and truly stuffed.

THE EMU SYSTEMS OPPORTUNITY

Turn a problem into an opportunity, the management consultants say.

So could the introduction of Emu be used positively as a catalyst to stimulate long overdue structural changes to the way IT is organised in many companies?

It would be nice to think so and research by Price Waterhouse shows that some companies, at least, regard Emu as “an important driver for structural and system-based changes”.

Nearly one in five companies among Price Waterhouse’s sample of 485 multinationals thought it was more likely that Emu might encourage them to try outsourcing.

More than half said Emu could stimulate a move to enterprise-wide systems and slightly less than half to shared service centres (SSCs).

While this represents a laudatory positive attitude for most companies it represents not much more than striking a pose. Quite simply, they have left it too late to do anything about these issues before Emu is upon them.

“If you are a very complex large organisation and haven’t started yet, you are probably going to have enough on your plate just getting the operational aspects of Emu sorted out,” says David Swann, a principal consultant at Price Waterhouse Management Consultants.

That is not to say that Emu, if it succeeds, might not make SSCs and enterprise-wide systems more likely. Indeed, the ability of enterprise-wide systems to automatically handle every knock-on accounting transaction from the moment a customer places an order, makes them a natural for an enlarged single market. “The absence of a true single market and currency has stopped some companies moving towards SSCs,” says Swann.

But because an enterprise-wide system, run from a single SSC, still has to produce reports that meet the peculiar needs of each country’s reporting regime, they are complex to set up. “That places a lot of emphasis on filtering and reformatting of information and on the efficiency and extent of the system installed,” says Swann.

So it is fine for an FD to think positively so long as he doesn’t get over enthusiastic. With Emu looming closer, it’s more important to think realistically.

THE BIGGER PICTURE

Accounting software is not the only IT issue FDs need to focus on as they plan for Emu. Research published by Andersen Consulting suggests FDs should conduct an Emu audit of four key areas:

Transactional systems:

– Production including materials requirements planning and just-in-time

– Logistics and distribution

– Sales

– Payroll

– Accounting/consolidation

– Treasury/banking

– Electronic commerce including electronic data interchange

Management information systems:

– Management information systems, executive information systems and decision support systems

– Data warehouses

Peripheral systems:

– Automated teller machines (ATMs)

– Electronic point-of-sales systems (EPOS) and Point-of-sale systems

– Ticketing machines

– Petrol pumps

– Electronic payment terminals

Personal applications:

– PC-based packages

– Spreadsheets

– User-developed databases.