Every rollout we have delivered in the Kingdom has had the same pressure behind it. The business cannot stop. Invoices still go out, stock still moves, payroll still runs on the 27th. The question is never how to build the perfect system, it is how to change the engine without stopping the car.
Start with one process that genuinely hurts
The instinct is to scope everything at once: finance, inventory, sales, HR, projects, production. It feels efficient. In practice it means a long build with nothing to show for months, and by the time anything reaches a user the original sponsors have moved on.
Pick the process that costs you the most today. For a trading business that is usually stock accuracy and landed cost. For a contractor it is project cost against budget. Fix that first, in a phase short enough that people still remember why it started.
A first phase that solves one real problem earns the goodwill the rest of the project runs on. A first phase that solves everything slightly rarely gets a second.
A phased rollout at a glance
Durations below are typical for a mid-sized Saudi business with two to five branches. They move with data quality and how quickly decisions get made, not with the software.
| Phase | What actually happens | Who owns it | Typical duration |
|---|---|---|---|
| Discovery | Process mapping with the people who do the work, not only managers | Consultant + process owners | 2 - 3 weeks |
| Scope & design | Phase-one scope agreed in writing, including what is deliberately excluded | Consultant + sponsor | 1 - 2 weeks |
| Configuration | Chart of accounts, warehouses, approval chains, documents, reports | Implementation team | 3 - 6 weeks |
| Data migration | Masters and opening balances loaded, then reconciled line by line | Finance + consultant | 2 - 4 weeks |
| UAT | Each role tests its own daily screens against real documents | Named users per role | 2 weeks |
| Training | Short sessions per role, in Arabic or English, using your own data | Consultant | 1 week |
| Go-live & support | Cutover, then dedicated support while question volume peaks | Everyone | 4 weeks |
Clean the data before you migrate it
This is the step everyone underestimates. Duplicate customers, dead item codes, three spellings of the same supplier, opening balances nobody can explain. All of it is cheaper to fix in a spreadsheet than in a live system.
| Data set | What usually goes wrong | Decide before go-live |
|---|---|---|
| Customers | The same company exists three times with different spellings and credit limits | Who owns the master list afterwards |
| Items | Codes that have not moved in years still carry stock value | What gets retired rather than migrated |
| Suppliers | Payment terms live in people's memory, not the record | Terms and tax treatment per supplier |
| Opening balances | Trial balance does not tie to the sub-ledgers | Cut-off date, signed off by finance |
| History | Everyone asks for all of it and nobody uses most of it | How many years you genuinely need |
Configure the approval chain you really use
Ask how a purchase gets approved and you will be told the policy. Watch what happens and you will see the practice: a message to the GM, a signature collected later. If you configure the policy and ignore the practice, people will work around the system within a fortnight.
Model the real chain first, including the delegation that happens when someone travels. Tighten it afterwards, once the system is where the work already happens.
The question worth asking early
Who owns this system after go-live? Not the vendor, not the project manager, but the person inside your business who will approve changes and answer questions in month six. Rollouts without that person drift.
Run finance in parallel for one period
For finance especially, one month run twice is cheaper than a quarter of doubt. Parallel running is tedious and everyone resents it, and it is still the single most effective way to find the configuration gap that would otherwise surface during your first statutory close.
Train by role, not by module
A storekeeper does not need a tour of the general ledger. Give each role the four or five screens they will use daily, in their own language, using your own data rather than demo records. Sessions get shorter and adoption gets better.
Budget for the month after go-live
Questions peak in the four weeks after launch, which is exactly when most projects declare success and release the team. Keep support capacity in the plan for that period. It is the difference between a system people trust and a system people tolerate.
None of this is exotic. It is the order that keeps a business running while its systems change underneath it, and the projects that skip steps are the ones that end up doing them anyway, later and more expensively.
