Apply: Systems Development Life Cycle Presentation

Choosing Off-the-Shelf Software

Once you have decided to purchase off-the-shelf software rather than write some or all of the software for your new system, how do you decide what to buy? There are several criteria to consider, and special criteria may arise with each potential software purchase. For each criterion, an explicit comparison should be made between the software package and the process of developing the same application in- house. The most common criteria include the following:

• Cost

• Functionality

• Vendor support

• Viability of vendor

• Flexibility

• Documentation

• Response time

• Ease of installation

These criteria are presented in no particular order. The relative importance of the criteria will vary from project to project and from organization to organization. If you had to choose two criteria that would always be among the most important, those two would probably be vendor viability and vendor support. You do not want to get involved with a vendor that might not be in business tomorrow. Similarly, you do not want to license software from a vendor with a reputation for poor support. How you rank the importance of the remaining criteria will very much depend on the specific situation in which you find yourself.

Cost involves comparing the cost of developing the same system in-house with the cost of purchasing or licensing the software package. You should include a comparison of the cost of purchasing vendor upgrades or annual license fees with the costs you would incur to maintain your own software. Costs for purchasing and developing in-house can be compared based on economic feasibility measures (e.g., a present value can be calculated for the cash flow associated with each alternative).

Functionality refers to the tasks the software can perform and the mandatory, essential, and desired system features. Can the software package perform all or just some of the tasks your users need? If only some, can it perform the necessary core tasks? Note that meeting user requirements occurs at the end of the analysis phase because you cannot evaluate packaged software until user requirements have been gathered and structured. Purchasing application software is not a substitute for conducting the systems analysis phase; rather, purchasing software is part of one design strategy for acquiring the system identified during analysis.

As we said earlier, vendor support refers to whether vendor can provide support, and how much it can provide. Support occurs in the form of assistance with installing the software, training user and systems staff on the software, and providing help as problems arise after installation. Recently, many software companies have significantly reduced the amount of free support they will provide customers, so the cost to use telephone, on-site, fax, or computer bulletin-board support facilities should be considered. Related to support is the vendor’s viability. You do not want to get stuck with software developed by a vendor that might go out of business soon. This latter point should not be minimized. The software industry is quite dynamic, and innovative application software is created by entrepreneurs working from home offices—the classic cottage industry. Such organizations, even with outstanding software, often do not have the resources or business management ability to stay in business very long. Further, competitive moves by major software firms can render the products of smaller firms outdated or incompatible with operating systems. One software firm we talked to while developing this book was struggling to survive, just trying to make its software work on any supposedly Windows PC (given the infinite combination of video boards, monitors, BIOS chips, and other components). Keeping up with hardware and system software changes may be more than a small firm can handle, and good off-the- shelf application software can be lost.

Flexibility refers to how easy it is for you, or the vendor, to customize the software. If the software is not very flexible, your users may have to adapt the way they work to fit the software. Are they likely to adapt in this manner? Purchased software can be modified in several ways. Sometimes the vendor will be willing to make custom changes for you, if you are willing to pay for the redesign and programming. Some vendors design the software for customization. For example, the software may include several different ways of processing data and, at installation time, the customer chooses which to initiate. Also, displays and reports may be easily redesigned if these modules are written in a fourth-generation language. Reports, forms, and displays may be easily customized using a process whereby your company name and chosen titles for reports, displays, forms, column headings, and so forth are selected from a table of parameters you provide. You may want to employ some of these same customization techniques for systems developed in-house so that the software can be easily adapted for different business units, product lines, or departments.

Documentation includes the user’s manual as well as technical documentation. How understandable and up-to-date is the documentation? What is the cost for multiple copies, if required? Response time refers to how long it takes the software package to respond to the user’s requests in an interactive

session. Another measure of time would be how long it takes the software to complete running a job. Finally, ease of installation is a measure of the difficulty of loading the software and making it operational.

Of course, the criteria for software acquisition will vary with the type of system you are acquiring. For example, if you are thinking about licensing an ERP system, you will certainly take all of the prior criteria into account, but you will also want to investigate criteria that are specific to ERP systems. Verville, Bernadas, and Halingten (2005) studied organizations that had acquired ERP systems to discover what the critical factors were for success. They found 10 success factors, with 5 related to the acquisition process and 5 related to the people in the process. They found the acquisition process had to be highly planned and structured, and it had to be rigorous. For the process to be successful, nothing could be overlooked during planning. It was important that two of the five success factors related to the process were completed before ERP vendors were contacted. These two factors were determining all of the system requirements and establishing the selection and evaluation criteria. They helped the organizations compose clear descriptions of their needs and evaluate bids from vendors. The fifth process-related criterion was obtaining accurate information. Information sources needed to be verified and cross-validated.

The other five success factors dealt with the people involved in the acquisition process. The first factor was clear and unambiguous authority. The person in charge of the process needed to be objective and a strong leader. Second, the composition of the acquisition team was important. The team needed to be diverse, with each member having a particular skill set that was complementary to those of the other team members. Third, it was considered important to approach the relationship with the vendor as a partnership, as opposed to an adversarial or neutral relationship. Given the complexity and cost of ERP systems, members of the acquiring organization would be working with the vendors for several years, so a comfortable working relationship was essential. Fourth, future users of the ERP system were active participants in the acquisition process. Lastly, the fifth success factor related to people in the process was user buy-in. In the companies studied, user buy-in often translated into user acceptance of the system and even enthusiasm and excitement about it.