Skip to content
1961 Digital TransformX
العربية

Service

Go-live is not the finish line. The month after is.

Most ERP projects are declared successful on the day the old system is switched off. We judge ours four weeks later, when finance closes the month inside the system and nobody has reopened a spreadsheet to do it.

Book a consultationAll services

You will recognise this

  • Your last implementation went live over a weekend, and by Wednesday the old spreadsheets were open again on every desk.

  • The system was configured against a demo script, not against what your production supervisor actually does at seven in the morning.

  • Opening balances in the new system never reconciled to the closing ledger of the old one, and nobody was made to chase it.

  • Training was one classroom session for everyone at once, so the people who key transactions daily learned nothing they could use.

  • Month-end still takes a week because finance re-derives by hand every figure the system already holds somewhere inside it.

How the work runs

  1. Map the real process

    We walk the floor, the store and the finance office and write down what happens, including the steps nobody documented and the workaround that keeps production moving. The map records exceptions by name, because exceptions are what break configurations built from a template.

  2. Name the gaps

    Every place the standard product disagrees with your process goes into a register with a decision beside it: change the process, configure around it, or build. Each decision carries a cost and an owner. Nothing moves to configuration while a gap is still an open question.

  3. Configure and migrate

    We configure to the agreed map and migrate master data and balances in controlled passes. Every migration run is reconciled against the old ledger before the next one starts, so an error is caught while it is still one batch rather than a year of history.

  4. Rehearse the close

    Before go-live we run a full period end on real data with your own finance team driving. It finds the missing account mapping, the report that will not foot and the approval that has no route. Rehearsal is where those are cheap to fix.

  5. Hypercare to first close

    We stay through the first full month end, sitting with the people doing the work rather than answering tickets from a distance. The engagement ends when your team closes the period unaided and the numbers agree with the ones we migrated.

What you are handed

  • Process maps for every flow the system will carry
  • Gap register with a decision and an owner per line
  • Migration reconciliation signed against the old closing balances
  • Role-based user guides in Arabic and English
  • Test scripts with their recorded pass results
  • A named owner for every report the board reads

Why implementations fail after go-live

Almost nothing fails during the project. It fails afterwards, quietly, when one department finds the system slower than the old habit and goes back to the habit. Within a quarter the system holds the official record and the spreadsheet holds the truth, and the two drift apart with nobody watching. The cause is nearly always the same: the configuration matched a demonstration rather than the work. A storekeeper who is asked for three fields he cannot know at the moment of receipt will not fill them in. He will post something plausible, or wait, and the stock figure becomes fiction from that day forward.

Migration is an accounting exercise

Data migration is usually treated as a technical task and handed to whoever knows the export format. That is how companies arrive at an opening trial balance nobody can defend. Master data and balances have to be reconciled by someone who understands what the numbers mean, line by line, against the ledger being retired. We migrate in controlled passes and reconcile after each one, because a variance found in a single batch is an afternoon of work and the same variance found six months later is an audit finding. The old system stays readable until the reconciliation is signed.

The measure is the month after

Ask how the project will be judged and most vendors answer with a date. We answer with a period end. Four weeks after go-live, either your finance team closes inside the system on the normal timetable or it does not, and everything else is commentary. That standard changes what we build. It means the reports have to exist before go-live, not after. It means approvals have to run where the work happens rather than in a chat that gets re-typed. And it means we are still in the building when the first real close comes round.

Questions we get asked

How much does an ERP implementation cost?
We will not quote before the diagnosis, because a number given at that stage is a guess dressed as a proposal. What drives cost is the number of genuine gaps between your process and the standard product, the state of the data being migrated, and how many people need training. The diagnosis prices those three things explicitly, and you can take it to another firm.
Can you work with the ERP we already bought?
Usually yes, and often that is the recommendation. A system that fits badly is a cheaper problem than a system that fits and is not adopted. We assess whether the platform can carry your process at reasonable effort. If it can, we fix the implementation rather than replace the software. If it genuinely cannot, we will say so in writing and explain what the replacement costs.
What if our staff refuse to use the new system?
Some will, and it is rarely stubbornness. Resistance almost always marks a place where the design asks someone for information they do not have at that moment. We treat refusal as a design signal and go and watch the task being done. Where the objection is genuinely about habit rather than design, it is a management decision and we say that plainly to the sponsor.
How long until we stop using spreadsheets?
Some spreadsheets should stay. A one-off analysis is a reasonable use of a spreadsheet; a spreadsheet that carries an operational balance month after month is a failure of the system. We identify which is which during mapping, and the ones carrying balances have a named replacement inside the system before go-live. If a replacement does not exist, we do not switch off the file.
Who is accountable if the implementation goes wrong?
We are, for the parts we control, and we write down which parts those are before we start. The most common cause of failure is not technical: it is a sponsor who cannot make a decision about a process that crosses two departments. So the diagnosis names the decisions that will be needed and who must make them. Undecided items are escalated in writing, not absorbed.

Often bought together

Tell us what is not working

Send one line about what is going wrong. On the first call we will tell you whether it is a system problem, a process problem or a governance problem — and which one to fix first. That call is free and it is not a sales meeting.

Book a consultation