Software Application Selection - Essay Example

Running Head: Software Application Selection Software Application selection And Implementation (Style: APA) ID 19714 Order No. 239792 16 September 2008 Word Count: 2880 (including topics but excluding table of contents and reference list) Abstract A Software Application System has the potential to enable a business towards partial or full automation thus ensuring better Efficiency, improved Staff Productivity, improved Customer satisfaction, improved Data Consistency, Accuracy & Security, improved compliance to Regulations & Global Standards, improved response to Business Dynamics and improved Bottom Lines. A Software Application System essentially changes the way a business is operating making it more structured, disciplined and informed. An integrated Software enabled system unleashes a number of secrets of correlations and analysis on a per-product or per-customer basis which a manual system otherwise is not able to deliver at a high level of accuracy. The Management is informed with accurate and consistent data from a tightly integrated and controlled system who, otherwise, were dependent on the manual, approximate data provided by the functional, unit or branch heads. The benefits of a software enabled business thus are enormous. (Dunshee, ERPN, 2001, p. 2-3 and Upadhyaya, 2005, p.4-11) However, if a Software System is not carefully selected or implemented in the organization, it actually causes more damages than bringing benefits to the table (Litzenberg, 2007, p. 4). This paper presents a structured methodology of Software Application selection and implementation in an organization. Table of Contents: Introduction: Businesses in today’s competitive world are getting more and more complex and expanding across regions and countries. The large span of a business and its complexities makes it almost impossible to be managed manually. Almost every business today is enabled by IT Systems and Services. However, not all IT solutions offer an end to end integrated and relational information management as well as paperless automation. Example, many businesses run with distributed standalone systems operating in departments that are full-fledged applications in silos but the data consolidation & MIS reporting happens after the data is extracted from all systems, copied on excel sheets, graphs/charts are created and then stored on network drives or sent via E-mail. One such sample is very prominently reported in UI-Integrate Project Update presentation by University of Illinois (p.4). The benefits are more tangible to an organization when an end-to-end integrated Application System is implemented for an organization having multiple independent components exchanging data with each other over an integrated information system. Examples of such systems are Enterprise Resources Planning (ERP), Enterprise Wide Systems (EWS), Customer Relationship Management (CRM), Supply Chain Management (SCM), etc. An organization should look for such a solution when the uncertainties in actual revenues, customer satisfaction, operating costs, work duplication, operations performance, ability to grow, forecasting & hypothecations, etc increases beyond a comfort level of the Management and the Stake Holders (The ERP Selection process survival guide, Relevant Business Systems Inc, 2005, p.3) . The objective of this paper is to present a systematic methodology of selection of Software Applications for an organization and present the factors that make it successful. Role of a Software Application Consultant: The role of a Software Application Consultant is very crucial in the success of a Software Application in an organization. This is the first step towards the journey to implement a Software Application but many organizations make a mistake at this step itself. Most of the organizations get carried away by the sales pitching of ERP companies and end up hiring a Software Reseller or Implementer as a consultant. This first step going wring itself increases the probability of failure of the Software Application at the first place. Dave Litzenburg in his presentation on Software Selection has presented an excellent model that explains the thin line amidst the vested interest that a Consultant has in the ERP Solution vis-à-vis the ability & skills to deliver a successful Software Application (Litzenburg, 2002, p.8-9) . It is easy to refuse the work to a general, non-Application consultant who is more aligned towards Infrastructure Solutions or Software Project Management. But the real challenge is faced when a highly skilled and experienced Application consultant has offered his/her services but it is difficult to find out the vested interests that he/she has in some specific Software Application products. It is very essential to first keep in mind the proposed role of the Software Application consultant before signing a contract. Following are some key points to be considered: (1) The consultant should be preferably an expert of the Business Domain of the organization and must have implemented at least one Application in this domain. (2) The consultant should have thorough knowledge of the Application Systems prevailing in the market pertaining to the domain and the best implementation vendors preferably within the country. (3) The consultant should not have vested interest in any Software Application product or vendor. The consultant should be capable of presenting an independent analysis of available applications mapped with the business and select the package which is most suitable for the organization. (4) The consultant is capable to understand and absorb the technical flaws in the existing system, Business Dynamics & Political influencing factors and is able to factor in these aspects to arrive at the right direction in the selection process. (Gusdorf, 2006, p.3) David Sammon and David McAvinue have presented the role of a consultant much in detail in their case study pertaining to ERP software selection process of City and County (Sammon and McAvinue, 2004, entire document). Hereafter in this paper, a Consultant’s approach for selection and implementation of the Software Application is presented. The Software Selection Process: The first essential step in selecting the Software is that the requirements from the Software Application is very clearly identified and documented. The usual purchase process of knowing what is available and then select the best one at lowest cost will not work in selecting Business Application. It is better to continue with current practices rather than selecting the software that may cause more harm than ensuring benefits. The documentation of requirement specifications should be carried out after identifying process champions in every department (to be covered by the software) and getting as many inputs as possible. Adequate time should be spent in this step to identify the need for the software (i.e., impacts of not implementing the software application), identify the requirements, evaluate if they bring value to the business, identify impact of process changes & enhancements wherever necessary, establish costing & return factors, analyze & select best practices of such a system in the same industry, and evaluate & establish a measurement criteria of benefits that the software is supposed to bring to the table. This document should be prepared using a very structured template (example at http://www.klariti.com/templates/Functional-Requirements-Specification-Template.shtml), reviewed multiple times and finally “frozen” from all aspects before proceeding to the net step. This document is normally called “User Requirement Specifications (URS)” in the application industry. This process is very important in order to get user buy-in by involving them deeply and clearly identifying the quantitative as well qualitative benefits of the Software Application (ERP Software Selection, Atrilogy Solutions Group, 2007, p. 1-2). Once the URS is frozen, it should be handed over to the Application consultant to develop the corresponding “Software Requirement Specifications (SRS)”. The SRS presents a detailed mapping to indicate how a software feature shall justify the needs of a user requirement. In addition to the mapping, the SRS taken into account every component that shall contribute to the success of the software application, viz., System features, Hardware features, Platform features, Communication features, Scalability aspects, Reliability aspects, Support aspects, etc (TurningPoint Systems Inc., 2006, p.1; CC Pace Systems, 2003, p.9). In this document, no bias to a particular product is presented. It is an attempt to prepare detailed technical expectations to present a baseline with which vendors can attempt to match their solutions (SRS Template, Weigers, Carl, 2005). Once the SRS is completely documented, then the best Software Vendors who have developed Application Systems dedicated to the domain of this business should be invited and Request for Proposal circulated setting the expectations clearly in the form of the SRS document. A Software Application satisfying a large percentage (say 70% or more) of the SRS requirements should be short-listed. If no Software Application is able to meet the minimum percentage (say at least 60%) of the SRS requirements, then it is better to get the Application developed rather than purchasing an off-the-shelf product. The Evaluation Criteria: It is important to partner with the best professionals in the Software Industry of the specific domain. This is due to the fact that any software will never be 100% complete from the perspective of the SRS and also the Software Application will serve as the lifeline of the business post implementation. The selected vendor should own the software (and not just its intellectual property rights); have sound track record, an experienced customization team, and a sound Project Management methodology (TurningPoint Systems Inc., 2006, p.2-3). The vendor should present a clear plan on what requirements are already mapped and how the rest would be fulfilled. It is important to clearly identify the areas where a feasibility of implementation doesn’t exist. The project management team of the vendor should have adequate experience in bringing to table these finer details to enable the Software Application consultant to verify the acceptance by going back to the functional champions in the company and discussing the impacts on business of the infeasibility of certain requirements which cannot be met by a vendor. If a compromise is not possible, the alternate vendor should be consulted. Some critical factors like infeasibility of compliance to regulations may lead scrapping of the project altogether. Issues and Strategies for Stake Holders Involvement: The Stake Holders should be involved in creating the URS, SRS and in all the discussions pertaining to selection of the Software Application & the Vendor. Normally the representatives of Stake Holders get involved directly who in turn publish back to back reports. In the decision of some very critical aspects of the Software Application (especially related to Governance), the CEO might directly like to be involved. The involvement of Stake Holders (directly or via representatives) is to ensure that: (a) Adequate Buy-in for the application system is obtained at the planning stage itself (b) The Stake Holders are able to monitor the intent of the consultant during the progress of the project. (c) The internal influencing factors like political, Strategic Changes, Organizational Changes, Risk Management, etc. are taken care of in the Project. (d) The Stake Holders are satisfied with the progress made in line with the project plan (e) The Stake Holders have a clear visibility of the people who are involved to contribute to the SRS and URS. (f) The Stake Holders are able to cross-verify the specifications to ensure that they are designed keeping in mind the business benefits. Fancy features not expected to value add much but expected to load the Infrastructure will be rejected by them during the reviews. (g) The organization gets a clear message that this initiative is sponsored by the Management of the organization. (h) The factors and methodology for measuring Return on Investments can be derived and established only when the CEO is involved in the decision making. (The ERP Selection process survival guide, Relevant Business Systems Inc, 2005, p.6-7) Mapping of the Selected Software with Business: When mapping the selected Software Application with the targeted business features it should kept in mind that the focus should be on critical functionality only. Normally, the evaluation process should be completely original because no two companies will have identical process for selection of a Software Application. Moreover the best and brightest individuals from all the departments should be selected to arrive at the desired critical functionalities (The ERP Selection process survival guide, Relevant Business Systems Inc, 2005, p.4). The Software Applications should be very carefully analyzed by mapping their features with the documented critical functionalities. The key to success here is that the Software should not be selected by virtue of its branding only (although it is important). After verifying the credentials of a vendor (detailed out in next section) the Software Application should be thoroughly verified against the desired features documented. Post this evaluation, the short-listed vendors should be requested for a detailed demonstration using some mock data. An on-line demo environment for users to play with is a good idea (CC Pace Systems, 2003, p.10). A sample sheet to be used for comparing the effectiveness of the features of four software systems is presented below: Module Current Practice Targeted Practice Software Application-1 Software Application-2 Software Application-3 Software Application-4 Employee Benefits Employee Information Employee Taxations Employee Payroll Employee Leaves Employee Training Employee History The process till now should only be requiring “Request for Information (RFI)” communications with clients. After the evaluation process is over and a shortlist most preferred vendors is prepared, the next step is to send a “Request For Proposal (RFP)” to the selected vendors and the detailed evaluation process should be triggered. Decision Matrix for Software Selection: Before a contract is awarded to the final selected vendor, a number of parameters pertaining to the vendor and their product should be evaluated. The best practice is to list down all parameters that can influence the decision (decision factors), assign a weighting to each parameter, assign the metrics against which a vendor qualifies to a weighting, give details and then verify which vendor achieves the maximum marks. In the marking however, some parameters should be made compulsory in which a vendor should qualify with high marks (say 70%). (CC Pace Systems, 2003, p.10-13) Decision Factors Metrics Assigned (0 to 100%) Weighting Mapping with SRS 0.15 Track Record 0.1 Quality of the Project Management Team 0.1 References from other customers 0.05 Satisfying the internal Influencing (Political) Factors 0.05 Cost 0.15 Future Scalability 0.1 Vendor Stability 0.05 Support and Maintainability 0.05 Protection against Platform Obsolescence 0.05 Information Security Controls 0.1 Long Term Commitment 0.05 Total Weighting of all decision factors put together 1.0 Based on the outcome of this decision matrix, the contract is finally awarded to the best qualifying vendor. After following such an in-depth and structured selection criteria, the probability of success of the software is quite high. Success Story of the Software Implementation: The Software selected following the above criteria is successfully implemented. The make-live process went on successfully. All the users are provided access to the Software Application via their respective clients on their desktops and laptops. The training function of the vendor provided the following trainings and workshops: (a) Detailed functional training using modules which were customized for the company post all modifications and customizations were completed. (b) Detailed technical and administration training for the backend IT support team and the Application Support team in the production environment. The vendor has established a helpdesk in the organization where all the problems pertaining to the application are logged. In addition to the helpdesk, there is a bug-fixing team working on the application errors being reported via the helpdesk. All rectifications of the bug are then applied to the production environment via a controlled Change Management process. Following are the factors leading to successful implementation of the Software Application implementation that were taken care of during the planning and selection process: The best functional experts from all the departments were engaged to define the functions specifications. The Stake Holders were involved actively via their authorized representatives and sometimes directly. This strategy along with the first point ensured that buy-in was achieved by all the departments of the organization. All the functional specifications were documented in a consolidated document called “User Requirement Specifications (URS)”. Adequate time was given to arrive at the URS which, after all essential approvals was “Frozen” such that no further entries or modifications were entertained. The “Software Requirement Specifications (SRS)” was documented on the basis of frozen URS. The SRS took into account all system level requirements as well in addition to detailing out the software specifications mapped with the URS. The Software Application and Vendor evaluation criteria was very detailed, structured and disciplined. An intelligent mix of qualitative as well as quantitative analysis was followed. The final decision matrix ensured that the most appropriate vendor was selected for this project. The methodology for measuring the “Return of Investment” was very carefully and realistically defined that was approved by the CEO of the organization. These factors can be taken as learning for future projects because all of them put together ensured a very disciplined, collaborative, down-to-earth and approved approach to select the Software Application. Conclusion: Enterprise wide automation of an organization is needed when a number of controls in the business seem to be loosing their effectiveness. Hence, a decision of Software Application is a Business decision with the help of multiple IT decisions. It is important that the representatives of the Stake Holders and Users are involved to a good extent such that all approvals and buy-ins happen seamlessly. The Software Application and Vendor evaluation process needs to be very structured, disciplined and collaborative with an intelligent mix of quantitative and qualitative analysis. A number of documents in this entire process like User Requirement Specifications (URS), Software Requirement Specifications (SRS), functional mapping analysis, vendor evaluation sheets, decision matrix, etc. should be created which can be used later to look back into the success factors and taken as learning from the entire project. Reference List: Purdue University On-Line Writing Lab (OWL) (2008), APA Formatting and Style Guide, Retrieved September 16, 2008, from http://owl.english.purdue.edu/owl/resource/560/01/. Upadhyay, Ankur. (2005), ERP Research, 4-11 State of IOWA. (2001). Enterprise Resource Planning Newsletter. ERP Benefits are many, far and wide. 2-3. Litzenburg, Dave. (2007). Software Selection. 4, 8-9. Technology Group International, M2M United. University of Illinois. (2005). UI-Integrate Project Update. 4. Relevant Business Systems Inc. (2005). The ERP Selection process survival guide. 3-6 Gusdorf, Jeff. (2006). Technology Evaluation Centers Inc. Software Selection processes; Accelerating Vendor Identification. 3-4 Sammon, David, McAvinue, David. (2004). 1-11. Business Information Systems. University College Cork. Ireland. Atrilogy Solutions Group. (2007). ERP Software Selection, p. 1-2 Weigers, Carl. (2005). SRS Template, 1-8 TurningPoint Systems Inc. (2006). Five Steps to a successful ERP Software Implementation. 1-3 CC Pace Systems. (2003). Maximizing Value Minimizing Cost in Software Selection. p.9-13 Klariti Ltd. (2008). Functional Requirements Template. Retrieved September 16, 2008 from http://www.klariti.com/templates/Functional-Requirements-Specification-Template.shtml In addition to the cited references, I would like to extend my special thanks to all those who extended to me knowledge and information that helped me to put together this paper. On their request, their names have not been published herewith. End of Document Read More