ERP Business Analyst in Iraq

Writing requirements entity by entity

A group operating across federal Iraq and the Kurdistan Region often runs separate legal companies with their own registrations, accountants and banking. Requirements gathered as if the group were a single business tend to miss that, and the gap only appears when the implementer tries to configure a second company.

I gather requirements with an entity matrix from the first workshop. Each legal company gets its own column describing its ledger, document numbering, bank accounts, local reporting and the staff who use it. Shared elements, such as the customer list, item catalog or a common chart of accounts, are stated as shared deliberately rather than by accident. Transactions between companies, like equipment hire, staff recharges or material transfers, are written as separate requirements with their own approval and evidence.

Tax and statutory points can differ between the entities. Interpreting them is not my role; the accountants serving each region confirm the treatment, and their guidance becomes requirements and test cases. The matrix also supports the design decision on whether one multi-company platform or separate systems make more sense, a question the Iraq ERP consultant page looks at from the configuration side. The requirements gathering page explains the wider method.

Mapping contracting and import chains

Two chains dominate the requirements for many Iraqi businesses: the contract chain and the import chain. Both involve many hands and many documents, and both lose money quietly when a step is unrecorded.

For contracting and oil and gas services, the swimlane diagram starts at tender or award and follows mobilization, purchase requests from site, subcontract agreements, progress measurement, client invoicing, retentions and final account. I note who approves each step on site and in head office, which documents pass between them and where costs currently arrive without a project code. Each weak point links to a numbered requirement.

For import trading, the diagram runs from supplier quotation through order, advance payment, shipping documents, clearing and transport charges, warehouse receipt and landed cost, then on to sale and collection in dinars or dollars. Requirements state which charges belong to which shipment, who records them and when stock valuation is closed.

The diagrams are reviewed with the people who run each step, not only with managers, because field supervisors and clearing staff often describe a different process from the one on paper. The ERP process mapping page shows the notation I use.

Documentation international partners will ask for

Iraqi firms working with joint venture partners, main contractors or international clients are frequently asked for structured cost reports, approval trails and supporting evidence. When those needs are not in the requirements, staff end up rebuilding reports by hand for every request.

I treat partner reporting as a requirements area of its own. For each external party the BRD records which reports they expect, at what frequency, in which currency and format, what supporting documents must be attached, and who signs before submission. Where a partner supplies its own template, the template is attached and every field is traced back to a source in the system.

The same section covers audit trail expectations: which records must be locked after approval, which changes must show who made them and when, and how scanned documents such as delivery notes or job tickets are stored against their transactions. During demonstrations, each vendor produces one partner report from sample data, and the result is scored in the fit-gap grid alongside the core accounting requirements. My BRD consulting service explains how these sections are structured.

Arabic and Kurdish outputs, hosting and connectivity

The analysis and the BRD are in English. Many outputs of an Iraqi ERP, however, will be read in Arabic or Kurdish: invoices, delivery notes, site forms and some internal reports. The requirements include a register of these outputs with the language, text direction, fixed wording and the bilingual staff member who approves each one. Arabic and Kurdish text is reviewed by your team, and that review is tracked to completion.

Technical requirements receive equal care because field conditions vary. I document where the system and backups are hosted and how often backups are tested, how sites with weak or interrupted internet will record receipts, issues and timesheets, whether mobile entry must work offline and synchronize later, and what manual fallback applies if a site is cut off for a day. User access is specified per entity and per site.

These answers shape the shortlist as much as functional fit does. The Iraq pages for ERPNext, Odoo, Zoho and Dynamics 365 discuss hosting options for each platform, and the gap analysis records how each vendor answered.

Running the analysis remotely with head office and sites

Every part of the analysis happens online. India's working day starts a few hours before Iraq's, which puts live sessions in your morning and midday, and my written notes reach you before the next working day.

Head office workshops cover finance, procurement and management reporting. Site and warehouse staff, who may have limited time or bandwidth for video calls, contribute through short voice or screen recordings, photographed documents and simple questionnaires. All open questions go into one shared tracker, each with an owner and a due date set by your project lead.

Approval runs by section: each entity's finance lead signs the entity matrix, operations signs the process diagrams, and the partner reporting section is checked against the partners' own templates. The BRD is frozen only once every section is approved. For the general approach, see ERP business analysis, and for the broader market view, visit the Iraq overview.