Information Technologies in Organizations powered by ERPsim

Information Technologies in Organizations powered by ERPsim PART 7: IT Projects Chapter 17: Introduction to the software selection process Stefan Tams Chapter 17 Introduction to the software selection process Laura and Pierre, two accountants at Greatcorp Inc., have just been assigned the task of selecting a new accounting software solution that can increase the efficiency of their departmental operations. The two accountants have a positive attitude toward information technology and believe it can be useful for their department. Unfortunately, they face great trouble in adequately performing the selection process. They wonder: it is such a complex task, where do we begin? What are functional requirements, what are non‐functional ones, how are they related, and why do we need them anyway? How do we find a good solution, and how can we close the deal? This vignette illustrates some of the challenges inherent in the software selection process; the questions Laura and Pierre encounter are not unexpected, they arise in most software selection projects (Howcroft and Light 2010; Tams 2008). Do these challenges imply that the software selection process is unmanageable? Not necessarily, there is good news: the software selection process can be considered a business process and, as such, it can be structured so that it is more easily manageable. Please recall that we have introduced the term business process in prior chapters, and we have defined a business process as a collection of structured activities or tasks required to achieve a particular business goal (for example, produce a product, serve a customer, and create a purchase order). One such particular business goal is to improve process efficiency and/or effectiveness through the use of new software, implying that most concepts we already discussed concerning business processes also apply to the software selection process. But there is more: in this chapter, we discuss further concepts that provide for an even better understanding of how to manage software selection projects effectively. We begin our expedition into the software selection process by dividing the entire process into a number of smaller and more easily manageable phases and by discussing the distinct goals and characteristics of these phases. Afterward, we introduce the notion of functional and non‐functional requirements, followed by a discussion of added considerations for enterprise resource planning systems, which are particularly complex. Next, we discuss the costs and benefits of open source solutions. Then, we introduce three contemporary issues in software selection. We conclude our expedition into the software selection process with some final thoughts. © 2012, Robert & al 17 2 17.1 Dividing the Entire Process into Manageable Phases As mentioned earlier, the software selection process is complex and, hence, full of challenges. To make the process more manageable, we can divide it into five phases (see Figure 17.1) (Howcroft and Light 2010; Rasmussen et al. 2002; Tams 2008): Planning and Budget Creation, Requirements Analysis, Vendor Search and Evaluation, Presentations to Management, and Deal Closure. Deal Closure Planning and Budget Creation Requirements Analysis Vendor Search and Evaluation Presentations to Management Figure 17‐1 The Five Phases of the Software Selection Process Planning and Budget Creation. The first phase of the selection process is concerned with the creation of a project plan and budget (Howcroft and Light 2010; Rasmussen et al. 2002). To make sure that an optimal software solution will have been found at the end of the process, a good project team has to be established. More specifically, a strong project manager and representatives from all functional areas of the business are needed since software selection projects often cut across functional boundaries, such as marketing or accounting. Once the project team is established, the project manager estimates a timeline for the selection process. A timeline is important to keep the project team and the selection process on track at all times; it allows for continuous evaluations of the progress of the selection project. Perhaps even more important than the timeline is the budget; the budget requires a careful estimation of the total costs for the software license, the software implementation, and the software maintenance. License costs are often given per user or station, implementation costs are the costs for implementing the software (that is, the costs associated with launching the software in its live environment), and the maintenance costs are those for updates and support, they typically account for around twenty per cent of the software list price per year. © 2012, Robert & al 17 3 Requirements Analysis. In the second phase of the selection process we establish the purpose for the software and detail the functional and non‐functional requirements as well as the technology requirements for the software (Gebauer et al. 2008; Howcroft and Light 2010; Rasmussen et al. 2002). The resulting requirements document needs to be focused on a few key criteria – otherwise, we may lose the forest for the trees, with detrimental impacts on the project timeline and the quality of our final investment decision. A detailed list of both functional and non‐functional requirements is particularly important. Functional requirements are necessary software features that relate to the different functions a system can perform for the user (Gebauer et al. 2008). By contrast, non‐functional attributes relate to the acquisition and operation of the system, not to what the system is supposed to do. Since the detailed specification of both functional and non‐functional requirements is particularly important for a selection project to be successful, we devote an entire subsection to them (please see section 17.2). The technology requirements are based on the currently available technology infrastructure (that is, currently available hardware and software) and future acquisition of both hardware and software. The specification of the requirements includes, for example, the preferred operating system (e.g., Microsoft Windows vs. Linux), the preferred database (e.g., Oracle vs. Microsoft SQL Server or IBM DB2), and hardware specifications (e.g., requirements for random access memory). Technology requirements are often, but not always, established as part of the functional requirements. Vendor Search and Evaluation. The third phase of the selection process is concerned with identifying the vendors whose solutions best meet the previously established requirements. In this phase, one first generates a long list of candidate vendors. Next, this list is narrowed down to a shortlist of three to five vendors on the basis of documented vendor information (e.g., vendor Web sites, price lists), phone calls, and vendor visits. The shortlisted vendors are then invited to demonstrate the value of their solutions including relevant software features, vendor support, and potential price discounts. It is often useful to establish a detailed protocol for these vendor demonstrations to ease the comparison effort. Another important aspect in this phase is testing; the shortlisted software products can be installed in a testing environment so that future users can get a feel for them. Getting a feel for the candidate solutions is important for the users because contemporary software tends to be highly interactive and, therefore, has to be explored in depth before informed evaluations can be made (Burston 2003). Presentations to Management. In the fourth phase of the selection process we present the shortlisted solutions to the final decision makers. This presentation includes documented information as well as the software and vendor‐related information that has been learned from the vendor presentations and testing efforts (Howcroft and Light 2010). Deal Closure. In the final phase of the selection process management is concerned with making a choice among the presented solutions. This decision can be based directly on the presentations. Alternatively, the choice decision can be based on follow‐up vendor demonstrations or visits of vendors’ headquarters. Decision aids include, for example, paired comparison analyses, which directly contrast each candidate software solution with each other solution, or the traditional cost/benefit analyses (Rasmussen et al. 2002). © 2012, Robert & al 17 4 To conclude our discussion of the proposed division of the entire selection process into five smaller phases, let us admit that this division is somewhat artificial since – at the end of the day – we need to consider the process holistically to arrive at a good selection decision. Nevertheless, this division makes sense since selection projects tend to be complex and, thus, full of challenges and managerial difficulties (Rasmussen et al. 2002). Consequently, an organized approach based on simple and distinct phases can be helpful in deciding on a good software solution. Please also note that we could meaningfully include agile components in this approach, that is, we could iterate among the phases (for example, we could repeat Phase two after experiencing testing problems). 17.2 Functional and Non‐Functional Requirements As previously mentioned, the establishment of detailed functional and non‐ functional requirements (or attributes) is a critical aspect of the second phase in the software selection process (Howcroft and Light 2010; Rasmussen et al. 2002; Tams 2008). Functional requirements are necessary software features that relate to the different functions a system can perform for the user, whereas non‐ functional attributes relate to the acquisition and operation of the system, not to what the system is supposed to do (Gebauer et al. 2008). As such, functional requirements include software functionality, security, performance, and compatibility. The former implies that the software solution has the required functions to do for the user what the user needs to have done. Software security means that the functions and data can be accessed only by authorized individuals. This criterion is functional since security is these days key; imagine if an online vendor would not have appropriate security measures, what we trust them with our credit card information? Thus, the very purpose of a software solution can be compromised in the case of insufficient security features. Similarly, software performance, such as response time, is often tied directly to the purpose of the software system. Imagine an online vendor whose Web site needs to “think” for thirty seconds each time we click a button. How many of us would buy from this vendor? Finally, system compatibility implies that © 2012, Robert & al Figure 17‐2 Non‐functional and functional requirements 17 5 the software solution can work together effectively with our current and future hardware and software components (for example, Microsoft Excel, a spreadsheet solution, is compatible with Microsoft Windows, an operating system). Non‐functional requirements include software maturity, vendor financial stability, user training support, general vendor support, and software price. These requirements are not tied directly to the purpose of the software, but they are necessary for us to put a software solution to an effective use. Software maturity implies that a software solution has been around for a while so that initial programming‐ related problems (also called bugs) have been resolved. A good proxy for software maturity is the version number; a high version number generally points to a mature product with few remaining problems. Vendor financial stability is important to ensure continuous support from the vendor; a vendor that is financial unstable may go out of business relatively soon and, thus, may become unable to continue the delivery of updates and other forms of support. It is also important that the vendor can offer support in terms of user training. Training users in terms of how to use a software solution is important to ensure that they have the confidence and intention to use the software and that they are able to use it effectively. Another relevant criterion is general vendor support. Vendors must be able to assist with a variety of aspects surrounding the implementation, continuous operation, and maintenance of the solution in question. Finally and perhaps most importantly, the price must be right. It is important that the software solution in question does not exceed the available budget. Figure 7.2 shows the functional and non‐functional requirements in context; the non‐functional requirements surround the functional ones, that is, they are at the periphery. This is not to say that non‐functional requirements are not important; they are, but they are not directly tied to the purpose of the software. The figure further demonstrates that functional and non‐functional requirements are complementary; meeting functional requirements is of limited value if the non‐functional requirements are not met. For example, even a software solution that can perfectly do for an organization what the organization needs to have done is of limited value to the organization if it exceeds the budget (that is, the organization cannot afford to purchase the focal software solution) or if it suffers from substantial problems related to software immaturity. 17.3 Added Considerations For Enterprise Resource Planning Systems In the case of the selection of a new Enterprise Resource Planning (ERP) system such as SAP R/3, an additional criterion needs to be considered due to the extreme complexity inherent in such software systems. More specifically, because these software solutions have major impacts on many aspects of an enterprise one needs to decide on whether a complete suite or a best‐of‐breed solution is best. The former refers to an ERP solution that covers the breadth and depth of the entire, or complete, enterprise. In other words, the entire value chain of an organization's transactions is covered when employing a complete suite of a vendor’s applications. This approach implies an © 2012, Robert & al 17 6 integration of financial, accounting‐related, distribution‐related, marketing‐related, human resource‐related, manufacturing‐related, and other aspects of organizational life. By contrast, a best‐of‐breed solution is not an integrated, complete software solution but rather emphasizes certain aspects that are of particular importance to the enterprise (see Figure 7.3). For example, a company could invest only in the accounting and manufacturing components of an enterprise system if it outsourced the other aspects of organizational life. Further, it could purchase these Piecemeal approach Emphasis of key areas Best‐of‐ Breed Complete Suite Emphasis of business integration Integrated approach components from different vendors that are the best in their respective domains, given adequate compatibility Figure 17‐2 Distinct Emphases of the Best‐of‐Breed vs. Complete Suite of these components with each other and with the Approaches existing and future technological infrastructure of the organization. This best‐of‐breed approach recognizes that not every company needs every single piece of a complete enterprise system, but the approach misses to recognize the importance of an integrated solution. After all, the division of an enterprise into several different departments with distinct goals and characteristics is an artificial approach to make the enterprise more manageable; in reality, all departments work together toward a common goal, such as profit maximization. 17.4 Open Source – Always A Cheap Alternative? At some point during the software selection process we will come across open source solutions (Maxville et al. 2009), which usually have much lower licensing cost than marketed solutions, if any. Open source software is software whose source code is freely available, implying that these software solutions tend to be also free of licensing costs. For example, Linux is a free operating system, and Apache Open Office is an office suite that can be obtained free of licensing costs. Hence, open source solutions appear to be much cheaper than regularly marketed software products such as Microsoft Windows or Office – at least at the surface. One needs to consider that open source solutions often have large hidden costs due to the lack of support associated with them. For example, there is usually no vendor support in terms of system © 2012, Robert & al 17 7 installation in the live environment or in terms of user training bundled with open source solutions. Further, there are generally no guaranteed updates since no company is obliged to provide them. This lack of vendor support implies that a strong internal technology department is needed for any company considering open source solutions; open source is not for companies that have outsourced their technology departments or otherwise lack technological expertise. However, open source solutions can be of substantial value to firms with idle technological resources and ample technological expertise. 17.5 Contemporary Issues in Software Selection A number of additional considerations warrant brief introductions. Especially important are business agility, contextual aspects, and outsourcing. Business Agility. Today’s fast paced business environments require organizations in many industries to be flexible with respect to their business operations and corresponding software solutions so that environmental changes can be accommodated. Hence, business agility is emerging as the next major factor in the software selection process (Persaud 2011). For example, in the case of the introduction of a new product line, it is important that the available software solutions can support this change. Importance of Context. It should not be overlooked that different project teams and users may interpret the costs and benefits of a software solution for a particular business problem quite differently. Since these interpretations shape all aspects of the selection process, particularly the requirements analysis, the evaluation, and the final decision‐making, we need to consider structural influences, power asymmetries, and the economic positioning of relevant social groups in the selection process (Howcroft and Light 2010). Outsourcing. Outsourcing is a relationship between a client company and a vendor in which the client asks the vendor to perform all or part of its software selection activities for it in exchange for a contract fee. While outsourcing can often help companies reach a good selection decision, particularly those companies with small information technology departments, they also have important pitfalls that should be considered. These important barriers to successful outsourcing include, first and foremost, language and cultural barriers, but also lack of effective project management and lack of technical capability (Khan et al. 2011). These barriers need to be addressed up‐front and hands‐on by the client company for outsourced software selection projects to be successful. © 2012, Robert & al 17 8 17.6 Conclusion We have taken a brief expedition into the software selection process and have, hopefully, learned some concepts that may prove helpful in circumventing some of the challenges inherent in this process. Hence, equipped with this recently obtained knowledge, we can address Laura and Pierre’s fundamental questions. Of course, we begin the selection process by creating a project plan, a timeline, and a budget. We proceed with the requirements analyses, vendor evaluations, presentations to management, and the ultimate decision making. We have also learned that functional requirements, including software functionality, security, performance, and compatibility, are those related directly to the purpose of the software. Additionally, we have learned that non‐functional requirements, for example, vendor stability, product maturity, and software price, are those requirements that complement the functional ones. Furthermore, we have looked into a variety of other concepts, which equip us with the tools necessary to perform a software selection process successfully from its beginning to end. REFERENCES Burston, J. 2003. “Software Selection: A Primer on Sources and Evaluation,” CALICO Journal (21:1), pp. 29-40. Howcroft, D., and Light, B. 2010. “The Social Shaping of Packaged Software Selection,” Journal of the Association for Information Systems (11:3), pp. 122-148. Gebauer, J., Tang, Y., and Baimai, C. 2008. "User requirements of mobile technology: Results from a content analysis of user reviews," Information Systems and e-Business Management (6:4), pp. 361-384. Khan, S. U., Niazi, M., and Ahmad, R. 2011. “Barriers in the selection of offshore software development outsourcing vendors: An exploratory study using a systematic literature review,” Information & Software Technology (53:7), pp. 693-706. Maxville, V., Armarego, J., and Lam, C. P. 2009. “Applying a reusable framework for software selection,” IET Software (3:5), pp. 369– 380. Persaud, D. 2011. “ERP Trends that Affect Your Success,” Tech Trends IMPO, September 2011. Rasmussen, N. H., Goldy, P. S., and Solli, P. O. 2002. Financial Business Intelligence: Trends, Technology, Software Selection, and Implementation, Wiley: New York. Tams, S. (2008) “Business intelligence appl. in personnel controlling” [Personalcontrolling mit Business Intelligence], VDM: Saarbruecken. © 2012, Robert & al 17 9