Why Generic ERP Gets Abandoned in Family-Owned Businesses
The system is rarely rejected because it is wrong. It is rejected because using it correctly requires an approval chain that does not exist, so people route around it and the data becomes untrustworthy within a quarter.
A family-owned trading or manufacturing business buys an ERP, spends the implementation budget, and eighteen months later the real work is still happening in spreadsheets. The usual explanation is "the staff did not adopt it" or "the system was too complex". Neither is quite right. What usually happened is that the software encoded an organisational model the business does not have.
The software assumes a decision structure
Standard ERP is built around roles: a purchase requisition is raised by a buyer, approved by a purchasing manager, checked against budget by finance, and released. Every step has a permission and a queue. That model is a reasonable description of a company where authority is delegated by position.
In a family business of thirty to two hundred people, authority is often not delegated by position. It is concentrated, informal and situational: the person who has done the job for twenty years approves because they know the supplier, not because they hold the title. A system that requires a formal approval step will either be bypassed or will generate a queue of approvals waiting for someone who is not logged in.
Three patterns that break a standard rollout
Pattern one: the owner is the approval engine
Every purchase above a threshold routes to one person, usually on a phone, often verbally. When the system enforces a two-step approval in software, the second step never happens because the decision was already made in a corridor. The data then records something that did not happen, which is worse than no record at all.
The workable design is not to remove the approval, it is to let the system record a decision made elsewhere: a single confirmed action with the person named, timestamped, and a visible flag for anything approved outside the normal path. Formal process can be layered on later; an unrecorded process cannot be recovered.
Pattern two: the same person holds three roles
In a smaller business the warehouse manager may also be the buyer and the person who reconciles the supplier invoice. Separation-of-duties controls from enterprise software assume distinct people; enforcing them here means one person cannot complete their own work, and they will find a workaround. The right response is a lighter control: one operator, full audit trail, and a periodic review of exceptions, rather than a hard block that gets defeated.
Pattern three: the real reporting is a spreadsheet that predates the system
There is often a monthly file — receivables ageing, margin by customer, stock by location — maintained by hand for years. It is the number management trusts. Replacing it with a system report that uses slightly different definitions guarantees the system report will be ignored. The rollout works better if the existing report is rebuilt inside the system first, with the same columns and the same definitions, and only then improved.
If the official report and the trusted report disagree, the system loses. Match the trusted report first, then change its definitions deliberately.
Designing around how approvals actually happen
- Start by writing down three real transactions from last month, step by step, including the steps that happened verbally.
- Map each step to a system action, and mark the ones that will not happen inside the software.
- For those, design a single confirmed action with a named operator and a visible exception flag — not a fake approval chain.
- Add a weekly exception review rather than a hard block, so control exists without breaking the workflow.
- Only formalise approvals where the cost of an error is genuinely high: credit limits, price overrides, write-offs.
Succession: making the system survive the handover
A family business has a specific structural risk that generic ERP does not address: the knowledge of how the business runs often lives in one or two people. If the system depends on their judgement rather than recording it, the next generation inherits a black box.
This is a design requirement, not a documentation task added at the end. Concretely: pricing rules written as rules rather than applied manually; customer credit terms stored against the customer rather than remembered; supplier lead times recorded from actual receipts rather than estimated. Each of these turns tacit knowledge into an operating parameter that a successor can read.
| Tacit knowledge | What it looks like in a system |
|---|---|
| "This customer always pays late but never defaults" | A credit term and a payment pattern recorded against the customer record |
| "We quote this product lower for this region" | A price rule with a region condition, visible and editable |
| "This supplier takes about three weeks" | Lead time calculated from receipt history, not typed once |
| "That order has to go out today" | A priority flag with a reason field, so the exception is visible rather than verbal |
A staged scope that holds
- Stage one: orders, stock and receivables — the three things that must be right every week.
- Stage two: the trusted monthly report, rebuilt inside the system with the same definitions.
- Stage three: pricing rules and credit limits, moved from memory into configuration.
- Stage four: purchasing and production planning, once the base data is trustworthy.
Each stage has an acceptance test the business can verify without a consultant, which is the point: if the people who run the business cannot check the result, they will not trust it, and an untrusted system is a spreadsheet with extra steps.
Questions we are asked
Should we customise an existing ERP or build our own?
Customisation is the right answer when the gap is in reporting and a few workflow steps. A separate build makes sense when the core operating model — how stock, pricing or approvals actually work — does not fit the package, because at that point customisation becomes a fork you have to maintain forever.
How do we get staff to actually use it?
By making the system the shortest path to getting their work done, not the compliant path. If entering an order in the system takes more steps than the spreadsheet, the spreadsheet wins. The first release should remove work rather than add a parallel record.
What about the data in our existing spreadsheets?
The master data — customers, products, prices, opening balances — is imported and reconciled during the build. Historical transactions are usually kept as an export rather than migrated, because old structures rarely map cleanly onto a new model.
