Enterprise software evaluation is difficult, where to start, what to do, how to do is usually not documented or does not exist. Many people have cobbled together steps, tasks and procedures to create an approach. This post will offer a best practice approach used by Eval-Source within its methodology for companies to shortlist software vendors.
Keep in mind, that creating the shortlist is one component of a software evaluation project and could possibly make or break your project success. This single task could be the difference between IT failure or success. Here we discuss four tips and tricks that will assist you in your software selection project.
Build a Requirements Document
It is recommended that you create a full standard operating procedure (SOP) business requirements document. This document is the culmination of all the functional and technical business processes used daily to support your business. This includes technical information about integrations to other systems, exceptions, and functional business processes. Be sure to include the “Future” state as the document created will likely be for the “Current” or “As Is” state of the business. The requirements document is the basis for the eventual RFI that will be issued to vendors as part of the RFX and then the vendor demonstration script. Doing this correctly will ease the RFX creation process and identify actual business issues that the software will have to support your business.
Organizations rarely know how software vendors sell their software and the differences that they see as to how organizations perceive themselves. Software is categorized into many categories for endless verticals and industries and with many vendors having significant market expertise which may be difficult for organizations to discern between competing vendors.
A best practise approach is to classify what type of business your company actually does,, services, distribution, manufacturing etc. If manufacturing is your business ascertain what type of manufacturing you do – discrete, process, mixed-mode, ETO. This will aid you in selecting the correct vendors from the beginning.
Not comparing Apples to Apples
Organizations often make the mistake of comparing different types of systems and different deployment models side by side. Cloud, hybrid, managed and on-premise costs for ROI and TCO are all calculated differently. You cannot compare the initial cost of a cloud system to a hybrid deployment model as the measurable cost components differ significantly. Another tip is to consider the base software or the “off the shelf” core package, not the add-ons. The add-ons may confuse the actual need and what is supplied. Usually add-ons are expensive whether they are third-party or from the vendor itself.
A best practices approach is to do a comprehensive due diligence investigation. Include aspects of product features/functions, vendor services, product maintenance, industry expertise, vendor resources, case studies, reference checks, site visits, vendor viability, vendor track record for sticking to budget and timelines, consider analyst reports, like deployment models(cloud versus cloud, not cloud versus managed services or on-premise), strategic fit (matching a s solution to the size of the company. An SMB should not be implementing SAP Enterprise Suite) are some areas to focus on.
A mistake that organizations make is that they do not clearly define what they are doing, how they doing it and what needs to be supported for daily operations. This failure to communicate these requirements can cause the vendor to misdiagnose which type of software is required, resulting in the incorrect type of software to be evaluated and then improperly chosen. Full disclosure from the organization to the vendor is required as the vendor uses this determine the type of software required, as well as possible configurations and workflows to satisfy the business and technical needs. Not fully communicating your needs may result in an improper business requirement mapping (the matching of software functionality to your business needs). This may further affect adoption when implemented as the certain criteria and processes may have been accidentally misunderstood or even omitted. The result, lower adoption and the perception of a failed IT project.
A best practice approach is to fully disclose all business needs to the vendor using your SOP business requirements document that includes, prioritization, exceptions, integrations needed for current systems, current and future processes required, tasks, business process workflows and what you would like automated if possible. This will confirm that certain criteria and business objectives are sufficiently met and aid in the RFX evaluation process. In this process, you should not disclose pricing from competitive vendors as that will question your credibility and make you biased as to a potential vendor which may jeopardize the software selection decision. .
These four tips of building a requirements document, proper market categorization, not comparing apples to apples and full disclosure will possibly identify early issues within your software evaluation process and can be mitigated early before implementation.
Eval‐Source is a consulting firm that provides enterprise software selection and strategic technology consulting services for organizations to achieve success in their IT initiatives. Our consulting practices include cloud and on-premise software evaluation services, ERP Project Management, Project Recovery, , Corporate training and Technology Management Consulting. Our Tru‐Eval selection system allows organizations to avoid IT failure, receive greater ROI and provide accurate decision support for enterprise software procurement. What sets us apart is our unbiased best in class consulting services that provide our clients with value, direction and success in selection, planning and optimization of their technology systems.