14 Feb Five steps to buying the right package software
Package software is often one of the largest technology expenditures of a business. The promise of package software is compelling: replace unwieldy custom applications developed in-house with a standardized, integrated system, built on processes based on the latest industry best practices.
All this is combined with promises of a fast implementation and relatively painless upgrades when the next version of the package is released. The popularity of package software has seen the development and delivery of packages to cover all aspects of a business: from enterprise resource planning to customer relationship management and procurement, all being peddled by the biggest names in the business, such as Microsoft, Oracle, SAP, etcetera.
The selection process for buying a package, while tedious, often leaves the selection group with a positive impression. Vendors promise that the software will work perfectly “out of the box,” and that any customizations can be easily and cheaply accommodated. At the end of the process, the selection committee often feels like it cannot make a wrong decision.
Fast forward several months and you may find a CIO cursing the software company and many people on the IT staff wondering how they ended up with such an inflexible piece of junk. The answer often lies in the requirements and selection process, itself. The following five tips provide a guideline for not only selecting a package, but knowing what to expect when buying package software.
Implement processes, not software
The biggest mistake most companies make when purchasing package software is seeing the decision as a software purchase. Vendors tout the availability of “best practices” built into the software, but what they are really selling is a particular process for completing a business transaction. Each vendor handles a process, such as issuing a purchase order, or creating a marketing campaign in a particular manner. If one of your key concerns is building a new customer invoicing process, pay particular attention to how the process works in each vendor’s software.
Despite what the salesperson will tell you, hammering a legacy business process into a package that uses a completely different set of rules rarely works. Always assume that you will be implementing the processes your package is delivered with, and ensure that those processes will work for your business.
Building the ultimate selection committee
As the above point concludes, you are buying processes rather than just a software toolkit. Keep this in mind as your build the selection committee that will ultimately decide which package to purchase. A selection committee should have:
• High-level decision makers from the affected business units that have an actual vote in the selection of the package. This group should be well-known in advance of the actual vote on which package to select.
• Business process experts from all affected areas.
• Financial analysts who can determine the ROI of each package with the help of the aforementioned experts.
• In a particularly complex implementation, “hired gun” experts in each package who can get a rough handle on the cost of implementation. Do not leave this job to the package salesperson!
• Legacy systems experts who have a good grasp of current data structures, and a good grasp of data that must be converted to the new system.
• Select technical staff who will be participating in the implementation.
A typical selection committee is heavy at the bottom of the list and light toward the top, bringing in loads of developers and systems people who see the package as a new software-development environment. These people tend to be sold on the features and “coolness factor” of a particular package, and since they rarely understand the complexities of a particular business process, or what benefits and drawbacks a packaged process will offer, they prefer a technical “fit” that may not be a business fit.
They also are accustomed to a world where a requirement comes in, and software tools are used to build a solution from the ground up. As the following points demonstrate, this is exactly how not to successfully implement a package.
The ultimate selection committee will assess each business process that will be changed, and determine, in order of preference, whether:
• The package process can serve as a “drop in” replacement for the legacy process.
• The legacy process should be modified to accommodate the package, or in the absolute worst case scenario, the packaged process should be modified to fit the legacy process.
Experts in the particular package being considered can shed some light on the difficulty and cost of each option, and the selection committee should bear in mind that it is always cheaper and easier in the long run to use a “drop in” process or modify the legacy process to accommodate the system rather than the reverse.
Once the selection committee is assembled, it should conduct a preliminary requirements gathering session to identify “must have” processes and features that will be referenced during vendor presentations. The output of the requirements gathering should be a punch list of process requirements, not technical features. This is in contrast to a bullet list riddled with buzzwords. While a package may have the features you want, if it cannot accommodate key process requirements or product/customer service models, it is not appropriate for your business.
Rank each requirement by order of priority, and resist the temptation to spend 80 percent of your time focusing on the three percent of your business that is overly complex or exception-based. A package generates cost savings by standardizing and eliminating exception processes and “unique” business processes; do not bake these in before you have even signed the check for the software.
Sales demos are the fun part of the package sales process. This is where slick PowerPoint presentations are finally replaced with a demonstration system, hopefully configured to show how some of your business processes might look in a live system. Again, during demo time, ensure the vendor displays business processes that are relevant to your company and industry, and show how the software might meet some of your requirements.
It may be unrealistic to expect a fully functioning demonstration that includes all of your products and every imaginable scenario, but it is reasonable to expect scenarios that use a couple of examples you provide, or at least data and processes relevant to your industry. Keep your list of key processes in eyesight at all times, and ask how the system will accommodate them, rather than being distracted by things like screen layouts and flashy features.
Be realistic on implementation timeframes
Vendors often tout the speed with which their particular package can be implemented, and for valid reasons. Time is money in most businesses, and the more quickly a package can go from installation to roll-out, the less costly the implementation. Many companies have relied on vendor estimates, only to be stuck with mounting costs and ever more distant go-live dates, wondering what went wrong.
Vendors are only partly to blame, since their time estimates assume few to no customizations to the package. Implementing the vendor-delivered “best practices” can often be accomplished in a rapid manner, but many businesses underestimate the time required for any needed customizations, or changes to the process side of the business that will be required for the implementation to be successful. Required interfaces to legacy systems also can rapidly become a “black hole” and consume vast amounts of time and money.
Determining an accurate implementation timeframe is where your punch list of key processes and “hired gun” experts comes into play. While it would be impossible at this stage to deliver a perfectly accurate time estimate, knowing that one package may require around six months more time to implement can be a key factor in deciding on one package versus another.
Customizations kill implementations
Perhaps the biggest factor in extended timelines, blown budgets, and missed expectations when implementing package software is tied to the amount of customizations. Packages are integrated systems, and often a seemingly minor change in one area has a trickle down effect on many other parts of the system. Customizations increase development time, require additional testing time, and increase support costs in the long run. One of the great promises of package software is the ease of upgrades; however, this promise rests on the assumption that the package has not been extensively customized by the customer.
The punch list of key processes will help determine where customization is required, and allow for thoughtful discussion with the vendor before checks have been signed. For example, if invoicing is a key process that can be met by a particular package by changing the legacy process, heartache and “pocket ache” will be saved in the long run by changing the business rather than the software. Business process experts on the selection committee can help assess the difficulties of changing the process, and identify any hidden costs in that area as well.
No more “what if” questions
While some of the luster around package software has faded since true end-to-end solutions began appearing in the early 1990s, it is still an excellent solution to many business problems: replacing aging legacy applications, integrating business processes, and lowering maintenance costs, among others.
Selecting software with these five criteria in mind can make the implementation less costly in the long run, and ensure that appropriate questions are asked. Beginning an implementation with eyes wide open is far less risky, and more likely to prevent premature gray hair than becoming mired in a failing implementation, asking “what if we had picked that other package?”
• Software tax dispute could go the Supreme Court
• More enterprise software predictions for 2007
• Wisconsin firms won’t rush to adopt Microsoft Vista
• Users help software company morph in new directions
• CIO Leadership Series: Mike Jackson, Rockwell Automation
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.
WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.