When should a growing business move to SAP Business One?

There is no revenue figure or headcount at which a business should move to an ERP system, although you will find plenty of articles offering one. The threshold is about how much manual effort is being spent holding the current arrangement together, and that varies enormously between two businesses of identical size.

What follows is how we assess it, including the reasons we would tell you to wait.

The signals that genuinely indicate readiness

None of these on its own is decisive. Three or four together usually are.

Somebody re-keys data between systems as part of their daily routine

Orders arrive in one place, stock lives in another, and a person moves data between them every morning before anything else can happen. This is the clearest signal there is, because it has a measurable cost, it scales linearly with growth, and it is where a large proportion of your data errors originate.

Count the hours. If it is a couple a week, it is an irritation. If it is a person’s morning, every morning, it is a business case.

The month-end close is getting longer, not shorter

Growing businesses should see the close stabilise as processes mature. If it is lengthening as volume rises, the close is scaling with transactions rather than with process — which means it is being done by hand somewhere, and it will keep getting worse.

Your stock position is a matter of opinion

If the answer to “how much of this do we have” depends on who you ask, and if the stock valuation and the ledger disagree by an amount nobody can explain quickly, you have passed the point at which accounting software plus spreadsheets is adequate. This one gets expensive quietly: it shows up as over-ordering, as stockouts, and eventually as an audit problem.

Reporting depends on one person and one workbook

There is a spreadsheet. It has been extended for years. One person understands it, reporting does not happen while they are away, and everybody has quietly agreed not to think about what happens if they leave. That workbook is doing the job of an ERP system, without version control, audit trail or access permissions.

You cannot answer margin questions at the level you manage the business

You know your overall gross margin. You cannot reliably say which customers, product lines or sites are making money, so decisions about them are being made on instinct. This is usually a reporting-structure problem rather than a software problem — but by the time it is entrenched, fixing the structure and changing the system tend to be the same project.

The finance team has grown to keep up with volume

If headcount in finance has risen roughly in step with transaction volume, the process is not scaling and each additional pound of revenue is carrying an avoidable cost.

Something is coming that the current setup will not survive

An acquisition, a second entity, a new territory, a major customer with EDI requirements, a move into manufacturing. It is much cheaper to implement before the event than during it — and businesses that wait almost always underestimate how much of the project will land in the same quarter as the thing that forced it.

Reasons that look convincing but are not

• Revenue has passed some round number. Turnover is not a proxy for operational complexity. A ten-million-pound business with two products and forty customers may be perfectly well served by accounting software; a three-million-pound business with batch traceability and four sales channels may not.
• A competitor has one. You do not know whether theirs is working.
• The board wants better reporting. Frequently a chart of accounts problem, and sometimes solvable in a fortnight without changing system at all. Establish which before committing to a project.
• Your current software has an irritating limitation. One limitation is not a business case. Six interlocking ones might be.
• An investor or acquirer expects to see it. Occasionally a genuine requirement, but ask what they actually need — usually it is reliable, auditable numbers, and there is more than one route to those.

Signs you are not ready yet

These matter as much as the readiness signals, and they are why we sometimes tell people to wait.

Nobody has time to be involved

This is the single strongest predictor of a disappointing implementation. An ERP project needs your finance lead and one person from each operational area in workshops, cleansing data, testing and training. If those people genuinely cannot be freed up, the project will go live and underdeliver, and you will have spent the money to get there. Better to wait a quarter and do it properly.

Your processes are genuinely undecided

If two depots do the same job in two different ways and nobody has authority to say which is correct, an ERP implementation will surface that on day one and stall. The system will force a decision; it cannot make one. Settle the important ones first.

Your data is in poor condition and nobody will own fixing it

Duplicate customers, obsolete items, addresses nobody has checked in a decade. Migration is the right moment to deal with this, but the cleansing decisions have to be made by people who know the business. We can identify duplicates; only you can say which of two similar customer records is the real one.

You want the new system to work exactly like the old one

Some of your processes exist because your current software cannot do something better. Replicating those faithfully in a new system means paying for capability and then configuring it away. If there is no appetite to change anything, the honest advice is to keep what you have.

What it actually costs you, beyond the invoice

The part most businesses underestimate is their own time. For a single-company distribution business, a typical implementation runs three to four months from first workshop to go-live, with the first month-end close about four weeks after that. Across that period, expect:

• Your finance lead materially involved throughout — design workshops, reconciliation of migrated balances, and the first close.
• One person from each operational area in workshops and user acceptance testing.
• A real block of time for data cleansing, which is best started in the old system before the project begins.
• Testing done by your people, on a copy of your own data, including the awkward cases.

Manufacturing, multiple companies, multiple currencies or significant integration extend all of this. Anybody quoting a fixed duration before understanding your processes is guessing.

If you are close but not ready

There is useful work available that is not a full implementation, and it makes the eventual project cheaper and shorter:

1. Start cleansing master data now, in your current system. It is the longest-lead item in any migration and it does not need the new system to exist.
2. Write down what your management pack has to produce, at the level of analysis the board actually wants. This becomes the input to chart of accounts design later, and it is the single most valuable document you can take into a selection process.
3. Walk a month-end and list every manual step, workbook and reconciliation. Attach hours to each. That list is both your business case and your requirements document.
4. Settle the process disagreements that you already know about. Do not leave them for the implementation to surface.
5. Decide who from your side will own the project. Not sponsor it — own it, with the time freed to do it.

None of that requires a supplier, and all of it is useful even if you decide to stay where you are for another two years.

Where to go next

• SAP Business One Implementation — What an implementation actually involves, stage by stage, and how long each part takes.
• Data Migration — Why the data is the risky part, and how balances get reconciled and signed off.
• SAP B1 vs Business Central — If you have decided to move but not decided what to, start here.