ERP Selection: 10 Areas That Need Clarification

Is your company ready for ERP selection? 10 areas that need clarification

Selecting an ERP system does not begin by approaching vendors or comparing their presentations. First, it is necessary to clarify the reasons for the change, project goals, the scope of the future solution, and the company’s readiness for its realization.

The quality of preparation affects the content of the requirements specification, the comparability of bids, the selection of the vendor, and the course of the subsequent implementation. Ambiguities in the project usually manifest as changes in scope, cost increases, schedule delays, or a solution that does not sufficiently support the company’s needs.

The following ten areas represent a guideline framework for the management of companies that are preparing for ERP selection or are just deciding on a system change. It helps identify topics that should be professionally assessed and unified before starting the tender process.

1. Reason for changing the current ERP system

A company needs to determine exactly why it is considering an ERP change. A general statement that the current system is no longer suitable does not provide a sufficient basis for a decision or for the requirements of a future solution.

The cause of problems may lie in system limitations, inappropriate configuration, low utilization of available functionality, data quality, or historically established business processes. Each of these situations requires a different subsequent approach.

The result of the assessment may be the selection of a new ERP, expansion of the current system, process optimization, or re-implementation. Therefore, before starting the selection, it makes sense to verify whether the planned change corresponds to the actual cause of the problems.

2. ERP project goals

ERP project goals should describe the specific change the company wants to achieve. This could include, for example, more accurate production planning, better inventory management, more accessible data, more reliable calculations, better reporting, or the unification of processes between individual operations.

General formulations, such as increasing efficiency or company digitalization, do not provide sufficient support for system selection or for evaluating the implementation result.

Goals should be converted into measurable or clearly verifiable criteria. Subsequently, they must be reflected in the requirements specification, bid evaluation, contractual terms, and the method of acceptance for the implemented solution.

3. Scope of the future solution

Before approaching vendors, it is necessary to define which companies, operations, organizational units, and business processes the ERP project should include.

Part of the decision is also the future role of the ERP in relation to other business applications, such as MES, APS, WMS, PLM, CRM, or BI. It must be clear which areas will be supported by the ERP and which will remain in follow-up systems.

If the scope is unclearly defined, vendors may prepare bids based on different assumptions. One bid may include a comprehensive solution including integrations, while another counts only on basic functionality. Such bids are not comparable in terms of substance or price.

4. Readiness of business processes

An ERP system supports a specific way of working. Therefore, before starting the selection, it is necessary to know the form of key processes, their main limitations, and the links between individual areas of the company.

Historical procedures may stem from the limitations of the current ERP, local customs, or an organizational structure that no longer corresponds to current needs. Automatically transferring them to a new system would increase the complexity of the solution and could lead to further custom modifications.

Process preparation helps distinguish the company’s actual needs from procedures created as a reaction to the limitations of the current system. At the same time, it creates a basis for deciding which processes should be unified, changed, or newly supported by ERP functionality.

5. Data quality and availability

The state of master and transactional data significantly affects the scope, complexity, and risks of ERP implementation. Before starting the project, it is advisable to assess, in particular, the uniformity of code lists, the existence of duplicates, the completeness of key data, and responsibilities for their management.

In manufacturing companies, this may involve, for example, material items, bills of materials (BOM), technological procedures, standards, workstations, or data needed for planning and calculations.

Not all data needs to be cleaned before ERP selection. However, the company needs to know its status, responsibilities for its management, and the expected scope of preparation before migration. Vendors can thus more accurately determine labor requirements, division of responsibilities, and data transfer conditions.

6. Requirements for the new ERP system

ERP requirements should be based on the business and process needs of the company. A mere list of functions from the current system or individual user ideas usually does not lead to a high-quality requirements specification.

Requirements should be categorized according to their importance.

Critical requirements

Functionality and conditions essential for the company’s main operations. Failure to meet them may be a reason to exclude a solution from further evaluation.

Requirements supporting project goals

Areas directly related to the expected benefits of the ERP project, such as more accurate planning, more accessible reporting, more efficient inventory management, or process unification.

