Nobody in his or her right mind would build a general ledger or payroll-processing application today. What possible strategic advantage can an organization achieve by building such an application? Instead, organizations everywhere are purchasing off-the-shelf applications that deliver various pieces of core business functionality or functionality tailored to a specific industry. They will buy inventory or purchasing systems, or complete banking, hospital, or manufacturing systems.
In buying these systems, organizations save the time, effort, and cost of building the applications themselves. In the build-versus-buy debate, purchased applications are typically better designed than the monolithic systems organizations often wrote and modified during the past 15 years. Increasingly, programmers are writing applications that take advantage of the latest technology: components, the Internet/Web, emerging standards, multiple platforms. It would take a lot of effort from a sophisticated, highly skilled in-house development group to come up with a solution that rivaled a good off-the-shelf product. Because of the leverage offered by many of these packages, many organizations are better off leveraging a packaged solution.
In addition, one of the key reasons why organizations select packages is because they ensure that best practices for a particular discipline will be implemented at the same time as the software. Packaged applications ı at least the good ones ı capture the best practices and current state-of-the-art processes of the particular vertical industry or business function. A business that implements a leading purchasing package or customer-service management package is also adopting the best industry practices and processes in the given area. There are downsides to this approach, however. In many instances, individuals within an organization will be uncomfortable allowing the software to dictate how business is conducted. IT organizations are often not prepared for the internal turmoil that a packaged application can cause.
Once an organization goes through the pain of implementing a package, it must deal with a host of other concerns: How do I implement the same package that all of my competitors have and maintain differentiation? How does my company implement changes in a package that was designed with a well-established set of business rules and business processes?
Invariably, organizations begin to implement changes to these complex packages to match their changing competitive environments. Implementing packaged applications follows the old 80/20 rule. A packaged application will give you about 80 percent of the functionality you want. This is the core business functionality required to make the business work, but it has never provided any significant advantage or differentiation. The unique value the organization brings is captured in the remaining 20 percent through customization and extension. While it is safe to say that many aspects of a packaged application will meet most of your organizationıs needs, it is equally safe to assume that no packaged application will meet all your needs, especially if you are in a dynamically changing market. Inevitably, you will be doing important things differently. These are the things you customize.
For example, a liquor importer had a unique way of receiving shipments in bulk and breaking it down into deliverable quantities. This approach couldnıt be handled out-of-the-box by the distribution system. The unique process, however, gave the importer advantage in terms of flexibility that its customers liked, so it wasnıt about to change the process. Instead, it customized the system.
But there are risks and costs involved in customization, particularly over the long term. After the initial customization is completed, for instance, your business will continue to change and evolve, at times very rapidly. You will need to customize, extend, and enhance the application as the business changes, just as you would a custom application. In addition, the vendor will be enhancing the core application, which may complicate your own efforts.
Customization of packaged applications is not trivial. The first mistake managers typically make is to underestimate the size of the customization task. In one case we studied, the managers identified 1,400 modifications to the packaged application they had selected. They submitted the list of modifications to the system integrator, who returned with an estimate for the customization that exceeded $1 million. The stunned managers reviewed the desired modifications and decided that, in many cases, they could live with the functionality as it came out of the box. The dramatically reduced list of critical modifications turned out to be quite reasonable.
There are three major steps to the process of customizing or extending packaged applications:
Identifying the truly worthwhile customizations is a critical step in controlling the cost. Your natural tendency is to want to tweak every function to reflect how you had done them before. But one of the benefits of adopting a piece of packaged software is to get the best practices already embedded in the system. The organization must accept the fact that implementing packaged software means some things, maybe many things, will change. Prepare your people to cope with the change ı new ways of doing things, new screens, and new names for old tasks and functions.
To separate the worthwhile changes from those that are merely convenient or comforting, you will have to sort out the weıve-always-done-it-this-way protests from the our-critical-process-requires-we-do-it-this-way protests. Help the former protesters learn to cope with the changes. With the latter protesters, you need to examine the claims to determine if those critical processes truly differentiate the organization from its competitors or create a strategic advantage. Just because you perform an important task in a unique way doesnıt mean you gain anything by it.
The actual task of writing the code is typically left to system integrators who are familiar with the APIs, data structures, and logic of the packaged application. This task is best handled as a joint effort with your own people working side by side with the integrator. In this way, your people will acquire the skills to maintain the application down the road. Insist that every change be exhaustively documented.
To avoid maintenance horror stories, we strongly recommend that you store all changes in a separate library or directory. By isolating your changes this way, you will have an easier time when the vendor upgrades the application or releases a fix. Otherwise, your programmers will be hunting down changes all over the place.
Finally, plan ahead for how you are going to manage the maintenance of the application over the long run. By enabling your people to become familiar with the application during the initial customization, documenting the changes, and storing the changes in a separate library, you will be in a good position to maintain the application. The key is not to let your guard down. Be as insistent as you were initially on skills transfer, documentation, and isolation when doing subsequent modifications.
No package, however comprehensive, handles everything your organization does. As a result, you will need to integrate the off-the-shelf application, customizations and all, with your other applications, both packaged and custom built. Organizations need to integrate varied applications as they support cross-functional business processes. A customer-management application, for example, will have to interoperate with packaged applications and a financial package to support a seamless customer service process.
The integration of multiple packages and custom applications raises the level of complexity significantly (see David Linthicumıs column "Crossing the Stream," DBMS, February 1998). You will need to enforce an effective change process to ensure that changes are made across all affected pieces of software. The maintenance of all these applications along with their customizations and integration can become a full-time job for a skilled team, particularly if the organization or its industry is undergoing substantial change. Fortunately, there is a growing variety of middleware and specialized application integration software to help with this kind of integration and maintenance.
Buying packaged applications does not eliminate the need for custom programming. When customizing packaged applications, however, managers must always weigh the strategic value of the customization against both the initial and ongoing costs