There is a size at which a manufacturing business stops being run and starts being reconstructed. Nobody knows today's stock without walking the floor. The costing sheet is a spreadsheet three people edit and one person trusts. A customer asks when their order ships and the answer takes two phone calls.
That is the point at which ERP enters the conversation, usually via a vendor demonstration that looks wonderful and a quotation that looks alarming.
The uncomfortable part is that most ERP failures are not software failures. They are failures of preparation, and the preparation is entirely within your control and costs very little.
The short version
- The trigger is not size, it is reconciliation. When more than a few hours a week go on making numbers agree, you have outgrown spreadsheets.
- Master data is the project. Item codes, units, bills of material, supplier records. If these are wrong, no system saves you, and cleaning them is most of the work.
- Never go live with everything at once. Inventory first, then production, then purchasing, then sales, then finance.
- The costs people omit are the large ones: data migration, training, and running in parallel with the old way for a period.
- Customise as little as possible. Every customisation is something you own forever, and the standard process is usually better than the one you invented.
Five signals you have outgrown spreadsheets
- Two people quote different stock figures for the same item, and both are working from a file.
- Costing a job takes hours, and the answer is a best estimate rather than a fact.
- You discover shortages at production time, not at planning time.
- Month end takes more than a few days, and most of it is reconciliation rather than analysis.
- One person is the system. If they are away, decisions wait.
None of these is about turnover. A focused business can run on spreadsheets longer than people expect, and a chaotic one needs a system sooner. The test is how much of your week goes on making numbers agree instead of acting on them.
What ERP actually is
Strip away the vendor language and an ERP is one thing: a single record of what you have, what you owe, what is owed to you, and what is in progress, that everyone works from instead of from their own file.
That is the whole value. Every feature is in service of it. Which is why the project succeeds or fails on whether people actually use it as the single record, and not on which product you chose.
What this should change: stop comparing feature lists. Start by asking which system your team will realistically keep up to date every day, because an ERP nobody updates is worse than the spreadsheets it replaced, and considerably more expensive.
Why these projects fail
Master data was never cleaned. Duplicate item codes, three units of measure for the same thing, bills of material that do not match what the floor actually does. Migrating this into a new system produces confident, precise, wrong answers.
The process was never written down. You cannot configure a system to match a process that exists only as habit, and you will discover mid-project that three people do the same job three different ways. This is the same prerequisite we describe in the first ten SOPs every growing business needs, and it is the cheapest part of the project to get right.
No internal owner. A consultant cannot own your ERP. Someone inside the business must, with the authority to decide how a process will work, and the time to do it. If nobody has that time, the project will fail regardless of budget.
Big-bang go-live. Every module, every site, one weekend. When something breaks, and something always breaks, you cannot tell which change caused it, and the business is stopped while you find out.
Over-customisation. Every customisation is code you own, that must be retested at every upgrade, and that only one person understands. The default should be to change your process to match the system. The exception is where the process is genuinely your advantage, which is the same test as in build or buy.
The module order
Do not buy everything on day one, whatever the discount for bundling.
| Order | Module | What it fixes | Add it when |
|---|---|---|---|
| 1 | Inventory and warehouse | Nobody knows what stock exists | Always first. Everything else depends on it |
| 2 | Production and bills of material | Costing is guesswork, shortages surprise you | Once stock data is trusted |
| 3 | Purchasing | Buying is reactive, suppliers are managed by memory | Once you can see what production will need |
| 4 | Sales and dispatch | Order status requires phone calls | Once stock and production are reliable |
| 5 | Finance and costing | Month end is reconstruction | Last. It is only as good as everything above it |
| 6 | Quality, maintenance, HR | Genuine but secondary gains | Once the core is stable for a full quarter |
The reason inventory comes first is arithmetic. Every other module's numbers are derived from stock. Put finance in first and you get beautifully formatted reports built on figures nobody believes.
The Pakistan-specific considerations
Provincial sales tax. Services are taxed provincially, and your obligations differ by where you are registered. Any system must handle the tax treatment that actually applies to you. Confirm the current position with FBR and the relevant provincial authority rather than assuming the software's defaults fit.
Multi-currency, if you export. Sales in dollars, costs in rupees, and a conversion that has to be recorded at the right rate on the right date. Get this configured properly at the start. The export documentation and payment side is in exporting goods from Pakistan.
Cash transactions. Many Pakistani manufacturers still have cash-based supplier and sales flows. A system that assumes everything is banked will be worked around within a month, and workarounds are how single sources of truth die. Configure for how you actually trade, then formalise deliberately. The argument for doing so is in Raast and the end of the cash-only business.
Power and connectivity. If the plant loses power or connectivity regularly, a cloud-only system with no offline tolerance will fail at exactly the wrong moment. Ask the vendor directly what happens during an outage and test it before go-live rather than after.
Floor literacy with systems. Your supervisors may be excellent at their jobs and unused to software. Scanning and simple screens beat elegant interfaces. If data entry is hard, it will not happen, and then nothing else works.
A realistic ninety-day plan
| Weeks | Focus |
|---|---|
| 1 to 3 | Write down the current process, honestly, including the workarounds. Name the internal owner and free up their time |
| 4 to 7 | Clean master data: item codes, units, bills of material, suppliers, customers. This is the real project |
| 8 to 9 | Configure inventory only. Train the people who will use it daily |
| 10 to 12 | Run inventory live, in parallel with the old method, and reconcile daily until they agree |
| 13 | Stop the parallel run. Only then plan the next module |
Three months for one module sounds slow and is the fastest reliable route. Businesses that compress this are the ones still fighting the system a year later.
The costs nobody budgets
- Data cleaning and migration. Frequently the largest line, and almost always omitted from the quotation.
- Training, including retraining after people leave. Attrition does not pause for your project.
- Parallel running. For a period you are doing the work twice. That is the insurance premium, and skipping it is how businesses lose visibility during go-live.
- Your own people's time. The internal owner is not doing their normal job during this. Plan for the gap rather than pretending it away.
- The second year. Support, upgrades, changes. Ask for the five-year cost, not the licence price.
Frequently asked questions
When does a manufacturer need an ERP system?
When reconciliation starts consuming management time: different stock figures from different people, costing that takes hours, shortages discovered at production time, and a month end that is reconstruction rather than review. Turnover matters less than how much of your week goes on making numbers agree.
Should we buy an ERP or build our own?
Buy, in almost every case. ERP is a solved, heavily regulated, deeply detailed problem and no manufacturer's requirement is unusual enough to justify building one. Custom development belongs around the edges: integrations, a customer portal, reporting the standard product will not produce.
How long does an ERP implementation take?
Plan roughly three months per module, done properly, starting with inventory. Anyone promising a full multi-module implementation in weeks is describing an installation, not an implementation.
What is the most common reason ERP projects fail?
Dirty master data, followed closely by a process that was never documented and a go-live that attempted everything at once. The software is rarely the problem.
Do we need internet at the plant for ERP?
For a cloud system, yes, and you should plan for outages rather than hope. Ask the vendor what happens offline, test it before go-live, and have a second connectivity route if production decisions depend on the system.
Where to go next
If the honest blocker is that the process is not documented and the data is not clean, that is the project, and it is what business operations consulting does before any software is chosen. For the integrations and reporting around a standard ERP, that is custom software development. Our sector view is under manufacturing and logistics and supply chain. Tell us what your month end looks like.
