The packaged software solution to performance problems

In both North America and Europe, a few major companies are still using bespoke systems that were first installed in the 1970s or even earlier and have been added to and updated ever since. Most organizations, however, prefer to buy packaged solutions to control their main business functions. For them any significant improvements in the packaged systems available are welcome if their availability coincides with a previously perceived need to change systems, and unwelcome if what is now accepted as an inferior system has just been implemented.

In the late 1970s the software vendors and consultancies dealing in financial systems software often described their product as ’good for five years in present form’, and in addition promised regular updates. In practice, a significant number of organizations bought new software from other vendors well within five years, but hoped that this time they would not be called upon to go through the considerable expense and upheaval of a further implementation in the near future. Almost invariably they were again forced to implement new systems from a different vendor well before the anticipated life of the system was exhausted or struggle on with a system that was no longer competitive. Typically, the reasons given for further changes were as follows.

• The promised benefits from the existing system were never obtained.

• Our business is changing and the existing system cannot meet our future needs.

• It would cost too much to modernize the existing system.

• Better systems have become available recently which will enable us to provide a more competitive service.

Experience shows that most organizations seriously underestimate the cost of implementing new systems by making ’working life’ assumptions that are never normally achieved.

The cost and disruption caused by such change is therefore increasing. The need to change major systems and the fear of failure is the key reason why organizations begin to consider outsourcing functions like finance.

Over the last few years of the 1990s the implementation of Enterprise Resource Planning (ERP) systems has been promoted as a major solution to keeping process costs low and the service at a competitive standard. However, most organizations struggled to find the right quality of staff when they implemented specialist ’best of breed’ financial and manufacturing systems. Why should the situation be improved when organizations implement even more complicated integrated systems?

Unfortunately, the need to change systems now appears to be happening more frequently, with some organizations having switched from one ERP supplier to another within three years of completing the first ERP implementation.

Confidence in this type of solution was still high in early 2000, but in mid to late 2000 negative publicity began to appear at an increasing rate. For example, PA Consulting reported that 92 per cent of organizations in a research exercise they had carried out, admitted that their ERP project (some of which had taken four years to implement) had failed to meet the targets set.

These failures have been explained by assuming that the main problem is due to the fact that project teams were attempting to do something they had never tried before and comparisons are being made, for the same reason, with the high failure rate of Data Warehousing projects. Senior management groups are nonetheless being advised that other new concepts, such as Customer Relationship Management (CRM), are more likely to succeed.

I believe that on a worldwide basis, the majority of large IT projects have always failed to reach their full potential by a significant margin and that this situation is very likely to continue.

Surely, the real problem stems from the fact that the ultimate aim is often difficult to set out. This is mainly due to not knowing what the competitive requirement is likely to be at various stages in the future and the ineptitude and short-term nature of management thinking. However, the ever increasing implementation periods and shortage of suitable skills also plays a major part.

Building a bridge over a major river will seem to most people like a very daunting task but in many ways it is considerably more straightforward than a typical large scale IT project. In bridge building you know where the opposite shore is and you know that you will have to build in a straight line towards it. In IT projects the opposite shoreline is often only a faint image and often keeps moving. Then instead of engineers the skill shortage often means you have to make do with the equivalent of bricklayers. In the circumstances it is not surprising that the IT version of bridge building often produces sections going in the wrong direction.