Evaluation and selection of an ERP software

Evaluation and selection of an ERP software

Often, the selection and evaluation of an ERP software is a step that the user company shortens and for which it does not prepare adequately, but it is one of the most critical. To find the optimal solution, and make a reliable decision, you must consider as many options as possible. With so many solutions available, it is tempting for the software buyer to consider only the industry leaders or the first choices that appear in search efforts. This shortcut often results in the loss of the ideal solution.

A good ERP software selection and evaluation process minimizes the risks of a failed project.

There are a number of recommendations for the process to be orderly and efficient. Among these recommendations, the following can be highlighted:

  • Have a formal process.
  • Define from highest to lowest:
    • Write and agree on the business problems or gaps that the company plans to solve.
    • Write what processes will solve business problems.
    • Write and agree on what will be the functionality to support such processes.
  • Know the company’s own limitations.
  • Assign budget: secure money.

    • Metrics of interest.

Each of these recommendations will be expanded upon below.

Have a formal process

A formal process is the cheapest way and the one that gives the best results:

  1. Design the documentation that will be necessary to have the support of potential suppliers.
  2. Document what will be the criteria by which you will evaluate and rate suppliers.
  3. Make a work plan and put estimated dates.
  4. Assemble the team of collaborators who will work on the ERP software evaluation and selection project.
  5. Review the articles available on the internet. There is a lot of material that is worth knowing.

Define from highest to lowest

Write and agree on the business problems or gaps that the company plans to solve

Generally, the business problems to be solved are gaps between the current situation and the desired one to achieve business objectives. Consensus on these gaps, in addition to serving for the evaluation of ERP software, serves to sensitize managers about the company’s business needs.

Write what processes will solve those business problems

This is a consequence of the previous step.

Write and agree on what will be the functionality necessary to support such business processes

This is the maximum detail that is reached and it is useful to later rate and cost each one of the software products that the sellers will offer.

Know the company’s own limitations

Assess whether your organization has the necessary and sufficient resources for an implementation. At the time of implementation, it will be necessary to have the people who know the best about the company in order to implement the software with the least amount of difficulties. It will be necessary to replace those people with others or reassign tasks so that the day-to-day work does not suffer.

Allocate budget: secure the money

Define what is the available budget and establish what will be necessary. This definition seems to be a question of the type Who is first, the chicken or the egg? However, unlike the previous question that can generate endless and byzantine discussions, the definition of the budget is easier.

Define priorities

As evaluation is the key to selecting an ERP software, it is essential to remove as much subjectivity as possible and execute a process as objective as possible. Before beginning the interaction with suppliers, it is advisable to have defined the criteria with which a project proposal will be considered acceptable. And note that a software proposal has not been written but a project proposal. It is known that the so-called “ERP project” does not consist only of a software product. There are at least four evaluations or axes that should be considered as a previous step to the selection of an ERP: functional, technical, supplier company and economic. These four axes can be called level 1 or higher level of the evaluation of an ERP software.

If each of these axes is assigned a score or weighting in such a way that the sum of all the scores is 100, it will be defining the importance that each of these axes has with respect to the other. The following examples show two different types of projects:

Note that in project A, the company that has decided the priorities, defined that the functional axis is the most important. In other words, that company is saying “our priority is to solve the business problems that afflict us and we are willing to pay for it.” This message arises when reading the relative importance of the functional (40%) and economic (30%) axes. On the other hand, in project B, the company is saying “we are willing to make certain concessions in the functional aspect because we have a limited budget and we must respect it.” This is clearly seen when comparing the relative importance of the functional (30%) and the economic (45%).

Relationship to supplier companies

Although in most evaluation and selection projects the evaluation of the supplier company is assigned the third or fourth relative importance, it is necessary to know that the selection of a software project implies living with a supplier 5, 7 or maybe 10 years. For this reason, some guides are included to evaluate the firm that will be a supplier.

Before you have a “short list” on hand, make a long list of potential suppliers and invite them to answer a series of questions so that you can gather information about them.

  • Provider strength. The company that offers you the product must have a solid financial position.
  • Implicit technology. Some popular products have been on the market for many years and seem like a good choice. However, detailed analyzes reveal that they are based on old and limited technology.
  • Large number of clients. A small customer database does not provide enough revenue to debug and maintain the product.
  • Stable code. The vendors on the list must have a reputation for clean and stable code.
  • Well developed distribution channel. Distributors must have complete knowledge of the product.
  • Good customization possibilities.
  • Wide range of modules. Enrich products with a varied range of modules to avoid having to replace the system when the company grows.
  • Easy to use. Training is a very high cost of implementation.

There are instances in which the long list of providers can be summoned and then a smaller group can be pre-selected. These instances are associated with two documents that will be seen in the next point.

Prepare the necessary documents before starting

RFI (Request for Information)

A request for information RFI (Request For Information) is a proposal requested from a seller, potential supplier to determine what products and services are potentially available in the market to satisfy the needs of a buyer and to know the capacity of a seller in terms of offer and strengths. RFIs are in common use in major acquisitions, when this requirement could potentially be satisfied through various alternative means. An RFI, however, is not an invitation to bid, is not binding on the buyer or seller, and may or may not lead to an RFP or RFQ.

The responses of the suppliers to the RFI should contain data from the supplier company, the implementer, customers, experience in the field or industry of your company and if it is possible that the project that the supplier will propose is in the budget range. that you defined.

RFP (Request for proposal)

As in other areas of life, using common sense is a good starting point when deciding to use an FRP. For example, issuing a document for the purchase of pencils and other office supplies is unnecessary. RFPs are most frequently issued for complex, highly customized products and services. An example of this type is a website redesign in which the project has numerous requirements and involves various types of knowledge. For the simplest products and services, organizations distribute a Request for Quotation (RFQ). This is a request for quotation that is shorter and requires less labor than an RFP.

Evaluate and compare the information given by the providers. Use a first filter to leave 4-6 providers in the race. The responses to the RFI will help you make a first filter and pre-select a group of companies with which you will deepen your work. Distribute project-specific documentation to those 4-6 vendors, with specific questions and tasks. Use an objective scoring and evaluation method to rate vendor proposals. Follow your formal work plan. Suppliers’ responses to the RFP will be the basis for the preparation of the demonstration and comparison of proposals.

What should not be missing in an RFP

  • Product or service specifications required, in as much detail as possible.
  • Information required from the bidder. For example: price, people who will lead the project, responsibilities, schedule, background.
  • Criteria for selection or disqualification of suppliers.
  • Key dates. For example, opening / closing of the process, visits to facilities, demonstrations, meetings.
  • Confidentiality requirements.
  • Contract model with which the contracting will be carried out.

Leave a Reply