PACKAGE VS CUSTOM: THE DECISION POINTS

Transcription

1 P.O. Box 336 Ramsey, NJ P F PACKAGE VS CUSTOM: THE DECISION POINTS A White Paper by Richard Luettgen This paper was developed to provide general background to assist clients in decisions related to employing packaged application software or customdeveloped software for their transaction processing needs. Please note that this paper presents professional opinions intended to apply generally and that clients must take appropriate care to evaluate them in light of their specific needs. makes no representations, warrantees or guarantees of any sort as to the applicability of the opinions presented in this paper to the specific needs of any client. The paper is organized as follows: 1. Overview 2. Package Software: Pros and Cons 3. Custom Software: Pros and Cons 4. The Fear of Failure 5. Conclusions. 1 of 6 Copyright, L.L.C.

2 1. Overview F or the last ten years of the Twentieth Century 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, intensifying competition for (and thereby cost of) the technical skills required to build, greatly enhance and maintain custom software. 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 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. This paper seeks to re-examine the factors affecting build-vs-buy decisions, and provide some guides for sorting through this complex issue. 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. 2. Package Software: Pros and Cons The major advantages to software packages can be summarized 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 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. 2 of 6 Copyright, L.L.C.

3 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 process changes will be relatively frequent and will require changes to how software operates and how information is used. With products from major vendors, it 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 truly 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 ongoing 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. 3 of 6 Copyright, L.L.C.

4 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. 3. Custom Software - Pros and Cons Custom software, on the other hand, possesses advantages that can also be disadvantages: Custom software can be precisely designed to the needs of the moment. However, the burden of anticipating the needs of the next year and beyond falls directly on (usually) a small team of internal designers and architects. With packages, a large team of vendor personnel creates and maintains a product that must stand the test of time and must be attractive to many companies, in order to be financially viable. The vendor also is usually armed with better information about world-class process requirements, and is highly incented to develop change-friendly products. 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. Custom environments can be less costly to implement than package environments, because 1) no license or maintenance fees are incurred; and 2) because custom design tends to be very tactical: it rarely includes extras; and, 3) because extended and expensive package selection activities are avoided. 4 of 6 Copyright, L.L.C.

5 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 with 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. 4. The Fear of Failure This fear needs to be put in perspective. Why do complex package implementations fail? We contend that the major causes of such implementation failures are: Incomplete or poor planning of the implementation; Poor change management, that is, poor anticipation of the barriers to introducing change to an organization, and poor attention to developing programs to effectively manage that change; Poor expectation management, which is an excessive set of expectations of what the package will do, by what period of time and at what cost this cause includes poor selection of the package in the first place; Altered internal or external conditions, which are conditions that develop that place in question the premises that justified the selection of the package, e.g., acquisitions or divestitures, new methods of doing business, major internal management/organizational upheaval. Problems with consultants, which can also have a role in all the other causes. The commonly understood, superficial reasons for such failures, such as package complexity, excessive need to customize or reengineer 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 should have similar confidence that it can handle complex package selection and implementation activities. It should also be noted that large, complex custom development projects have been failing for far longer and, we believe, 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. 5 of 6 Copyright, L.L.C.

6 5. Conclusions 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-vsbuy 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, we believe that custom software, particularly that which automates critical processes, is best suited to more stable environments consisting of unique and highvalue 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. 6 of 6 Copyright, L.L.C.