Selecting the correct Enterprise Resource Planning (ERP) software can be a daunting task. With the prevalent risks of implementation failure as well as the potential for cost overruns, organizations want to make sure they are doing their utmost to maximize success. One key challenge is knowing and understanding what success means to all stakeholders (Hint: It’s not the same for everyone!).
ERPs are systems that govern multiple functional areas within a company. They are designed to support the management and the integration of different business units through centralization and streamlining of business processes. ERPs also allow for facilitated reporting and evaluation of real time metrics. The selection and subsequent implementation of an ERP platform is therefore not your typical IT project, but a company wide venture that has touch points across numerous facets of the business.
ERP implementations are generally expensive and complex undertakings, so it is essential to define the implementation strategy and success factors prior to the deployment effort. ERP systems are highly integrated and drive changes in process, organizational structure and culture. Their extended impacts can go as far as changing the way people carry out their day-to-day jobs. Because of this, thorough planning and diligent execution needs to go into the selection process as well as the eventual execution of an effective change management process to support and maximize successful adoption of the new technology and toolsets.
Key benefits of an ERP implementation can be grouped into value-oriented pieces:
Standardized business processes
Supported growth acceleration and scalability
Standardized and real-time reporting
Improved key performance indicators
Facilitated access to data housed within the ERP solution
Before we get too far into things, it is worthwhile to define a few aspects tied to the ERP selection/implementation lifecycle. Most ERP providers have their own vernacular when it comes to implementation phases and, for the sake of this blog, we will refer to “Implementation”, in the general sense, as it relates to all the activities that come after the Vendor Selection phase and before a product is released for operational use. Vendor Selection elements would include everything prior to the implementation itself, and are as follows:
Business Case – What are we trying to achieve, and why?
Internal Information Gathering – How do we do things now? What requirements are we trying to address? What do we need in place to operate effectively?
Request for Information (RFI) – What vendors are potential candidates for the needs that we have?
Vendor Evaluation and Selection – Which vendor or product best meets our needs?
Vendor Audit – Are more in-depth vendor audit actions required? If so, which one?
Contract Negotiation – Review and negotiate the contracts (SLA, Quality Agreement, etc.)
Business Case
Input: Underlying business driver(s) prompting the need for new software.
Output: Approved Business Case
It is by building a Business Case that you will define what the best ERP strategy is for your business, and where your vendor selection process should start. By taking a hard look at the people, the processes, and the technology that reside within your organization, you should be able to select an ERP solution that will be well suited to your reality.
ERP functionalities will benefit many aspects of an organization’s operations. It is therefore imperative for the relevant stakeholders to define and agree on the implementation goals before initiating the selection process. These goals and their potential value realization should drive the selection process.
A good Business Case is what defines the desired destination (what we are trying to achieve), and the rough itinerary for your ERP selection/implementation voyage. It is imperative to clearly define the destination at the beginning of the venture, ensuring that all subsequent actions and decisions are in line with the required outcome.
Internal Information Gathering
Input: Approved Business Case
Output: Requirements document, As-is Process maps, Change Management related details, Demo scenarios
Effective vendor selection successfully ties your requirements and constraints with the available technology and service providers. For this to happen, a comprehensive capture of the business needs must take place. It is beneficial to group the requirements into sections that align with the groups of functionalities generally offered by the ERP vendors early in the requirements definition process. This grouping of requirements will help the subject matter experts address them in a more strategic manner.
There are many strong resources available that support how requirements gathering should be performed, all the way down to the details of requirements writing. If inexperienced with requirements gathering and writing, we recommend making use of an experienced professional in both requirements gathering and ERP systems, this investment will pay dividends later down the road. In order to tie your requirements with available technology, you will need to invest time into researching the ERP market. It is often tempting to return to familiar grounds to save time, or perhaps select one of the big names out there, but that may not be the best fit for your organization. If it is the best outcome you are after, you will need to do your homework.
As a first step, it is critical to ensure that the vendors being researched are knowledgeable about your industry. Look for groups that have referenceable clients prior to sending out initial requests for information (RFI). It will take some effort to put this initial “long list” of vendors together but it will ensure that more viable vendors are brought into the selection process.
Potential vendors often have predefined requirements that you can leverage for your ERP selection and validation effort, and this is something you should ask about and leverage if possible. These predefined vendor requirements can save you a lot of time, but they should never be considered as “complete” without a thorough review on your part. The reason for this is simple: It is only by reviewing those requirements in detail that you can ensure they are fit to meet your operational needs. Even if you have your own requirements, you may not know what you don’t know about a particular solution or vendor, and only by looking at vendor provided requirements will you be able to shed light on important pieces of information that the vendor documentation could help expose.
We cannot overstate how critical the business process engineering phase is to your success. It is done at the beginning of the project where the mapping of one's current state is the initial exercise (How do we do things now?). While carrying out the process mapping exercise as part of your requirements definition effort, we suggest choosing 2 or 3 processes that are complex or that are pain points to the organisation. Then, earmark those processes for use as demo scenarios further down the selection process. This will ensure that the demos are reflective of your actual operations and more pressing business needs.
Request for Information
Input: Requirements, Process maps (As is)
Output: RFI Document, List of potential vendors
In order to ensure maximum value realization, your organisation’s specific requirements must be understood and captured during the early phases of the ERP selection process.
Once the current state has been defined and with your requirements in hand, vendor assessment can now begin.
In order to carry out an effective and efficient vendor assessment, it is essential to level the playing field. This is done through a quantifiable questionnaire, usually called a Request for Information (RFI) document. A good RFI should be based on your requirements and be weighted based on their value to your business. For example, a critical element of a supply chain may be tied to the reception of raw materials from a global distributor so this requirement would merit a higher score than a requirement that is more of a “nice to have”. Scoring should allow for vendors to select options of “does not meet”, “partially meets”, and “fully meets” requirement, with scaled scoring based on their response as well as a comments section allowing for the vendor to justify their response. It should be noted that the potential vendors should not see the weighting as it could bias their responses.
Within the RFI, there should also be sections for non-functional requirements. This can include question about vendor specific software constraints and their mode of operations. If you operate in a GxP environment, you should plan to include compliance questions into your RFI. This will allow your RFI to double as a postal audit. You don’t want to realise that a vendor does not meet your compliance needs after spending a great number of hours in demo, communications, evaluation and negotiation.
With your list of potential vendors from the previous step, and your newly created RFI document, you can now reach out to each potential vendor. Remember to specify a deadline with your RFI but be realistic with the requested turnaround time. Try to provide enough time for all to properly complete the RFI, without having things drag on longer than they need to.
Vendor Evaluation and Selection
Input: Completed RFI documents
Output: RFI scorecards, RFP, Demo scorecards, selected vendor, Process Maps (Future State)
Once the RFI documents have been returned by each vendor, a thorough RFI review can be carried out. At this stage, it is advisable to plan time to go back and forth with vendors to clarify their answers.
Following this review, 3 to 5 vendors should be chosen for demos and further discussion. A demo scorecard should be prepared ahead of time to be leveraged during the demos, allowing for notes to be taken and for rankings to be applied to common elements such as: ease of navigation, user interface, general functionality, etc.
It is important to provide business process scripts to vendors for them to give effective and comparable demos of the product in relation to scenarios that are specific to your organization's day-to-day operations (these are the ones we earmarked earlier). The scenarios that will be demoed should be paired with an overarching tour of the system and its capabilities. Some vendors will provide you with the opportunity to access a demo environment that you can navigate on your own, before and/or after the demo. This option may allow you to raise or answer additional questions on your own, while also getting a better feel for the solution.
While reviewing the system’s functionalities, it is important to begin understanding where there will be opportunities for positive change. Ensure that time is taken to compare your current operations (As-is) to the potential future state that would come with the new software. This should be reviewed with members of the vendor team in order to highlight where opportunities for improvement lie, as well as the areas that will be undergoing change to how current activities are being handled. Which departments will be most impacted and what is the strategy to sell and champion these changes internally? All of these potential changes need to be documented and used later when working through the change management portion of the implementation.
As the potential list of vendors continues to be narrowed, a Request for Proposal (RFP) can then be delivered to the final 2 or 3 vendors. The RFP should include details related to the baseline cost for the planned implementation, licensing for the selected modules, maintenance and support and any other fees that could present themselves during the lifecycle of the solution. Some of the service attributes that should be thoroughly understood at this point are around the following project areas:
Project schedule – task sequencing and timelines
Resourcing requirements – what will be needed from your side to complete the implementation, both from a technical and a knowledge/skill perspective
Training requirements – training needs prior, during, and after the implementation and users/admin guide and training materials included
Long term costs – licenses, customizations, reports, training, etc.
Maintenance and updates – free/paid updates, update frequency, support for validation of update
Included services – support to computer system validation, number of supported environments (ex.: development, staging and production), data migration
Other terms – Duration, cost structure (ex.: number of regular and advanced users)
This phase of the selection process ends once the selected vendors have been evaluated, leading to the selection of the best vendor for your needs. If none of the vendors are deemed adequate, you will either need to go back to a previous step of the process to find another potential vendor, rework your requirements or abandon the project.
Vendor Audit
Input: Completed RFI/RFP documents
Output: Audit Report, References
If the RFI you created in the previous section doubled as a postal audit, you may have already determined that you could use this vendor. If this was not the case, or if you determine that subsequent verification steps were necessary, an independent Vendor Audit phase may be required.
The Vendor Audit portion of the process will be looking at the selected vendor(s) to ensure they are able to meet all required quality standards. Is the company committed to following those standards? Does their Quality Management System cover the necessary requirements? Do they have detailed practices that cover the related needs? If you are a GxP organization (GLP, GCP, GMP, GDP, etc.), Vendor Audits should be a well know affair, but remember to request references from clients in your industry.
An important aspect of a successful long-term relationship which is difficult to quantify, and review is their culture. How does the company treat its employees? Its clients? Does their mission statement and values mesh with your organisation’s? Try to devise questions or verifications that could corroborate or refute this alignment. This is not necessarily the deal maker or deal breaker, but I have certainly seen this factor shift the momentum of a deal that was, from a scoring standpoint, too close to call.
Contract Negotiation
Input: RFI, RFP, Audit Report
Output: Signed Contract, SLA, Quality Agreement, Total Cost of Ownership details
Now that you have proposals in hands you hopefully identified your primary, secondary and tertiary contenders, it is time to conduct the final negotiation. Review the vendor’s proposals and how their solution will optimize your operations while ensuring a high degree of confidence in what the total cost of ownership will look like. This involves taking into consideration the per user licensing costs, system integrations, training, maintenance, customizations, custom reports, upgrades, internal costs, and other fees. Take a hard look at the Service Level Agreement (SLA) for any hidden costs such as system enhancements and upgrades. One must have a high degree of confidence that there is a thorough understanding of all variables, and how they will impact cost as the relationship with the vendor grows and moves forward.
In Conclusion...
An ERP implementation project is a serious undertaking that will impact your organization for years to come. This is true whether you are a small biotech or a large Contract Manufacturing Organization (CMO). To conduct a successful ERP implementation, it is imperative to plan for an effective and efficient selection process.
Investing in a rigorous, transparent and logical Vendor Selection approach will ensure the correct solution fit is attained. Skimping on your selection process is expose yourself to budget and scope issues down the road.
Hopefully this Blog was successful at clarifying the importance and the critical aspects of an effective Vendor Selection process. Although this article was geared toward the selection of an ERP system, the core methodology is applicable for any complex solution selection representing a strategic corporate decision. Should you have any questions, be sure to contact us! We will be happy to help however we can.
Scott McGrail M.Sc. PMP
Chief Operations Officer (COO) at InnovX Solutions
Scott McGrail is a seasoned veteran in software development, implementation, and validation projects and is well-versed across multiple industries, including the regulated space that houses pharmaceutical, medical device, and cosmetic manufacturing and distribution. He is passionate about operations and process improvement, facilitating change, and empowering teams' knowledge transfer.
Opmerkingen