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 ERP to CRM and Procurement, all being peddled by the biggest names in the business, such as Microsoft, Oracle, SAP etc. 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 they can not make a wrong decision. Fast forward several months and you may find a CIO cursing the software company and many people on her 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 vendors 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 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: - One or two high-level decision makers from the affected business units
- 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 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 towards 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 used 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 if, in order of preference: - 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. Gathering Requirements
Once the selection committee is assembled, they 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. For example, a good requirement would be Ability to handle our current Series 1000 product and its associated 78 configurations. Configurations should be easy to build by the sales people, and should explode to a line-item pack list for the warehouse. This is in contrast to a bullet list that contains things like Easy variant modeling, ATP, RFID, etc. While a package may have the features you want, if it can not accommodate key process requirements or product/customer service models, it is not appropriate for your business. Also document any legacy systems that must be interfaced with the package software. Your legacy systems experts can help determine which data structures will need to be changed on the legacy or package side of the house, and the complexity of the required interfaces. Legacy system experts can also contribute lists of key systems that will need to be converted to the new package, and help estimate the timeframe required to convert and validate the data. Rank each requirement by order of priority, and resist the temptation to spend 80% of your time focusing on the 3% 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
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 example materials and customers 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 field names, 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 reason. 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 in the system being considered come 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. 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 appropriate questions are asked. Beginning an implementation with eyes wide open is far less risky, and more likely to prevent premature grey hair than becoming mired in a failing implementation, asking what if we had chosen package X? |
