ERP Requirements Consultant, Jordan

Why the written lines matter more than the workshops

Workshops produce understanding. Only the written specification produces commitment. When a Jordanian implementer prices a project, the proposal rests on the lines they were given, and anything not written down becomes either an assumption or a change request.

So the document has to be complete in places that are easy to skip. A typical structure I use:

• Scope: legal entities, including any company registered in the Aqaba Special Economic Zone, branches, warehouses and what is deferred to a later phase.
• Functional lines: sales and collections, purchasing and supplier payments, inventory and batches where relevant, service or project billing, finance and the period close.
• Statutory lines: grouped together so your advisor reviews them as a set.
• Non-functional lines, integrations and migration.
• Reports: named outputs with their audience, filters and frequency.

Each line is one requirement, not three joined by "and". Compound lines are where bidders quietly meet half the sentence. I also attach a short glossary, because terms such as a returned check or a tax number mean something precise to your staff and may mean something looser to a regional bidder. The lines themselves come from discovery work such as the ERP business analysis for Jordan. The general structure is described on the ERP requirements gathering page.

Statutory and check-handling lines written as tests

I draft statutory lines with your advisor's input and record who confirmed each one. My role is to make the wording testable; the interpretation of the law stays with them. Examples of how lines read:

• Each sales invoice and credit note is submitted to the national e-invoicing system in the format your advisor and implementer confirm, and the submission status is stored against the document.
• A rejected submission is visible to a named role, can be corrected and resubmitted, and the history of attempts is kept.
• Sales tax is calculated per line using the treatments your advisor has listed, including exempt and zero-rated cases where they apply to you.
• Dinar amounts are held and printed to three decimal places of fils without rounding differences on statements.
• A post-dated check received from a customer is recorded with its due date and bank, moves through the agreed statuses, and only affects the bank balance when deposited and cleared.
• A returned check reopens the customer balance and records the reason, without manual journals.
• Payroll results from your provider can be imported, and any file the social security corporation requires is produced by the provider or the system as agreed.

Each of these lines can be shown in a demo and later passed or failed in testing. That is the point.

Non-functional requirements for Jordanian operations

Non-functional lines cover qualities of the system rather than its features. It is easy for a specification to reduce them to a single sentence about security. I write them as questions and conditions that a bidder must answer in their proposal.

Hosting and data. Where production data and backups are held, which vendor staff can reach them, whether every record and attachment can be extracted on request, and how restore tests are evidenced. Personal data of staff and customers is covered with reference to Jordan's data protection rules as your advisor reads them, without the specification guessing at obligations.

Connectivity. What happens if the connection drops while invoices are being submitted: are they queued, flagged or lost? Can a branch or warehouse keep working and sync later?

Access and audit. Roles that separate entering, approving and posting; approval limits from your delegation matrix; an audit trail on price changes, credit limit overrides and check status changes.

Performance and availability. Stated by business moment, such as end-of-month invoicing or a busy collection day, rather than by abstract figures.

Bidders who answer these clearly tend to have thought about operations. Bidders who answer with brochure text give you a useful signal for the Jordan ERP selection stage.

Integration, migration and setting priorities

Integrations and data migration belong in the specification as requirements, each with a direction, an owner and a definition of done. For Jordanian companies the list often includes bank statement import for local banks, payroll results from an outsourced provider, an e-commerce or point-of-sale feed for retailers, and a group reporting feed for subsidiaries of regional or international parents.

Migration lines state what moves and in what form: open customer and supplier balances, uncleared post-dated checks with their due dates, open batches with expiry where stock is controlled, and the depth of history to be loaded for comparison reports. Leaving open checks out of the migration scope is a gap that tends to surface only at cutover.

Owners then rank their own lines: Must for go-live, Should, Could, or Won't in this phase. I challenge long Must lists, because they hide the few requirements that genuinely decide fit. A clear Won't list matters too; it shows bidders where not to spend effort and prevents later claims that something was implied.

The ERP data migration and ERP integration pages explain how these lines are delivered once a partner is appointed.

Traceability, the tender and the signed baseline

Each line keeps its identifier from draft to go-live. It appears in the demo script that proves it, the fit-gap row noting each bidder's proposed route and the UAT case that confirms it. One register shows those links, so any line that disappears does so by a recorded decision.

For a tender, the annex goes out with fixed response codes per line: standard, configured, custom, third-party or not offered. That keeps an Amman implementer's answers comparable with a regional bidder's. The method is on the ERP RFP consulting page.

After review sessions with each owner and the sponsor, I issue a baseline version and keep a change log. The contract should name that baseline. Later changes carry a reason, a priority and an approver.

Gaps worth checking in Jordanian specifications, as risks:

• E-invoicing stated as a single line with no rejection or correction handling.
• Post-dated checks treated as ordinary receipts.
• No lines for an Aqaba zone entity with different treatment.
• Arabic printouts mentioned without a document list.
• No data export requirement for leaving the vendor.

I work remotely with no vendor commissions. See the Jordan ERP consultant page and the Jordan overview for wider context.