How should a company with 5 to 70 employees choose an ERP? Start with process complexity, locations, data quality, required integrations, an internal project owner and the cost of a wrong decision. Compare solutions only after that. An ERP for a small company is not necessarily a smaller version of an enterprise system. It needs to fit the actual way the business works, support planned growth and remain manageable for the existing team.
Management teams often begin with a question such as: "Which ERP includes manufacturing, inventory and accounting?" It is a reasonable question, but not enough for a sound decision. Many solutions cover similar core functions. The difference appears in how a system follows real workflows, connects data and handles exceptions.
A company with ten employees can have more complex needs than a company with seventy. A manufacturer with work orders, bills of materials, material batches, subcontractors and several warehouses faces a different challenge from a service company that invoices a small set of recurring services. Headcount is a starting point for project scale, but it is not the main measure of complexity.
Before the first supplier conversation, it is useful to record answers to six questions:
These answers turn a general enquiry into a framework for ERP selection.
There is no need to digitise every current step simply because it exists. Some procedures were created as temporary workarounds, because data was unavailable, or because one person had kept the process under control for years. An implementation is an opportunity to distinguish necessary controls from habits that slow work down.
An ERP for a small company can usually begin with a narrower scope when operations include:
In this case, a clearly established foundation matters most: items, business partners, chart of accounts, document flows, permissions and core reports. An overly broad project can place unnecessary pressure on a small team.
The need for detailed analysis increases when a company has manufacturing, multiple warehouses, project-based work, field services, multiple currencies, several legal entities or specific commercial channels. The following situations add complexity:
Such a business does not need to implement every module immediately. However, the selected solution needs to support priority processes without constant workarounds outside the system.
A second location is not merely another address in a system. It raises questions about inventory ownership, goods transfers, local entry rules, approval rights and data availability.
For a company with one warehouse, the main issue may be discipline in receiving and issuing goods. A company with several locations needs to check how users will manage transfers, stocktakes, returns and location-level reporting. If sales staff work in the field, the company needs to define clearly which data employees enter immediately and which data is created later in the office.
Do not assume that a shared system will standardise practice by itself. An ERP can provide a shared structure, but management needs to decide who can change prices, approve purchasing, close a work order or correct a document.
An ERP does not turn unreliable data into reliable data. If the same customer exists under several names, items have no unique codes or balances are not reconciled, moving that data may only move an existing problem into a new system.
Before making a decision, carry out a small data review:
Migration is not only a question of data volume. The more important question is whether users can trust opening balances, open documents and key master data.
An integration list can sound simple: bank, web shop, POS, CRM, carrier or payroll system. For assessment, it is more useful to describe a specific event and the data that moves when it occurs.
For a web shop, for example, establish whether an order moves into the ERP, when an invoice is created, how available inventory is updated, who handles returns and where a record of the change remains. For a bank, clarify who matches a payment to an invoice and how partial payments are processed. For manufacturing, define when material is consumed and when a product is considered complete.
Do not purchase an integration simply because it appears on a list. Ask for the intended flow, responsibility for exceptions and ownership of the data. An integration without clear rules can accelerate the transfer of incorrect data.
An external partner can lead workshops, configure a system and transfer knowledge. It cannot make every business decision in place of management. Every project needs an internal owner with sufficient time, authority and understanding of day-to-day work.
This person does not need to be an IT specialist. A finance, operations, manufacturing or commercial manager is often a better fit if they can bring users together and close open issues. The internal owner needs to:
If nobody can take this role, project risk rises regardless of the software selected. In that case, it is sensible to reduce the scope first, improve processes or seek preparation support.
A lower initial price is not always a lower total cost. Conversely, a broad system with many capabilities can create a complexity cost that a small team cannot sustain. It is useful to consider several types of cost:
It is not necessary to convert every item into a precise amount before choosing. What matters is an open discussion about which failure harms the business most. For a company with constrained inventory, warehouse accuracy may matter more than advanced reporting. For a project-based company, timely costs and statuses may matter more than a large set of sales automations.
Consider a company with 35 employees, one production site, a finished-goods warehouse and sales representatives. It currently uses an accounting application, spreadsheets for production planning and a separate inventory record. Management wants better visibility of orders, materials and fulfilment.
The first step is not to search for the solution with the most modules. The company needs to map the flow from order to delivery: order entry, inventory check, planning, material issue, production completion, dispatch, invoice and collection. It should then mark manual transfers, decisions dependent on an individual and data that does not match.
Based on that view, the company can set criteria. Priorities may include reliable items and bills of materials, work order tracking, inventory by location, data transfer to accounting and simple reporting for managers. CRM, advanced analytics or further automation can remain in a later phase if they are not required for an orderly first day of operation.
This framework creates a more meaningful comparison than asking whether a system "has manufacturing". A supplier should show how its system supports the specific flow and explain where decisions, configuration or process change are needed.
An ERP will not independently remove unclear responsibilities, align sales and manufacturing or create data-entry discipline. It will not replace management decisions about inventory, pricing and order priorities. A system can make deviations more visible, but people and rules still run the business.
For this reason, it can be appropriate to defer requirements that are not sufficiently clear. A phase with organised core processes can be safer than a large initial scope that attempts to cover every exception. At the same time, an overly simplified choice can quickly create a new set of spreadsheets and manual workarounds. The balance should be based on the process with the highest business risk.
For broader context on business digitalisation, see Eurostat's overview of ERP use in EU enterprises . The use of ERP alone does not indicate which scope is appropriate for an individual company.
Before requesting proposals, prepare a short document covering five priority processes, core data sources, required integrations, locations, key users and decisions management needs to make. Use this document in every supplier conversation.
If processes, data or the initial scope are not yet clear enough, ERP and process screening can help structure the decision before solutions are compared. Once a company knows what it needs to organise and who owns the responsibility, ERP selection becomes a testable business project rather than a comparison of long feature lists.