While the requirements specification helps properly structure the ERP selection process, the POC, or “Proof of Concept,” helps validate the company’s and the integrator’s ability to successfully carry out the project!
Using a matrix containing certain essential processes with an associated data set, and the main objectives that have been set, the partner can carry out a preliminary study and begin creating a prototype of the ERP solution. The POC thus makes it possible to create a “mock-up” based on the company’s real data so that solution demonstrations are much more concrete and refocused on the company’s key processes. This approach reassures business managers, who can better compare ERPs and better assess how end users will use them. In our view, it therefore represents a key criterion for choosing the right ERP.
Defining the POC Objectives and Scope
For a POC to be effective, it is important to clearly define its objectives and scope from the outset.
Plan the POC as Early as the Requirements Specification
Defining the objectives and scope of the POC must begin as soon as the requirements specification is drafted. Indeed, it is important to take the company’s needs and expectations into account from the very beginning of the ERP selection process. Since the requirements specification must identify the critical functionalities that the solution absolutely must cover, it will also be used to define what you want to verify with this POC, with clear, precise, and measurable objectives. This will make it possible to validate or invalidate the feasibility of the ERP project.
Here are a few examples of POC objectives:
- Verify that the ERP meets the company’s functional needs.
- Evaluate its performance in terms of response time and scalability.
- Test its ergonomics and ease of use.
- Verify the ERP’s adaptability.
- Evaluate the quality of the support provided.
In addition to functional objectives, it is sometimes useful to take non-functional objectives into account, such as ERP security, reliability, and maintainability.
Identify Functionalities to Observe Under Real-World Conditions
The scope of the POC must highlight the functionalities you want to observe under real-world conditions. It is therefore important not to overload the POC, and to focus on the functionalities that are most critical for the company. In addition, the scope should ideally take time and resource constraints into account: it is important to define a realistic schedule and plan an appropriate budget.
Here are a few tips taken from ERP requirements specification examples and templates to properly define the scope of the POC:
- Involve all stakeholders in the process of defining the POC objectives and scope.
- Prioritize objectives based on their importance to the company.
- Define precise and measurable objectives.
- Break objectives down into smaller, more manageable tasks.
- Estimate the time and resources required to achieve each objective.
Succeeding with the POC for Shortlisted ERP Solutions
For the POC to be conclusive, it is essential to prepare it in advance by formalizing the test scenarios and establishing a precise evaluation matrix. It should always be kept in mind that the main objective of a POC is not to test the completeness of all ERP functionalities, but rather to validate that the choice of software matches the company’s specific needs. And to confirm that the ERP can address the organization’s business challenges and integrate effectively with its existing IT environment.
Formalize the Processes for the Test Scenarios
The test scenarios must therefore be representative of business processes and cover the critical functionalities identified in the requirements specification. For each test scenario, it is necessary to define:
- The test objectives: what are you trying to verify with this scenario?
- The prerequisites: what conditions must be met for the test to be carried out?
- The test steps : how will the scenario be executed?
- The input data: what data will be used for the test?
- The success criteria: what indicators will be used to determine whether the test is successful or not?
And to evaluate the POC results, it is essential to implement a scoring matrix that identifies the various evaluation criteria and their relative weighting. These criteria can be grouped into different categories:
- Functionalities: does the ERP meet the functional needs expressed in the requirements specification?
- Ergonomics: is the user interface intuitive and easy to use?
- Performance: does the ERP perform well in terms of response time and scalability?
- Integration : does the ERP integrate easily with the company’s other systems?
- Support : is the support high quality?
The scoring matrix must be shared with all POC participants before testing begins. This ensures that everyone has the same understanding of the evaluation criteria and that the test results will be assessed objectively.
Of course, carrying out a POC is time-consuming for both the company and the integrators. It is therefore not reasonable to consider carrying it out with all the ERP solutions consulted; instead, it is better to focus on the finalist solutions from the RFP process and provide compensation for it. It should therefore be included in the evaluation of the costs associated with implementing the ERP.
As an expert integrator of Microsoft Dynamics 365 and SAP S/4HANA ERPs, we regularly carry out Proofs of Concept for these two solutions. This neutrality on the part of TVH Consulting enables us to provide an impartial perspective on the market’s leading ERP solutions. Far from steering you toward a preconceived ERP solution, we support you in an in-depth comparative study of the various options available. With complete transparency, we highlight the strengths and weaknesses of each solution, taking into account your budget constraints and technology priorities.
