Packaged software promises simplicity, but often delivers complexity.
Today, the term packaged software tends to refer to high-end enterprise software suites, such as ERP or CRM, as opposed to shrink-wrapped packages sold through retail outlets. But packaged software rarely comes ready to run. Before you invest in a package, you had better be sure you can live with its business implications, bearing in mind that extensive package customisation often causes failure.
Packaged software - we are not talking about word processing or accounting packages here, but rather about enterprise-level software - typically requires weeks or months of configuration to set it up for the specific needs of each individual business, often at the cost of flexibility and integration between multiple applications.
Do not get me wrong. I strongly endorse the choice of a pre-built ERP package. It is very alluring for any organisation to believe it can buy a piece of software to solve business problems and that the value proposition touted by package vendors - such as best-practice processes, rapid deployment and easy configuration - make it an exceptionally attractive option.
It is in fact true that wherever possible, organisations should invest in packaged software solutions, but with one proviso: your choice of package must meet in excess of 80% of your business requirements, and you must be prepared to live without the balance, choosing rather to modify your business processes in accordance with the constraints of the package, than vice versa.
The fact that most companies botch packaged software implementations has been well documented. The Standish Group's renowned CHAOS Report for 2003 shows that 66% of all IT projects fail, which means that they are more than 20% over budget, 20% or more late, and fail. The fact is that the more specific, individualised, and vertical the requirements are, the more disadvantageous it is to go with a bought product.
Let us look at some of the reasons for these failures:
* Modifications to packaged software turn an erstwhile manageable implementation project into a huge, costly and complex exercise. The Standish Group study shows that the probability of an IT project's success decreases exponentially with the size of the project, and that there has been no single enterprise-level implementation success in the last five years.
* If the changes you are required to make to the package in order to enable it to fit your business requirements are at a level which will require the vendor to modify the source code of the software, you can almost always count on failure.
* When clients make major changes to a vendor product, they effectively move out of the product's mainstream group of users and will no longer benefit from the ongoing research and development that goes into the product, nor will they have access to support.
* Extensive modification means you are cutting yourself off entirely from future versions of the product, as your software will be too different to accommodate simple upgrading.
* Finally, package vendors often do not have all the skills required for software customisation, particularly where imported products are concerned. This means the customisation to your system will either have to be conducted by imported consultants at exorbitant cost, or by inexperienced local consultants.
So, while IT managers may assume that their data architecture can be built entirely from packaged application software, this is clearly not always the case. It is generally more difficult, more time-consuming, and more costly to change 30 to 40% of an existing piece of software than it would be to build it from scratch. Therefore, before any purchase is made, you have to understand the business implications of using bought software: if you cannot get the features you want or that your business requires, you would do better to look at building your own software instead.
Derek Hughes, director at business systems solutions specialist, DVT