ERP Requirements Consultant, Bahrain

How a Bahrain specification is laid out

The skeleton matters more than it seems. If finance writes in one style and operations in another, vendors answer the easy lines and skip the awkward ones. I agree the structure first, then fill it.

• Scope: which legal entities, branches and activities are covered in this phase, and which are explicitly out.
• Functional lines by process area: selling and invoicing, buying and supplier payment, inventory or engagements, fixed assets, period close and management reporting. Each line has an identifier, an owner and a short reason.
• Bahrain statutory lines: kept in their own section so your advisor can review them in one sitting.
• Non-functional lines: hosting, access control, audit trail, performance and availability.
• Integrations and data migration: listed as requirements, not left for the implementer to discover.
• Glossary: local terms such as CR number, fils and the names your staff use for documents.

A good test of the layout is whether a vendor in Riyadh or Dubai, who has never seen your company, could price it without a call. If they would need to ask what a line means, the line needs rewriting. The BRD consulting page describes the wider document this sits inside.

Writing VAT, fils and Arabic needs as testable statements

"The system must be VAT compliant" appears in many Gulf specifications and is among the least useful lines in them. Nobody can fail it. I break it into statements a tester can run, drafted with your advisor and marked confirmed before they reach a vendor.

• The tax invoice prints the fields your advisor lists for Bahrain, in Arabic and English, generated from one transaction record.
• A credit note references the original invoice and reverses the tax on it without manual journal entries.
• Sales to a customer in another Gulf state carry the treatment your advisor has confirmed and are reported apart from domestic supplies.
• All dinar amounts are stored and printed to fils, and line rounding does not leave differences on statements or bank reconciliations.
• The system produces the data your accountant uses for the VAT return, reconciled to the ledger by tax code.
• Transaction records and attachments can be kept for the retention period your advisor confirms.

Where an obligation is under discussion rather than in force, such as structured electronic invoicing, I write it as a Should with a note, so vendors explain their route without the specification overstating today's rules. Payroll is handled the same way: the interface to your payroll provider and any social insurance or wage file is specified, while the calculation stays with the provider.

Non-functional requirements Bahrain buyers tend to leave out

Functional lines get most of the attention because process owners can picture them. The lines that cause trouble later are usually non-functional, and in Bahrain they carry some particular weight.

Hosting and data location. Rather than asserting where data must live, I write questions each vendor must answer: where production data and backups are stored, who can access them, how a full export works and how long a restore takes in practice. Businesses licensed by the Central Bank of Bahrain may have outsourcing expectations; your compliance team interprets them, and the specification makes sure the answers exist. Personal data handling is framed around Bahrain's data protection law, again for your advisor to confirm.

Access and approvals. Role definitions, segregation between preparing and approving payments, and approval limits that mirror your delegation of authority.

Audit trail. What must be logged when a posted document, price or bank detail changes, and who can see that log.

Performance and availability. Expectations described by business moment, such as invoicing at month-end or users at a remote site, rather than by figures a vendor can game. If a regional parent supplies the hosting, the same lines apply to them.

Priorities, traceability and the tender

Every line carries a priority agreed with its owner: Must for this phase, Should, Could, or Won't for now. I push back on specifications where nearly everything is a Must, because vendors then treat all of it as negotiable. A short Must list is a stronger signal.

Each identifier then travels. It appears in the scripted demo scenario that proves it, in the fit-gap entry that records how a vendor would meet it, and in the test case that later confirms it. The traceability register shows those links in one view, so a requirement cannot vanish between selection and go-live without someone deciding it should.

For a tender, I produce an annex from the same register. Vendors answer per line with a fixed code: standard, configuration, custom development, third-party product or not offered. Free-text marketing answers are not accepted in place of a code. That makes responses from a Manama firm and a regional bidder comparable, and it feeds directly into the Bahrain ERP selection scoring. The method behind the annex is on the ERP RFP consulting page.

Sign-off, version control and gaps worth checking

A specification is only useful if everyone knows which version is current. I keep a change log, issue a baseline after sign-off, and record who approved each section. In smaller Bahraini firms one finance manager may own most lines, so I ask the sponsor to sign as well, and I note any area where nobody would accept ownership.

Once a partner is chosen, the statement of work names the signed baseline as its reference. Later changes go through the log with a reason and a priority, which gives the client-side implementation work a firm reference.

Gaps worth checking in any Bahrain specification, whoever wrote it:

• A template inherited from a sister company in another Gulf country, carrying rules that do not apply here and missing ones that do.
• Dinar precision assumed to be two decimals.
• Arabic requirements stated as "supports Arabic" with no list of documents.
• No exit or export requirement, leaving data portability to goodwill.
• Payroll interfaces left out because payroll sits with a provider.

I work remotely and accept no vendor commissions, so the document reflects your needs rather than any product's strengths. Process discovery itself sits with the Bahrain ERP business analysis. More context is on the Bahrain ERP consultant page and the Bahrain overview.