ERP Software Selection Guide
Practical guide to choosing the right solution
The software that appears best in a demonstration may not be the software that works best for your organization.
The difference is not always obvious until after you have chosen a product.
Why Software Selection Is Critical to Implementation Success
The software selection process is more than comparing features and pricing and listening to vendor sales pitches. It is about defining how your organization will work, coordinate data, support users, and function after it is implemented.
This is essential for an ERP or ERP implementation, an already existing CRM and ERP landscape, a business integration application, or any other mission-critical software implementation project. A bad selection decision can cause problems that are expensive and difficult to rectify down the line.
The problem in the selection is typically made before the implementation project begins. At that stage, many of the future risks are just starting to surface. Requirements are often incomplete, stakeholders may have contrary agendas, vendors offer their products in the best possible light, and costs are not always easily comparable.
However, following a disciplined software selection process minimizes these risks. It offers your organization a structure for evaluating options and makes the final choice more transparent.
The objective is not to simply identify the software product with the most features. The objective is to identify the software solution that best fits your company’s business, processes, technology, data, people, and future vision.
Define Business Requirements Before Evaluating Software
The initial step is to determine the organization’s actual needs.
It seems intuitive, but choosing the software is too often the first step, with conversations about products and vendors. If that occurs, the organization may inadvertently shape its needs to the features of a certain solution.
A stronger approach begins with the “AS IS” and “TO-BE”.
Business requirements state what the business wants to accomplish. Process requirements state how the business wants work to be done. Functional requirements state what the software application needs to support. Technical requirements describe what the technical environment takes the solution to support.
These requirements are connected, but should not be confused or treated in the same way.
For example, a business requirement might be to boost the speed and reliability of financial reporting. A process requirement could involve standardizing the approval process across multiple entities. A functional requirement might be automated approval workflows. A technical requirement could involve integration with an existing data platform.
The distinction is essential, as the software should enable the business objective rather than become the objective itself.
During an enterprise resource planning implementation, this becomes particularly relevant. An ERP system can offer extensive functionality, but adding more functionality does not necessarily result in greater business value.
The organization therefore needs to ask:
- What are the business problems that we want to address?
- Which processes need to improve?
- Which capabilities are essential?
- What requirements can we relax?
- Which requirements are only preferences?
- What should the solution support in the future?
- Which existing systems will remain?
- Which systems could eventually be replaced?
Having a requirements structure in place will be helpful down the line when evaluating vendors, crafting RFPs, watching demonstrations, and scoring them.
Map Process Requirements and Future-State Processes
The process requirements need to be given an extra focus because software selection tends to be treated as a technical exercise.
The organization needs to know what business processes are and what they need to be in the future. This isn’t about a detailed process description of everything, but it is about defining the processes that achieve the business outcome and where in the process the pain is.
For example:
List the key end-to-end processes.
Identify key pain points, bottlenecks, manual steps, and duplicated effort.
Define the desired future process.
Highlight areas where off-the-shelf software solutions could improve the process.
Describe when a real business need might require configuration or customization.
Note the criteria to be tested during the software selection.
It avoids a trap that many implementations fall into: choosing a suite of software based on particular features without understanding how the features work together.
A potential system might have an exceptional purchasing workflow. Apart from the good purchasing system, the real business process might also include supplier management, inventory-finance-approval management, data integration, reporting, and user roles.
The selection therefore needs to consider the complete end-to-end process rather than individual screens.
Prioritize Functional Requirements
Functional requirements still matter, but we need to rank and prioritize them.
A good requirements catalogue might organize requirements into categories, such as:
Mandatory requirements
High-priority requirements
Desirable requirements
Future requirements
Out-of-scope requirements
This is what makes the subsequent scoring process highly relevant. It also stops the requirements list from becoming an enormous collection listing out everything as critical.
For each important requirement, the organization should ideally define how compliance will be evaluated. Do not ask whether a vendor supports automated approvals; rather, define what automated approval means in your environment.
For example:
Who can initiate the approval?
What conditions trigger the approval?
How many approval levels are required?
Can approval rules differ by entity?
Are there multiple methods for users to give approval?
Is an audit trail required?
What happens when an approver is unavailable?
Can the business maintain the rules without vendor development?
Specific requirements allow you to quickly compare vendor demos and responses.
ARE YOU READY to take your knowledge to a new level?
Review our End-To-End Masterclass
for comprehensive knowledge.
Start your journey today!
Evaluate Technical Requirements Early
Technical requirements must be defined in close relationship with the business requirements.
IT should not be forced to the end of the process to determine whether a solution will work in a particular environment; the technical team needs sufficient information as early as possible.
Technical requirements may include:
Architecture
Hosting model
Security
Identity and access management
Network requirements
Availability
Performance
Backup and recovery
Monitoring
Data residency
Compliance
Scalability
User management
Application interfaces
Integration capabilities
Technical support
This becomes even more crucial, though, when the new system needs to exist alongside existing applications in an already established landscape.
How SIA can help ERP implementation teams
Teams and key decision-makers responsible for ERP implementations may need a deeper understanding of the system selection process.
This is where Software Implementation Academy can complement project training, vendor-specific training, and consulting support.
SIA provides software-agnostic learning materials specifically focused on software implementation projects. The self-service platform combines video training, downloadable templates, individual activities, and 1-on-1 sessions to help professionals understand implementation flows, overcome barriers and pitfalls, and contribute to or lead successful implementations.
The material can be useful for professionals involved in different parts of an ERP implementation, including:
- Procurement teams
ERP project managers
Implementation managers
Technical-functional consultants
Software developers
CIOs and CTOs
Project coordinators
PMO professionals
Change managers
Program managers
Customer success managers
IT consultants
Project contributors
These audiences are central to the implementation ecosystem and often need to understand how their individual responsibilities connect to the wider project.
Learn before the project becomes difficult
SIA’s training focuses on practical implementation knowledge, methodologies, concepts, and tools that professionals can apply in real software implementation projects.
For example, an implementation professional can use structured learning to improve their understanding of:
ERP implementation phases
Software implementation processes
Project planning
Implementation barriers
Implementation pitfalls
Stakeholder cooperation
Business and IT alignment
Implementation methodologies
Testing
Data and integration considerations
Project management
Post-implementation activities
The objective is to build knowledge and talent in-house and not to rely on an external party, such as the ERP vendor or integration partner.
ARE YOU READY to take your knowledge to a new level?
Review our End-To-End Masterclass
for comprehensive knowledge.
Start your journey today!
Assess Software Integration and Data Requirements
A software system hardly ever operates as a stand-alone application. ERP implementation can include CRM, HR, payroll, banking, e-commerce, warehouse and manufacturing management, reporting, or any other specialized systems.
You should consider the data integration capabilities and the integration processes in the enterprise resource planning selection process as part of the solution and not leave them as technical afterthoughts.
A solution that fulfils all the functional requirements but introduces large problems in integrating it with other systems may be a poor choice. Data should also be assessed before the definite choice.
Sometimes organizations get too caught up in the function and forget about data. However, data handling and management are one of the cornerstones of a successful implementation.
Consider:
-
-
What data must be imported into the new system?
-
Where is the data now?
-
How reliable is the data?
-
Are there duplicates?
-
Are master data structures consistent?
-
Who owns the data?
-
What historical data must be migrated?
-
Which data should be archived instead?
-
How will data quality be validated?
-
How will data be exchanged with other systems?
-
These questions may also reveal the complexity of implementation that is otherwise unseen in a regular product demo. If two options seem functionally viable, but one of them takes you through a lengthy migration process and involves significant data cleansing, you need to dig a little deeper.
Data migration can have a significant impact on the effort, schedule, cost, and risk of implementation.
Evaluate Software Vendors, Not Just Software Features
Look at the entire offering; vendor assessment should not be limited to the product.
The organization is not just selecting a piece of software, but they are selecting a vendor collaboration and, in many cases, an implementation ecosystem. The vendor’s product might be a very strong candidate, but your organization needs to understand how the vendor will operate.
Relevant questions include:
-
-
How mature is the product?
-
What is the product roadmap?
-
How frequently is it updated?
-
What level of support is available?
-
What implementation partners are available?
-
How experienced are those partners?
-
How does the vendor treat significant customer problems?
-
How transparent are additional costs?
-
What references can the vendor provide?
-
How similar are those reference customers to the organization?
-
How dependent is the organization likely to become on the vendor?
-
The last question is explicitly important. A highly customized solution will foster significant reliance on specialized knowledge. In cases where the environment has only a few experts, changes and future software maintenance may be challenging.
Vendor evaluation should therefore consider both the immediate project and the longer-term operating model.
Build an Effective RFP for Software Selection
An RFP is intended to make it possible to compare vendors against each other. An RFP should enable making the key distinctions between the solutions transparent.
A practical RFP can include:
-
-
-
Business history and goals
-
Scope of the project
-
Existing application and process landscape
-
Future-state goals
-
Functional requirements
-
Technical specifications
-
Requirements of integration
-
Data and migration needs
-
Implementation expectations
-
Expectation of support and maintenance
-
Vendor details
-
Business and commercial needs
-
Requested implementation approach
-
References
-
-
The RFP should also explain how responses will be evaluated. Otherwise, vendors could have to put a lot of energy into their responses to show how they are meeting the needs of the requirements without actually knowing what things are really critical to the business.
Use Business Scenarios for Software Demonstrations
The demo should be at the customer’s control, not at the vendor’s control. This is one of the most fundamental rules in choosing software.
A demonstration by the vendor is supposed to be a shining example of the product, naturally. This is not a problem. The problem arises when the client organization leaves it up to the vendor to determine what should be demonstrated. Almost any mature software product can be made to look very appealing with a generic product presentation.
Rather, demos need to be based on real-world use cases and realistic business scenarios.
For example:
-
-
Set up a customer or vendor
-
Initiate a transaction
-
Request an approval
-
Handle an exception
-
Combine your data with a different system
-
Create report
-
Fix an error
-
Handle a change in the process
-
Show the user experience for various roles
-
The scenarios used must follow the organization’s processes. The project team should also ask vendors to clarify what is out-of-the-box functionality and where configuration, customization, third-party software, or manual intervention begins.
This distinction can heavily impact the eventual software implementation process.
Create a Structured Software Selection Scoring Model
Scoring frameworks provide a solid structure for decisions that can otherwise turn into subjective choices. The scoring model needs to be defined before the final vendor choice.
Typical categories may include:
-
-
Business fit
-
Process fit
-
Functional fit
-
Technical fit
-
Integration
-
Data and migration
-
User experience
-
Vendor capability
-
Implementation approach
-
Support
-
Total cost of ownership
-
Implementation complexity
-
Change impact
-
Strategic fit
-
Not all categories should have the same weighting. Alternatively, if integration is a priority to the digital transformation strategy, then integration may be weighted more than another less important feature.
An example scoring model might be a 1 to 5 scale:
-
-
-
Does not meet the requirement
-
Meets the requirement only with significant limitations
-
Meets the requirement adequately
-
Meets the requirement well
-
Meets the requirement exceptionally well
-
-
The organization can give each of the categories a weighted value. This does not make the decision mathematically optimal; however, it simply makes it more transparent and reasonable: The project team can better align why a certain vendor was given a score versus a statement such as “this option feels better”.
Calculate the Total Cost of the Software Solution
Consider the overall cost of ownership instead of simply the purchase price of the software. The price of the software license or subscription is just one part of the cost.
A more practical evaluation would take into account the total ownership and implementation costs.
Potential cost categories include:
-
-
Software licenses or subscriptions
-
Implementation services
-
Project management
-
Data migration and integration
-
Customization
-
Testing
-
Training
-
Change management
-
Infrastructure
-
External consultants
-
Support
-
Software maintenance
-
Additional environments
-
Future upgrades
-
Internal employee effort
-
A clear cost breakdown is even more critical when comparing solutions such as cloud and on-premise models or solutions with different implementation models.
A lower starting price does not always mean you will pay less overall. Similarly, a more expensive solution can be more cost-effective over time if it reduces all involved work, manual effort, integration effort, or maintenance effort significantly.
Assess Implementation Complexity Before Selection
Implementation complexity should be assessed before the decision is final. This is where software selection and software implementation really go hand in hand.
The company should ask not only:
“Can the software do this?”
It should also ask:
“How can we get the software to do this in our company?”
For each major requirement, consider:
-
-
Standard functionality
-
Configuration
-
Custom development
-
Third-party extensions
-
Integration
-
Data migration
-
Process change
-
User training
-
Testing effort
-
Operational support
-
A requirement that technically can be fulfilled may still be expensive or difficult to implement.
This is one reason why the distinction between implementation and development is relevant. Implementation of software does not mean building a new system; it means a solution being deployed to an existing organizational environment, including its processes, people, data, technology, and governance.
The selection process should therefore anticipate the future implementation project plan.
Evaluate Change Impact and Organizational Readiness
The impact of the change needs to be taken into account during the system selection process.
Having a great software product does not mean a smooth transition for the employees. The project team should determine the potential impact on each of the solutions under consideration:
-
-
Daily activities
-
Roles and responsibilities
-
Approval processes
-
Reporting
-
Decision-making
-
User interfaces
-
Skills
-
Management processes
-
Collaboration between departments
-
The overall software implementation impact may be positive, but it still needs to be understood and recognized. For example, the new solution might simplify a number of manual steps but use a more regimented process. Some staff might view this as a good thing; others might see it as a loss of flexibility at first.
Early understanding of this effect allows for improved change management training. Also, it allows management to assess the readiness of the organization to adopt the solution under consideration.
Make the Final Software Selection Decision
The final and ultimate selection should be based on a holistic view.
By the end of the system selection process, the organization should not just be asking which vendor achieved the highest score. Instead, the final decision must be made considering the balance of business value, solution fit, cost, complexity, risk, and organizational maturity.
A pragmatic and realistic review often covers:
-
-
-
Does the solution support the business strategy?
-
Does it support the critical processes?
-
Does it meet the mandatory functional requirements?
-
Can it operate within the technical environment?
-
Can it integrate effectively with other systems?
-
Can the required data be migrated and maintained?
-
Is the vendor capable of supporting the organization?
-
Is the implementation approach realistic?
-
Is the total cost acceptable?
-
Is the organization prepared for the required change?
-
Are the major risks identified and understood?
-
Does the expected business value justify the investment?
-
-
If most of these questions cannot be answered convincingly, then probably the decision is not yet clear for final approval.
Software Selection Best Practices: Key Takeaways
It is not possible to remove every uncertainty from a well-designed software selection process. That is too unrealistic. There are unknowns in every major software deployment.
Our aim is to highlight the critical uncertainties as early as possible before we are committed to a particular solution.
The most effective approach is to:
-
-
Begin with business goals, not the product.
-
Understand critical processes and identify desired improvements.
-
Differentiate business, process, functional, and technical requirements.
-
Engage with both business and IT stakeholders early.
-
Determine compatibility and data requirements before choosing.
-
Evaluate vendors on top of their software product.
-
Use an RFP template when necessary.
-
Make demos scenario-based and customer-driven.
-
Specify the scoring model in advance of vendor comparison.
-
Think of total cost of ownership rather than purchase price.
-
Assess implementation complexity.
-
Understand and prepare for the organizational change.
-
Document the assumptions, risks, and open questions.
-
Choose the final option according to the overall fit and not the most tempting demonstration.
-
The system selection becomes the foundation for every following implementation step.
A good solution can be a facilitator of a successful implementation, whereas choosing the wrong solution can create organizational barriers that the project team will be managing for years to come.
Software selection is not a procurement activity at the beginning of an ERP implementation or software implementation project. It is one of the first major decisions that determines how realistic the future project will be. A more effective strategy is to choose the solution that the organization is able to implement, adopt, integrate, operate, and improve over time.
This is why software selection is more complex than choosing a product. It becomes the first step to a successful implementation.
