What a small business should decide first
- ERP becomes relevant when several processes need a shared source and the current patches create meaningful errors or delays.
- Requirements should be expressed as working scenarios and controls, not a copied feature checklist.
- Data quality, integration and adoption often shape the result more than the sales demonstration.
- Evaluation must include total cost, security, support, data portability and a provider exit path.
1. Recognize when the problem crosses functions
A spreadsheet is not automatically a failure. It may be enough for a simple process with modest volume and a clear owner. ERP becomes worth considering when sales cannot see available inventory, purchasing works from another list, accounting reconstructs activity at month-end or leaders receive different figures depending on whom they ask. The relevant condition is poor coordination among processes, not company headcount.
Document the consequences: delayed orders, emergency purchasing, unexplained inventory, late invoices, duplicate entry or closes that depend on one person. Estimate rework and the risk of decisions based on incomplete information. If the problem remains inside one function, improving a specialist application may be sufficient. If several functions share master data and transactions, assess ERP.
- The same entity is recorded differently in several tools.
- A transaction must be re-entered for the next team to continue.
- There is no trace from order and purchase through payment and accounting.
- Reports depend on recurring manual reconciliation.
Buying an ERP to “organize the business” reverses the sequence. Define the operating order first, then assess which platform can sustain it.
2. Define scope through processes and outcomes
Bring together a small group of operations, finance, sales, purchasing and technology owners. Describe eight to twelve essential scenarios end to end: convert a quote into an order, reserve stock, replenish, receive goods, invoice, apply a payment, process a return or close a period. For each scenario, identify data, decisions, approvals, records and exceptions.
Separate what the first phase must deliver from what would merely be useful. A contained scope lets the team validate architecture and learn before adding payroll, maintenance, projects or other modules. Define measurable outcomes such as removing duplicate entry, establishing dependable availability or closing with known reconciliations. The initiative needs a sponsor, process owners and acceptance criteria.
- Processes included in and explicitly excluded from phase one.
- Relevant users, locations, currencies, taxes and volumes.
- Approvals, separation of duties and required evidence.
- Indicators that will demonstrate an operational improvement.
3. Evaluate fit with real cases, not slides
Give every candidate the same scenarios and anonymized sample data. Ask for a demonstration of initial entry, exceptions, authorized corrections and resulting history. Observe daily work: number of steps, clarity, performance, search, exports, accessibility and mobile experience when needed. A vendor-controlled demonstration can hide the tasks employees will repeat hundreds of times.
Classify each requirement as standard, configurable, integration, customization or unsupported. Configuration uses mechanisms maintained by the platform; customization introduces code or behavior that somebody must maintain. Not every difference justifies recreating the old process. Ask whether the change removes an unnecessary habit or sacrifices a genuine business advantage.
- Comparable script using the company’s data patterns and exceptions.
- Fit matrix with evidence behind every response.
- Separate inventories of configuration, integration and development.
- Participation by people who will perform the work.
“The system can do that” is incomplete. Record how, in which module, under which license, who maintains it and which limitation remains.
4. Treat data and integrations as products
Identify master data such as customers, suppliers, items, prices, accounts, tax configuration, locations and units. Assign ownership and rules for creation, change, duplication and deactivation. Do not migrate everything by habit. Correct identifiers, required fields and relationships. Keep older history in an accessible repository when placing it inside the new ERP adds no operating value.
Draw every system that remains: ecommerce, electronic invoicing, banks, payroll, logistics, CRM and industry applications. For each connection define direction, frequency, owner, common identifier, validation, retry and reconciliation. Do not let the ERP become a black box. The business must be able to follow a transaction and explain where it stopped.
- Inventory, quality and owner of every data set.
- Migration rehearsals with reconciled totals and samples.
- Integration contract with states and duplicate handling.
- Plan to freeze or govern changes during cutover.
5. Compare total cost, provider risk, security and exit
Project licenses by user type, modules, storage, environments, integrations, implementation, migration, training, support and future change. Include internal staff time and the period when old and new systems operate together. Model both growth and contraction. An attractive entry price may change when the business adds locations, transactions or functions.
CISA Secure by Demand guidance encourages software buyers to bring security into procurement. Ask about multifactor authentication, audit logs, roles, encryption, vulnerability management, incident communication, backup and recovery. Apply supplier due diligence such as the considerations in NIST SP 1326, and review export scope, formats, API access, migration assistance and deletion after contract termination.
- Multi-year cost under documented operating scenarios.
- Service expectations, support, updates and responsibilities.
- Identity, audit, resilience and third-party controls.
- A complete, usable export tested before dependency becomes deep.
6. Implement by process and stabilize before expansion
Assign owners with allocated time rather than people who are available only when other work permits. Configure a test environment, prepare data, execute every scenario and track defects. Train by role with company tasks. Acceptance must cover permissions, exceptions, period close, integrations, reports and recovery as well as the ideal transaction.
For cutover, define open inventory, balances, pending orders, owners and reconciliations. Keep one support channel and review issues daily. Do not activate every licensed module immediately. Stabilize, compare the indicators with the baseline and only then decide on the next phase. ERP should become an operating discipline rather than a project that ends at launch.
- Acceptance evidence signed by process owners.
- Cutover, reconciliation, rollback and communication plan.
- Reinforced support during the first operating weeks.
- Governance for change, master data and new integrations.
Frequently asked questions
Questions that should be settled before acting
How many employees must a business have before it needs ERP?
There is no universal threshold. Complexity, volume, shared data and the cost of poor coordination matter more. A small business with inventory and several integrations may need ERP sooner than a larger organization with simple processes.
Should the business adapt to the ERP or customize the ERP?
Decide process by process. Adopt the standard practice when it removes complexity without losing value. Configure or customize when a differentiating, contractual or control need is demonstrated. Every customization requires an owner and maintenance budget.
Which data should be migrated?
Move clean master data, balances and open transactions needed for operation. Older history may remain in a searchable repository when full migration adds little value. The business must also account for any validated retention obligation.
