Ting Hsuan Lin | September 29, 2016
This article provides general background to assist readers in decisions related to employing packaged application software or custom-developed software for their transaction processing needs.
Please note that no representations, warranties or guarantees of any sort are made as to the applicability of the advice presented in this article to the specific needs of anyone, and that readers must take appropriate care to evaluate them in light of their specific needs.
* ** * *
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 legitimate. 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 advantages to software packages can be summarized as follows:
These advantages usually translate in a package environment into less need to modify package code than custom code over time, 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.
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.
The major disadvantages of packages can be summarized as follows:
This could be important to companies in highly competitive environments, where constant innovation and continuous improvement are necessary to maintain competitive advantage.
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.
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.
Custom Software – Pros and Cons
Custom software, on the other hand, possesses advantages that also can be disadvantages:
Consequently, custom environments tend to be less stable than package environments once in production; and, enhancement backlogs tend to be more quickly and cost effectively reduced in package environments.
However, the lack of the extras can increase the total cost of operating the software over its production lifecycle, as can a tactical (as opposed to strategically flexible) architecture and design.
The extras may be needed soon, and will need to be built as well, and then integrated into the old, all at additional cost. Less dramatic but important changes also may be required that were not foreseen, that could require code modification and perhaps major design re-thinking.
It should be noted that it is generally accepted that approximately 90% of an application’s total cost of implementation and operation for as long as it is used lies in on-going support. Anything that minimizes this cost component will have a large affect on overall cost of use.
This fear needs to be put in perspective. Why do complex package implementations fail? The major causes of such implementation failures are:
The commonly understood, superficial reasons for such failures, such as package complexity, excessive need to customize or re-engineer business processes, are merely symptoms of the problems listed above.
The best response to such concerns is to point out that precisely the same problems can derail a large, complex custom development project. If a company’s management is sufficiently confident that it has the skills or can reliably acquire them to meet requirements while developing custom software, then it is not unreasonable that it also have similar confidence in handling complex package selection and implementation activities.
It also should be noted that large, complex custom development projects have been failing for far longer and, certainly, in similar numbers, as package implementations. One hears about the package failures because the client company has an incentive to publicize the failure when a package vendor can be sued.
The primary consideration in build-vs.-buy decisions, really at the premise level, is the availability of packaged software that does what needs to be done. There is no build-vs.-buy decision if packages are not available; and, sometimes the decision is moot if the packages that are available do not have significant followings or are offered by vendors that are not well capitalized and may be out of business before their next version release.
Next, we believe that the perception that package implementations are more likely to fail than custom implementations is not reflective of reality. Consequently, we believe that the build-vs.-buy decision should center on matters of fit, the strategic viability of candidate vendors, and rigorous cost/benefit analysis that focuses on total cost of ownership and use.
Finally, custom software, particularly that which automates critical processes, is best suited to more stable environments consisting of unique and high-value business processes. Where highly robust packaged software is available from proven vendors with a track record of high R&D investment, this may be the more strategically advantageous solution to automating less unique processes.