Developmental requirements

Functions and options that the company may not use during the first deployment but are important from the perspective of the long-term development of the solution.

Professional assessment helps limit unnecessary custom modifications while capturing functionality that will be important for the future operation and development of the company.

7. Internal project team and its capacities

ERP selection and implementation require the active participation of management, process owners, key users, and IT. Before the project starts, it is advisable to determine who will be responsible for individual areas and what capacity they can realistically dedicate to the project.

The vendor brings system knowledge and implementation experience. However, decisions regarding target processes, responsibilities, data management rules, and company priorities remain with the client.

Overloading key employees, unclear authorities, or limited management availability affect decision-making speed and the quality of project outputs. Therefore, the availability of the internal team must correspond to the schedule and project management method.

8. Evaluation of ERP systems and vendors

An ERP system cannot be evaluated solely by the number of declared functions. What matters is the way it supports the company’s specific processes, the degree of standard functionality utilization, integration options, technological sustainability, and the ease of further development.

In addition to the system, the vendor must also be assessed independently. The evaluation should particularly consider:

• coverage of key requirements,
• the method of solving specific process scenarios,
• the extent of necessary modifications,
• integration and technological possibilities,
• experience with similar projects,
• the proposed implementation approach,
• the composition and experience of the implementation team,
• support and further development conditions.

Presentations, reference visits, and potential proof-of-concept studies must be based on a unified requirements specification. Only then can the results of individual vendors be substantively compared.

9. Total cost of the ERP solution

The purchase price represents only one part of the economic evaluation. The comparison should also include licenses or subscriptions, implementation, integrations, data migration, infrastructure, support, updates, custom modifications, and future development.

For a substantive comparison, it is necessary to create a unified price structure and verify the assumptions on which individual bids are based.

A lower initial price may be related to a limited scope of delivery, a higher share of work on the client’s side, or costs that only manifest during implementation and subsequent operation. Therefore, the economic evaluation must be based on a comparable scope and consider the total cost of ownership (TCO).

10. Contractual and implementation conditions

The contractual framework should be prepared during the selection process. It must follow the requirements specification, the vendor’s bid, the schedule, the division of responsibilities, and the required project outputs.

Key topics include:

• precise definition of the scope of delivery,
• responsibilities of the client and the vendor,
• linking the price to specific outputs,
• schedule and project milestones,
• change management rules,
• acceptance criteria,
• conditions for price or deadline changes,
• the link between implementation and subsequent support.

Postponing contract negotiations until after a preferred vendor has been selected limits the client’s negotiating space. Therefore, essential contractual terms should be part of the bid evaluation and final decision.

What the overview reveals and what it does not solve

If any of the mentioned areas are not sufficiently prepared, it does not automatically mean a delay in the ERP project. However, the topic must be professionally addressed before it affects the requirements specification, bid evaluation, or implementation conditions.

The overview does not replace:

• an assessment of the current ERP environment,
• analysis and design of target processes,
• formulation of functional and data requirements,
• preparation of tender documentation,
• knowledge of the ERP system and vendor market,
• an objective evaluation model,
• economic evaluation of bids,
• preparation of the contractual and implementation framework.

An independent ERP consultant helps combine the views of management, process owners, key users, and IT into a unified requirements specification. At the same time, they verify whether vendor bids are mutually comparable and whether the proposed solutions match the nature of operations and the company’s long-term needs.

Their role does not replace management decision-making or the knowledge of the internal team. It complements them with experience in ERP project preparation, system and vendor evaluation, the contracting framework, and the risks of subsequent implementation.

Professional Preparation for ERP Selection

AppliCon IT helps companies define the initial situation, goals, scope, and decision criteria for an ERP project. Based on this, we prepare the requirements specification, evaluation model, and contractual framework for a substantive comparison of systems, vendors, and the total costs of proposed solutions.

Consultancy can be used for the entire ERP selection or for a selected part, such as assessing the initial situation, preparing the requirements specification, evaluating bids, or contract negotiations.