Chemicals giant ICI saw nearly 40% wiped off its share value last
week because of business process problems arising from a new IT
implementation ICI pays price for side-effects of IT project
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.