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, cautions Derek Hughes, MD of business systems solutions specialist DVT Gauteng, you had better be sure you can live with its business implications, bearing in mind that extensive package customisation often causes package 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.
Don`t 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. This is because extensive modification negates the value proposition of a package, conversely introducing the downside of custom development.
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 they are more than 20% over budget, 20% or more late, and fail to meet 20% or more of the business requirements for the system. The average cost overrun is 43%. The fact is that the more specific, individualised and vertical the requirements are, the more disadvantageous it is to go with a bought product.
Anyone who has watched the IT market over a period of time will attest to the vast number of failed implementations they have witnessed. Projects that were to take 15 months run to three, five or seven years, and into millions of rand.
Let`s 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. Changes that are more than minor configuration adjustments negate the very benefits that come along with buying a package by effectively introducing all the elements of a custom-developed project into software in which years of research, development and testing have been invested.
* When clients make major changes to a vendor product, they effectively move out of the product`s mainstream group of users. The vendor, after all, caters for the common denominators among its clients, so a user who makes major modifications to the software will no longer benefit from the ongoing research and development that goes into the product, nor will they have access to support. Think about it: you choose a package because of all the shared benefits it offers, and then promptly marginalise yourself from them. These include access to best practice, standardised, domain-specific business processes.
* 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 can`t get the features you want or that your business requires, you would do better to look at building your own software instead.
Share
Editorial contacts