Why the Same ERP Succeeds in One Company and Stalls in Another
Two distributors of similar size buy the same ERP from the same vendor. The first is running accounting, inventory and sales on it within four months, and a year later nobody in the company quotes a figure from anywhere else. The second spends a year on modifications, its staff drift back to spreadsheets "for now", and the board starts asking whether the project was a mistake. The software is identical. The implementation is not.
An ERP rollout is not a software installation. It changes how purchase requests are approved, who owns item data, when the month closes and who answers for each number. That is why the factors that decide success are spread across leadership, planning, data, people, testing and post-launch support. This guide walks through each one with practical steps, a sample timeline for a mid-sized company, a realistic budget, and the measures that tell you whether the project actually worked.
1. An Executive Sponsor Who Can Make Decisions
Every ERP project reaches a moment of disagreement. Sales wants to invoice before credit approval and finance refuses. The warehouse wants to edit quantities and internal audit objects. Without a senior person who can settle these disputes, each one costs weeks.
A real sponsor does more than sign the contract. They:
- Attend the steering committee at least every two weeks.
- Resolve cross-department conflicts in days, not weeks.
- Announce that the new system is the official source of numbers from a set date, and that work outside it will not be accepted after that.
- Protect the project team's time from being swallowed by daily operations.
2. Measurable Objectives, Set Before Selection
"We want an integrated system" is not an objective. A useful objective is a number with a baseline and a deadline:
| Area | Today (hypothetical) | Target after 12 months |
|---|---|---|
| Month-end close | 12 working days | 5 working days |
| Inventory record accuracy | 88% of SKUs match the count | 97% of SKUs match |
| Delivery to invoice | 3 days | Same day |
| Supplier invoices matched to a PO | 60% | 95% |
| Payroll preparation | 4 days | 1 day |
These targets guide design choices, give you a filter for new requirements, and let management judge the project on evidence rather than impressions. Record the baseline now. Once processes change, you will not be able to reconstruct it.
3. A Written Scope and a Formal Way to Change It
The scope lists the modules, sites, processes, reports and integrations in the project. Anything outside goes onto a backlog for a later phase. Change requests are not the problem; some are valid and important. Accepting them without assessing time and cost is the problem. Keep a change log that records who asked, which objective the change serves, the time and cost impact, and who approved it. Many requests quietly disappear once someone has to answer "which objective does this serve?"
4. An Internal Team With Real Time Allocated
Your vendor knows the software. Your staff know the business. That knowledge only reaches the system if people have time to contribute it. A minimum internal team looks like this:
- Internal project manager: the single point of contact with the vendor, owner of the plan and of open decisions.
- Key user per module: a senior accountant for finance, a warehouse supervisor for inventory, a sales coordinator, an HR officer. They help design and test, then train colleagues.
- Data owner: leads cleansing and migration.
As a working rule, key users should spend at least half their time on the project during design and testing. If that is impossible, either delay the project or bring in temporary cover for part of their day job.
5. Design Processes Before Configuring Screens
Move a disorganized process into a new system and you get a faster disorganized process. Before configuration, map the main flows as they should work: requisition to payment, quote to cash, receipt to issue. For each step, define who starts it, who approves it, which document it produces and which accounting entry follows.
Configure first, customize last
When the system works differently from your current habit, ask whether your way is genuinely better or simply familiar. Modern ERPs handle most reasonable differences through settings: approval levels, document sequences, extra fields. Code changes should be reserved for real competitive differences or legal requirements, because every modification adds maintenance cost and complicates future updates.
6. Clean Data Before Migration
Data is the most underestimated factor. A strong system loaded with poor data produces poor reports on day one, and users lose trust quickly. A sound migration plan has five stages:
- Inventory the data. Usually the chart of accounts, customers, suppliers, items, opening balances, employees and fixed assets. Historical transactions generally stay in the old system for reference.
- Cleanse. Remove duplicates, standardize names, fill missing fields such as customer VAT numbers and national addresses.
- Map. Match old fields to new ones.
- Trial loads. At least two in a test environment, each with balance reconciliation.
- Final load. On the cutover date, with finance signing off the opening balances.
What cleansing looks like in practice (hypothetical)
A distributor's legacy system holds 4,200 items and 1,900 customers. Review shows 900 items with no movement in three years, 350 duplicates under slightly different names, and 600 customers without a VAT number or address. After cleansing, 2,950 items and 1,300 customers move across. The work takes six weeks, and it saves the company from tax invoices with missing buyer data and inventory reports padded with dead lines.
7. Treat Saudi Compliance as Design, Not an Add-On
Some requirements must work from the first day:
- E-invoicing. Phase 1 began on 4 December 2021 and Phase 2 integration has been rolling out in waves since 1 January 2023. Wave 25 covers businesses with turnover above SAR 187,500 in any year from 2022 to 2025, due from 1 February 2027. Confirm your wave and test the ZATCA integration before go-live.
- VAT at 15%. Tax codes on every item and service, and returns monthly or quarterly depending on turnover.
- Payroll. GOSI contributions, the WPS file on Mudad within 30 days, and end-of-service awards under the Labor Law.
Build these into test scenarios. Discovering a gap after launch is far more expensive.
8. Phased Rollout or Big Bang?
| Aspect | Big bang | Phased |
|---|---|---|
| Approach | All modules and sites go live on one date | Modules or sites go live in stages |
| Risk | High: one problem affects everything | Lower: issues stay contained |
| Total duration | Shorter on paper | Longer, but value starts earlier |
| Temporary interfaces | None needed | May need a bridge between old and new |
| Best for | Small, single-site, simple operations | Mid-sized, large or multi-branch companies |
A common phased sequence is accounting and e-invoicing first, then purchasing, inventory and sales, then HR and payroll, then specialist modules such as projects, assets or manufacturing. Aim to cut over at the start of a financial year or quarter so opening balances come from a clean close.
9. Test With Real Scenarios
Creating and saving one invoice proves nothing. User acceptance testing should run complete processes on real data and include awkward cases:
- A PO received in two deliveries, with the invoice arriving at a different price.
- A sales return against last month's invoice, with an electronic credit note.
- An employee who joined mid-month and another who resigned with leave balance outstanding.
- An item bought by the pallet, stored by the carton and sold by the piece.
- A user with limited authority trying to approve above their limit.
Document expected and actual results for each, and do not go live until all critical issues are closed.
10. Role-Based Training and Change Management
Generic screen tours are forgotten within a week. Effective training follows each role's daily work: the storekeeper practices receipts, issues, transfers and counts; the accountant practices journals, reconciliations and the close; sales practices quotes and orders. Back it up with one or two page guides for each process.
Change management starts well before training. People need to know why their work is changing, what they gain and who to ask when something goes wrong. Celebrate early wins, such as the first faster close. Our article on ERP change management and adoption goes deeper.
A Realistic Budget
Projects often overrun not because the vendor raised prices but because the budget only covered subscription and implementation fees. For a hypothetical project quoted at SAR 300,000:
| Item | Estimate (SAR) | Note |
|---|---|---|
| Subscription and implementation | 300,000 | Vendor quote |
| Data cleansing and migration | 40,000 | Staff time or outside help |
| Internal team time | 90,000 | Four people at half time for three months |
| Extra training and internal guides | 20,000 | Beyond the contract scope |
| Hardware: printers, barcode scanners | 25,000 | If needed |
| Contingency at 10% | 47,500 | Approved changes only |
| Total | 522,500 |
Internal time is the line most often left out, yet it is a real cost. Putting it in the budget turns "the team will find time somehow" into a deliberate decision.
Sample Timeline for a Mid-Sized Company
For a hypothetical trading company with 60 users and three branches starting with accounting, inventory, sales and purchasing:
| Weeks | Phase | Key output |
|---|---|---|
| 1 to 3 | Analysis and process design | Signed process document and scope |
| 4 to 7 | Configuration and data cleansing | Configured system and first trial load |
| 8 to 10 | Testing and training | Signed UAT and second trial load |
| 11 | Cutover | Final load and approved opening balances |
| 12 to 16 | Hypercare | First full month-end close in the new system |
Actual duration depends more on data readiness and team availability than on the software. The weeks after launch have their own playbook in our guide to the first 90 days after ERP go-live.
The Cutover Weekend
- Freeze entries in the old system at a fixed time announced to every department.
- Close the period and extract the trial balance, customer, supplier and stock balances.
- Count stock, at least for high-value items, since opening inventory is the hardest balance to get right.
- Load opening balances and reconcile each one to the old trial balance.
- Run one of every key transaction: a cleared e-invoice, a PO, a receipt, a journal.
- Have finance and the sponsor sign the go or no-go decision.
Agree the rollback criterion in advance. For example: if a ZATCA-cleared invoice cannot be issued by the morning of the first working day, go-live moves a week. Deciding this beforehand keeps the call from being made under pressure.
Early Warning Signs
- Steering meetings are cancelled or attended by deputies.
- The list of open decisions grows week after week.
- Key users miss design sessions because of their day jobs.
- The first trial load has not happened by the midpoint.
- Requested customizations far exceed the plan.
None of these means failure, but each is a signal to hold a frank meeting between the sponsor and the vendor and reset the plan. For a structured set of post-launch measures, see our article on ERP implementation KPIs.
Keep Master Data Clean After Go-Live
Cleansing before migration is wasted if the mess returns within two months. The usual cause is that anyone can create a new item or customer. Give each master data type an owner and a few hard rules:
- Items, owned by inventory or purchasing: no item without a unit of measure, category and tax code.
- Customers, owned by credit or finance: VAT number and address mandatory for business customers.
- Suppliers, owned by purchasing with finance approval: a supplier's bank account cannot be changed without a second approver.
- Chart of accounts, owned by the finance manager: no new account without a mapping to a statement line.
The supplier bank rule matters more than it looks. Changing a genuine supplier's bank details just before a payment run is a common fraud pattern, and a second-approver control in the ERP shuts it down.
How Tranquil Supports Implementation
Tranquil is a cloud ERP with modules for financial accounting, ZATCA e-invoicing (Phase 1 and Phase 2), inventory, sales and distribution, purchasing, HR, payroll, projects, contracting, asset management, property management and POS. Services include customization of screens, reports, multi-level approvals and API integrations, plus certified training on-site or remote with role-based tracks and 30 days of post-training support. Most projects start with accounting and finance.
Frequently Asked Questions
How long does an ERP implementation take?
For a mid-sized company starting with core modules, typically three to six months. Data readiness and internal team availability matter more than the size of the system.
What is the single biggest success factor?
There is no single one, but a missing sponsor or an internal team without allocated time explains most stalled projects, because decisions slip and testing gets postponed.
Should we migrate all historical transactions?
Usually not. Move master data and opening balances, possibly the current year's transactions, and keep older history in the legacy system or an archive. Saudi commercial books rules require records to be kept for ten years.
When does a big bang go-live make sense?
For small, single-site companies with simple processes, where building temporary interfaces between two systems would cost more than the extra risk of going live all at once.
How do we start with Tranquil?
Write down your objectives and the modules you need, then contact the Tranquil team for a quote within 24 hours and a proposed implementation plan.

