For the last fifteen years the build-vs.-buy question appeared to have been solved: packaged software, where available and sufficiently robust for particular applications was the preferred solution; custom-developed software, while it could be aimed very specifically at requirements, had become too expensive to build and too expensive to maintain. This trend became even more pronounced as the U.S. economy heated up earlier this decade now closing intensifying competition for (and thereby cost of) the technical skills required to build, greatly enhance and maintain custom software. Today, with industry-and even company-specific implementation templates and billions of dollars more of investment, packages are even more functional than they were just a few years ago, and usually easier to implement.
However, the build-vs-buy question has again surfaced as highly Iegitimate. In large part this is due to the attention given in the press for years now to very visible (and expensive) package implementation failures, particularly for ERP (Enterprise Resource Planning), SCM (Supply Chain Management) and CRM (Customer Relationship Management) software. This is also due in part to the emerging importance of application software to new industries where very robust package alternatives have not yet developed or matured.
First and foremost when considering whether to employ packages rather than custom developed applications, a clear understanding of an organization’s priorities is necessary, since each option carries both advantages and disadvantages. The best solution is one that carries advantages that are important to the organization and disadvantages that minimally affect it.
Package Software: Pros and Cons
The major ad vantages to software packages can be summarize as follows:
The most reputable vendors have invested enormous effort and expense in incorporating world-class functionality into their products which a company acquires along with the package. Duplicating such expense to develop similar functionality in custom developed code used by one company has become, in many cases, prohibitively expensive. Moreover, if the customer does not customize the package code extensively, then regular version upgrades usually can secure the on-going benefits of continued R&D investment by the vendor, if maintenance fees are kept current. This can prove to be a cost effective way of remaining state-of-the-art in functionality.
Packages tend to be far more configurable and re-configurable than custom developed applications which is to say that they can accommodate change by adjusting table values to a far greater degree than is usual for custom developed applications. Moreover, package environments often come with capabilities that a customer does not implement immediately but are there for future exploitation without the need to build something new, then integrate it with the old, while custom code is usually more tactically designed. And integrated tools usually come with a package environment that allows extraction, analysis and presentation of information without the need to acquire and configure other, third party tools.
These advantages usually translate in a package environment into less need to modify package code than custom code overtime, and less cost and more speed to adding capabilities and using information.
This is important to organizations operating in highly volatile markets, or with many new product or service offerings, or start-up companies, where it may reasonably be expected that business process changes will be relatively frequent and will require changes to how software operates and how information is used.
With products from major vendors if is usual to find a body of experienced professionals on the open market, available as internal hires or as consultants with substantial familiarity with the products.
This is important to organizations with few or no people to dedicate to implementation and on-going maintenance of software products; and, to organizations that are at risk of losing key skills due to the highly competitive market for skills today.
It is usual that a package environment can be implemented in significantly less time than a custom environment, and often at substantially less cost.
The major disadvantages of packages can be summarized as follows:
Even the most robust package environments have constraints: If a company’s business processes or other transactional requirements are trully unique it may be that packages cannot easily accommodate them, requiring process change or package customization. If the current processes truly differentiate a company from its competition, then this could require major customization of the package in order to retain the process advantages.
In such cases the value of using a package would be substantially reduced, and customized software could be the better alternative.
If the “fit” of the package to actual requirements is less than beneficial (70%-80%), then excessive customization of the package may be required to satisfy requirements, or excessive changes in business processes may be required to accommodate the software constraints. Such package customization or process change, almost always extremely complex in execution, is a major cause for large implementation failures.
If the package vendor is small in size, without substantial resources to dedicate to on-going R&D of its product, then this could limit the value to a customer of the package environment over its production lifecycle.
This could be important to companies in highly competitive environments, where constant innovation and continuous improvement are necessary to maintain competitive advantage.
Conversely, very large vendors often offer very complex package environments which, while highly flexible, still require a substantial number of highly specialized professional resources to effect even moderate changes through table adjustments. The high cost of maintaining such resources, or of purchasing consulting services, can be an unanticipated and unpleasant surprise: a high degree of flexibility is often available, but it usually comes at high cost.
This is important to companies which have budgeted a relatively lean maintenance expense over the production lifecycle of a package environment, but who have been sold on the package based on its adaptability, and who have a high perceived need for such flexibility.
This problem often does not bear dramatically on the package vs custom decision, because it can apply equally to custom software; rather, it points to a need for carefully understanding what the true costs are of satisfying requirements, whether they be implementation costs or on-going support costs
A singular disadvantage to packaged software is that a customer incurs some degree of dependency on the vendor’s technology direction.
It is conceivable that the vendor could stop supporting equipment platforms, operating systems, database management systems, communication protocols or programming languages in which the customer has invested substantial resources.
However, the strong industry trend is for major vendors to become increasingly open in such matters, embracing multiple technologies rather than fewer, for their products.