Suspect Packages

In the 70's and 80's companies used to write bespoke software for all their needs. Everything from payroll to financials to core business systems would be written inhouse in COBOL, RPG, PL/1, Pascal and the like. Then in the 80's and 90's the concept of packaged applications became popular. The rationale was that it was better to purchase and implement off-the-shelf packages rather than develop from scratch. This made perfect sense and much of my early IT work was involved in package implementation. Ideally a package could be implemented in months rather than written in years.

Software selection became vital as the business would often need to assess how flexible that package was and how easily it would fit into the existing processes. Working on the Technical Pre-Sales side it was always important to try to get a product fit of 90% or better. Inevitably though there was never a 100% product fit and in these situations there were two potential solutions:

1) For the business to adjust its way of working (sometimes called Business Process Reengineering)
2) For the package to be changed or modified (i.e. mods)

In the vast majority of cases the latter option was chosen as the business was reluctant to take on change. In one scenario I worked on a customer site where 70% of the programs had been modded making you wonder why they had ever selected the package.

The one exception to this model has always been SAP. They have always insisted that BPR is a fundamental principle of their implementations and as far as I know SAP implementations are never quick. Here at the Department of Hopes and Dreams we're currently 3 years into a SAP implementation and the frustration it is causing the business is unprecedented. Makes me wonder whether the advantages of packaged apps are still there.