ERP Rescue Consultant, Iraq

How Iraqi ERP projects stall

The general causes of failing ERP projects apply in Iraq too: thin requirements, an early fixed date and too little time from the client side. Several local patterns tend to make matters worse.

• Head office first, sites never. The ledger goes live in Baghdad or Erbil, but site rollout keeps slipping, so the system never holds the cost data it was bought for.
• Connectivity learned the hard way. Screens time out at camps and yards, and staff return to paper after a few frustrating days.
• Partners at a distance. A partner delivering from abroad can work well, but when visits become rare and the client side lacks one decision-maker, questions wait for weeks.
• Cash never designed in. Advances, petty cash and partial cash payments to subcontractors were never built into the system, so balances drift.
• Entities blurred. Companies in federal Iraq and the Kurdistan Region were configured too similarly, and local accountants cannot get the reports they need.

None of these proves the platform or partner was the wrong choice. A rescue starts by establishing which patterns apply, with evidence. If the system is stable and simply underused, the ERP audit consultant page for Iraq describes a lighter first step.

Keeping each entity's books steady during the rescue

While the project is repaired, every company in the group still has to pay suppliers, bill clients, report to partners and close its books. Those obligations come before any discussion of fault.

I start with a short triage for each entity and each active site. What stops purchases, receipts, subcontractor certificates, client invoices or month-end today? Each blocking item gets an owner, either in your team or with the partner, and a target date. Problems that are irritating but not blocking go on a separate list.

Then I meet each entity's local accountant, remotely, to agree how the next month-end and any statutory filings will be supported. We decide which figures they will rely on, which corrections must go in first and how the ledger will be reconciled with bank, cash and supplier records. Tax and statutory questions remain theirs alone; what I contribute is a ledger they can actually rely on.

Sites that cannot yet use the system receive a written interim procedure: which forms to complete, who collects them, how often they reach head office and who enters them. Each routine has an owner and an end date. Without that discipline, the paper backlog grows faster than anyone can clear it.

Clearing site backlogs and correcting balances

A stalled Iraqi rollout tends to leave a pile of unentered records: goods receipts, material issues, timesheets, advance settlements and subcontractor measurements, on paper or in site spreadsheets. Until they are in the system, project costs and supplier balances cannot be trusted.

I sort the backlog by site, age and value, agree with finance which records must be entered in full and which can be summarized for older periods, and name an owner for each batch. Entry runs to a schedule, with a check after each batch that project costs and stock movements look plausible.

Balances then get corrected in rounds:

• Project cost to date, invoiced to date and retention receivable, agreed with each project manager.
• Subcontractor positions, including retention held and advances paid, by currency.
• Open advances to site staff, each confirmed with the person holding it.
• Stock at each site and warehouse, counted and valued under finance's method.

Corrections are posted through approved journals and stock adjustments, never by editing the database, and every round is balanced before the following one starts. The evidence is kept so auditors and partners can follow what changed. The ERP data migration and project costing pages cover the underlying methods.

Assessing the partner and securing control

Owners may be hearing two versions of events. The partner points to late decisions and changing requirements; your managers point to a system that does not work at sites. A rescue needs a factual account both can recognize.

I interview owners, finance, project managers, storekeepers and the partner's team separately. I read the proposal, contract scope, design notes, change approvals and test evidence, then run real flows in the system, including on the slow connections your sites actually use. Out of this comes a written status: each scope item marked as done, half done, absent or contested, with neutral notes on why.

Control deserves its own check. Some partners host the system themselves, holds the only administrator accounts and keeps custom code on its own servers. That may be fine while the relationship works, but it leaves you exposed if it does not. I confirm whether your company holds administrator and hosting credentials, recent backups that have been test-restored, access to source code for customizations and documentation another team could follow.

I also look at capacity: who on the partner's side can support sites in each region, who delivers Arabic and Kurdish training, and whether named people are still assigned. More on this kind of assessment sits on the independent second opinion page.

Choosing a path and restarting site by site

With books steady and facts written down, owners can choose calmly. Four routes are usually open, each with different costs and compromises:

• Carry on with the existing partner under a reset scope, a site-by-site plan and stronger client-side governance.
• Re-scope to stabilize finance, purchasing and stock at head office and the main warehouse before adding project sites in waves.
• Change partner on the same platform, which depends on a clean handover of code, documentation, hosting and credentials.
• Re-platform, reserved for cases where testing proves the product cannot cope with your sites' conditions or your entity structure.

Contract questions go to your lawyer before any partner change or dispute. I prepare a factual summary and point to the relevant terms, such as acceptance, payment stages, hosting arrangements, ownership of custom work and exit assistance, but legal advice stays with them.

The restart itself runs site by site. Each site goes live only after its key users are trained, its opening positions are agreed and an offline procedure has been tested on its real connection. Hypercare follows each switch. The rescue ends when agreed criteria are met, typically every planned site posting live and a clean month-end per entity. See ERP recovery, the Iraq implementation consultant page and the Iraq hub.