We only have a few dozen staff. Do we need an ERP?

Headcount is not the criterion; whether data has to flow between departments is. If sales, the warehouse, and accounting each use their own tools but only need to pass a file across occasionally, then doing one part well is usually a better investment than adopting a whole suite. The real signals that integration is needed are these: the same transaction has to be entered in three or more places, the month-end close consumes large amounts of manual reconciliation, or a manager asks for a number and nobody can answer on the spot. Those conditions mean the data has already been cut off into separate islands, and only then does the value of integration exceed the cost of getting there.

Packaged ERP or a custom system — how should a smaller company choose?

For most small and medium businesses the sensible starting point is packaged, and the reason is not cost. A packaged product carries a set of processes that have already been proven in practice, which forces the company to standardize the way it works. Custom becomes worth considering when the core operating process is itself a competitive advantage, when the industry is too niche for a suitable product to exist, or when deep integration with existing systems is unavoidable. What happens more often in practice is a hybrid: keep the packaged product for the core ledger and build the parts that do not fit as separate custom modules connected by an interface. That spreads the risk and avoids rebuilding everything for the sake of one or two unusual requirements.

Can we change vendors halfway through a rollout?

You can, but the cost depends on what you are actually holding. What can be carried to a new vendor is the process documentation, the master data, and the scope definitions already signed off. If those live only in the outgoing project manager's head, changing vendors means starting again. That is why documents and data should be contracted to arrive with each phase rather than at the end. Before deciding, separate the two possible causes: is the vendor short on capability, or do your own requirements keep moving? A new vendor does not fix the second one. If you do switch, cut a clean stopping point — close out and accept the finished modules, export and archive the data, keep the old system read-only for lookups — and let the new vendor pick up from the next module, rather than handing over something half-built.

ERP for SMBs: Packaged, Cloud, or Custom

“Is it time for us to put in an ERP?” The question usually is not really about wanting new software. It is that the owner has had enough of certain situations: month-end close takes a week, finding out where an order stands requires three phone calls, and the same record exists in different versions in different departments.

The concept behind ERP is simple enough: collapse the data scattered across departments onto one set of master records and one flow, so that everyone is looking at the same thing. The hard part has never been the software. It is getting an entire company to change how it works.

What follows covers when a company genuinely needs one, how packaged, cloud, and custom options compare, why rollouts most often fail, and what has to come from the owner’s side.

What an ERP actually solves

ERP stands for enterprise resource planning, which sounds abstract. In plain terms it means a piece of data gets entered once and every step afterward uses that same copy.

Picture a customer order. Sales takes it, the warehouse needs to know what to ship, purchasing needs to know what is missing, accounting needs to know what to collect, and the owner wants to know whether the order made money. If those four things each maintain their own record, that is four chances to be wrong, and the errors are hard to spot.

The value of an ERP lies in eliminating that duplicate entry and version drift. It typically spans inventory, financial accounting, purchasing, and receivables and payables, extending at larger scale into production scheduling, cost analysis, and human resources.

One caution, though: an ERP does not make a company efficient by itself. It fixes the existing process in place. If the current process is unsound, adopting a system mostly makes the unsound parts harder to change.

When a company genuinely needs one

Neither headcount nor revenue is a good criterion. The question to ask is whether data needs to flow across departments.

Situations where a full ERP is not yet warranted:

Departments coordinate through files or messages, and not very often.
The pain is concentrated in one place — inventory is a mess but everything else is fine.
The process is still changing quickly and could look very different within a year.

In these cases, doing one thing well is usually the better investment: get inventory management right on its own, or build an internal admin system, and revisit integration once the process settles.

Signals that ERP deserves serious evaluation:

The same transaction has to be entered in three or more places.
There is a standing overtime session for manual reconciliation before each month-end close.
A manager asks for a number and nobody can answer without going away to compile it.
Two or more systems are already in place and people move data between them by hand.
An audit or a customer inspection asks for a complete process record you cannot produce.

Packaged, cloud subscription, and custom: the trade-offs

Each of the three suits a different situation, and the difference is more than time to deploy.

Packaged ERP. It comes with a complete set of processes validated over years of practice. The upside is speed, an established set of good defaults, and the ease of finding someone who already knows the product. The price is that your process has to adapt to it rather than the other way around. For most smaller companies that is a hidden benefit: being forced to standardize tends to be healthier than preserving a pile of special cases.

Cloud subscription. No servers to maintain, updates handled by the vendor, and a low barrier to starting. Watch the freedom you have to export your data, the ceiling on customization, and whether you could take everything with you intact if you later needed to move.

Custom development. Suited to cases where the operating process is the competitive advantage, where the industry is too niche for a workable product, or where deep coupling with existing systems is mandatory. It offers the most flexibility, but it also means you have to define the process specification clearly yourself, and the quality of the requirements document determines the result directly. Structure it the way How to Write Software Requirements sets out.

In practice the hybrid is most common. Keep the packaged product for the core ledger, build the parts that do not fit as separate custom modules, and connect the two with an interface. The risk is spread, the work can be phased, and there is no need to rebuild everything for one or two unusual requirements. For how to plan that connection, see A Guide to System Integration and API Development.

