The heavy cost of failures in software projects hit home last week when ICI lost 39% of its share value - about £400m - after warnings that its pre-tax profits were expected to drop to about £50m from £66m last year.
The desperately poor figures - which saw ICI shares hit a 28-year low - were in large part brought about by failures in the implementation of a SAP-based supply chain management system at the company's Holland-based fragrance-making subsidiary Quest.
Quest was to launch ICI into a key market for expansion, but problems with the SAP project, carried out in partnership with Xansa, resulted in the company's first quarter sales forecast for 2003 plummeting by nearly 70% as existing customers, unhappy with unfulfilled orders, jumped ship to buy elsewhere. The debacle cost Quest chief executive Paul Drechsler his job.
ICI's chief executive Brendan O'Neill is facing calls from disgruntled shareholders for his removal, and in a briefing to analysts moved to calm fears, saying, "Some customers say they will return business to us if we increase supply chain reliability: this has improved in the past six months."
Although ICI was confident it had eliminated the supply chain difficulties by last autumn, its year-end results revealed that the effect of oversights in the IT project have gone right to the top. But what kind of errors can have such far-reaching effects?
The ICI communication department, when confronted with this question, was not forthcoming. "There was a problem with a software implementation. It has been fixed. We will not go into detail about it," it said.
But IT experts in the chemical industry, some of whom have worked for ICI, said the problem lies in faulty planning about how business processes would be affected by the new software, rather than the technology itself.
One consultant told Computer Weekly, "They did not have a problem implementing the software, it was the business processes where things went wrong. It was at the point where people had to actually carry out actions that things went wrong. Where before they used a fax machine to fulfil orders and people were used to the system, when the new software was put into place people did not know when to carry out the delivery, they did not know where the product was in the warehouse."
Putting in software is one thing, but successfully mapping it to business processes that work for your business and, crucially, work for the people who make up the business is quite another.
This is where the Quest supply chain management project went wrong. But how can IT professionals avoid such pitfalls?
A number of methods of working, from detailed implementation tactics to high-level strategic changes in the way IT is viewed can help, say analysts.
Simon Bragg, an analyst with ARC Consulting, said such failures are becoming rarer but businesses can still learn better ways to get employee buy-in to new business processes.
"Supply chain implementations that fail to the extent that the company loses customers are becoming rare, as most consultants have gained sufficient experience [to get them right]. These days, supply chain management is a mature technology, and implementations should be reasonably smooth. Nevertheless, Quest appears to be joining a list that includes Hershey and Nike.
"However, in the SAP partner ecosystem, consultants often just want to set appropriate parameters to configure the solution, and they lack the business process re-engineering expertise. Typically, they have great expertise in, say, the materials management module, but that does not make a supply chain expert.
"Usually, designing the new business process is the most difficult part, mainly due to company politics. A good first step is to choose the right target metrics for each operation/manager, and say, 'To achieve these new metrics you may want to consider this new supply chain management solution'. By creating a problem for managers and then providing the solution, the implementation team gets faster buy-in."
But if the repercussions go to the top, the solution should too, said Nigel Montgomery, research director at AMR Research. To avoid finding themselves in the same difficulties as Quest, he advocates board-level recognition that the role of the chief information officer is to deal with business information, not just information technology. "The 'I' in CIO should not be seen as just to do with IT," Montgomery said.
"There has been a major shift in the market, in terms of suppliers looking at the implementation methodology, recognising that it involves a process change, not just a software change. Many suppliers have found that even where a problem is not a software one it can still come back to bite them.
"Imposing existing software business processes on a company is OK as long as the user is prepared to change its political organisation, otherwise it is like pushing a square ball up a hill.
"It is perhaps most important that someone at executive level ensures information visibility and transparency across the business. We call the position a chief information officer but that is often not what they are. It should be about ensuring visibility across the business' processes and information requirements, not about the software or solution for a particular need. Stand back and say, 'What do we need to achieve?'"
The lesson is that when companies can take hits of hundreds of millions of pounds, as ICI has, it is worth looking at your own business and making certain that the interface between the strictly technical tasks of software implementation and the information requirements that flow from how your people work have been subjected to due diligence.