ERP Implementation Consultant, Iraq

What derails ERP rollouts across Iraqi sites

The same issues appear on many multi-site projects in Iraq. They are rarely about the software itself, and most are visible early if someone on the client side is looking for them.

• Design done at head office only. Processes are designed with finance and management, then site storekeepers and engineers receive a system that does not match how materials, timesheets and cash actually move.
• Connectivity discovered at go-live. The system was tested in an office with good internet; at the camp or yard, screens time out and staff return to paper.
• Cash outside the design. Advances, petty cash and subcontractor payments are handled informally, so project costs in the ERP never agree with what was actually spent.
• One big switch. Every entity and site goes live on the same day, and the partner's small team cannot support them all at once.
• Partner team thinning out. The consultants who led design return to another country, and support passes to someone who was not involved.

None of these require a different platform. They need a client-side owner who plans for them. If a project is already struggling, see my ERP recovery service.

Holding a remote or regional partner to the plan

Many partners serving Iraq deliver partly from Jordan, the Gulf or Turkey, with consultants visiting for workshops and go-live. That can work very well, as long as the client side is organized enough to keep decisions moving between visits.

I hold the requirements baseline agreed during selection or business analysis. Partner design papers are compared with that baseline, explained to the manager and a site representative who will live with them, then approved or sent back with questions in writing. During build, I ask the partner to demonstrate configuration on your own scenarios, such as a subcontractor certificate with retention or a goods receipt at a remote store, rather than describe it in a report.

Every change request is logged with the business reason, the partner's estimate and the effect on the timeline, and your sponsor approves, rejects or defers it. Weekly written status notes go to owners, which matters when decision makers travel between cities or countries.

I also watch continuity. Who is configuring now, who will support you after go-live, where customizations are documented and whether your company holds its own administrator credentials are questions I raise early, not when the partner's lead has moved to another client. The general approach is on my ERP implementation page.

Cash payments, site advances and subcontractor settlements

Iraqi operations are often cash-heavy. Site managers receive advances, storekeepers buy materials locally, subcontractors may be paid partly in cash, and some customers settle in dinars while contracts are priced in dollars. If these flows stay outside the ERP, project costs and supplier balances are never quite right.

I work with your finance team and the partner to design each flow as a controlled process:

• Cash advances to site staff, recorded against a person and a project, with receipts submitted and the advance cleared or returned.
• Petty cash at each site, per currency, with approval limits and periodic counts.
• Subcontractor payments linked to measured and approved work, with retention held and released according to the contract.
• Supplier payments in dinars or dollars, applied at the rate your accountant specifies.
• Customer receipts in either currency, matched to progress invoices.

Every one of these flows turns into a test script performed by those who handle it daily: site accountants, storekeepers and project managers, with finance checking the ledger result. A process that matters to cost control does not pass until it reconciles. The general testing method is under ERP testing and UAT, and the project costing guide covers the cost side in more depth.

Migrating from local packages, spreadsheets and paper site records

Data for an Iraqi ERP usually comes from several places at once: a local accounting package at head office, spreadsheets for projects and stock, and paper registers or files at sites. Migration therefore needs an owner in your team, clear templates agreed with the partner and several trial loads, with each one reconciled before the next.

The items that need most attention are:

• Project balances. Contract values, invoiced to date, retention receivable and payable, and costs to date per project, agreed with project managers and finance.
• Subcontractor and supplier positions. Open invoices, advances paid and retention held, by currency.
• Stock at each site and warehouse. Counted, valued and loaded by location, with materials already issued to projects excluded.
• Fixed assets and equipment. Vehicles, plant and tools with their location and responsible person.
• Entity separation. Each legal entity's data loaded into its own company, never merged for convenience.

Cutover for each entity is planned at a period end where possible. Payroll often stays with an internal team or provider; I agree how its journals reach the ERP by entity, project and currency. Method notes live under ERP data migration, and the guide to migrating from spreadsheets is relevant here.

Phased go-live by entity and site, then hypercare

I usually recommend going live in stages rather than all at once. Head office and one entity first, then further sites or companies in turn, gives the partner's team a manageable load and lets each stage learn from the previous one. The sequence is agreed early, because it affects migration, training and support planning.

Before each stage, a go-live review checks UAT sign-off for the processes in scope, reconciled balances for that entity, trained users at each site, a tested offline procedure for locations with weak connectivity and support arrangements with the partner. If something critical is missing, that stage waits while the others continue.

Hypercare follows each switch. Problems reported from every location land in a single log, which I go through each day with the partner and key users, ranked by business impact. Typical early problems are practical: a storekeeper who cannot post a receipt offline, an advance recorded against the wrong project, a Kurdish template printing incorrectly. I stay through the first period close for each entity, then pass ownership to your internal team along with a list of improvements parked for later.

All of this is remote. If you have not yet chosen a platform or partner, see ERP selection in Iraq. The Iraq ERP consultant page, the Erbil and Baghdad pages and the ERP go-live support service give more context.