Why rollouts most often fail

When a rollout goes wrong, it is almost never a defect in the software. It is one of these:

Starting without mapping the process. Moving the current mess into a system unchanged produces a system that faithfully executes the mess, with an extra layer of data entry on top. A rollout needs a process-mapping phase, which is also the chance to cut the steps that should not exist.

Master data was never unified. A customer name spelled three ways, one item with two codes, duplicate supplier records. If the master data is dirty, every report downstream is wrong, and cleaning it is manual labor that only gets more painful the longer it waits.

No internal owner with authority. Decisions about how a process should run come up constantly. They are management judgments, and a vendor has no standing to make them for you. Time spent stuck on a decision converts directly into project delay, and that is one of the most common root causes behind software projects running late.

Treating go-live as the finish line. The real test comes in the three months afterward: staff hit an exception, do not know how to handle it, and revert to the old way, and the side spreadsheets and group messages grow back.

Too much customization. Every “our company is a bit different” adds to the burden of future upgrades and maintenance. The only things worth customizing are the ones that genuinely differentiate you; elsewhere it is the process that should adapt. The accumulation logic here is identical to technical debt.

What owners and the internal team must commit

This is the part most consistently underestimated. Adopting an ERP is not outsourcing a task; it is redefining how the company operates. An outside vendor can assist but cannot substitute.

One project lead with decision-making authority. Someone who can settle how a process runs, whether a special case survives, and which module goes first. That person does not need to be technical, but they do need to understand how the business works and to have their word carry.

One hands-on contact per module. Warehouse staff, accounting clerks, and sales assistants know every exception, and exceptions are precisely what a specification misses. A system built from manager interviews alone is one the front line will not use.

Count the participation as workload. If none of these people’s existing duties are lifted and they can only contribute in fragments, the schedule will inevitably stretch.

Readiness to change the process. A rollout always surfaces practices that are historical leftovers with no remaining purpose. Whether the organization holds the line on those changes decides whether the rollout succeeds.

Phased rollout: which module first

Going live with everything at once is not advisable. The principle for phasing is start where the pain is clearest and the data most foundational.

The usual order:

Master data cleanup: customers, suppliers, items, chart of accounts. Until this is done, nothing else should be rushed.
Inventory and order flow: the most immediately noticeable change, and the source of the financial figures that follow.
Receivables, payables, and finance: connected only once the transaction data is already accurate, otherwise you are just carrying errors into the books.
Reporting and analysis: meaningful only once the data is complete. Built too early, it produces charts that are attractive and wrong.
External integrations: website, e-commerce, POS, and e-invoicing one at a time, verifying after each.

Each phase needs an explicit definition of done and an acceptance method, rather than a vague promise to “do part of it first.” For how to structure a phased contract, look at the hybrid approach in Fixed Price or Agile.

Acceptance and cutover

Accepting an ERP cannot be a matter of clicking through features. The question is whether the books close: take a handful of real transactions from invoice issuance through payment application and cost recognition, all the way to the month-end reports, and check that both sides balance and that every figure on a report can be traced back to a source document. Manufacture the exceptions deliberately — allowances, cross-period adjustments, prepayments and suspense receipts, a correction after something was applied to the wrong account — because those are where things actually break. How to verify the inventory and document-flow layer (stock states, partial receipts, inter-warehouse transfers) is covered in more detail in Inventory Management System Development. For how to organize acceptance, see How Software Acceptance Works.

There are two ways to cut over. Parallel running keeps both systems going for a short period so the two can be compared; it is safer but laborious. A clean break picks a closing date and switches; it is easier but concentrates the risk. A common approach is a quiet season and the start of an accounting period, with the old system kept read-only for a while for lookups — though accounting-period conventions differ from company to company, so let your own closing cycle set the actual date.

Either way, write the fallback plan in advance: if a serious problem appears in the first week, you need to be able to return to the old way rather than push through on willpower.

One last thing worth saying plainly: an ERP rollout is fundamentally a management project, and the software is only the vehicle. What decides the outcome is whether the company is willing to use the occasion to rethink how it works. If the intention is simply to swap in newer software while everything else stays as it was, the effort invested rarely returns anything proportionate.

Whether to start with a single system or adopt a full suite depends on what your process looks like, not on how many people you employ — which is why the current state has to be laid out first. Talk to NETVANA about your project. We have no fixed packages; software services are quoted on inquiry, and we clarify the process mapping and the integration scope before discussing how a rollout would be phased. What each service includes and delivers is listed in the software services overview.

Further reading: if you only want to fix one part rather than adopt a suite, start with Inventory Management System Development. If you are unsure whether to adopt a full suite at all, see A Guide to Building Internal Admin Systems. To connect several systems together, read A Guide to System Integration and API Development. For whether an old system should be patched, replaced, or rewritten, see Legacy System Modernization. For how to structure a phased contract, see Fixed Price or Agile. And for the questions to ask when choosing a vendor, see How to Choose a Software Development Company.