INTRODUCTION

Software packages, which have been around for 40 years, have posed a dilemma in IT and the business. Should you develop software that fits your needs better and more of your requirements? Or should you buy a software package that does not do everything but gives you some capabilities with less cost and, more importantly, less risk?

Most software packages are 10 15 years old. They have been modified and upgraded through new releases a number of times. The number of major software firms has declined through mergers and acquisitions. Yet you would not think of building large complex software systems on your own. Nor would you want to construct software when there are established, less expensive alternatives. So packages will always be part of the main software of an organization. Note, however, that some firms still see software as a competitive advantage. Wal-Mart develops and maintains their own systems. However, few can match their resources.

Given that you are going to buy or already have software packages, what are some guidelines that can be gleaned from past experience? Here is a basic one:

It is not what you get with the software that counts; it is what you did not get that matters.

What does this mean? No software package can meet all of your needs. Therefore, you have to compromise. Either you have to warp your processes to fit the software package or you have to invent new shadow systems or continue to use the existing software that...