Contact Info
Why hire an ERP business analyst in Oman before choosing software?
Omani businesses carry requirements that generic ERP templates skip: VAT treatments under the Oman Tax Authority, preparation for e-invoicing, rial amounts in baisa, bilingual documents and, for energy-sector suppliers, In-Country Value reporting. A business analyst captures these in a requirements document first, so vendors are compared on the same detail and nothing is left to be discovered during configuration.
Last reviewed by Vikas Saroj
Omani ERP projects often stall over details nobody wrote down: which VAT treatment applies to a supply to a free zone, how a service contractor proves its local spend to an operator, why the bank rejected a payment file, or how a container's freight and duty end up in item cost. Each one becomes a change request if it surfaces after the contract is signed.
I work remotely with Omani companies to capture these details as business requirements. Process owners walk me through their work, I draft the BRD and score shortlisted platforms against it, with Arabic and English output marked on every document that needs both.
You keep a reference your team can use for vendor talks, testing and sign-off.
Each deliverable records an Omani detail in a form a vendor can price and a tester can verify.
A list of the real transactions you run, from local sales to imports and services bought abroad, with the treatment your advisor confirms for each and the data the system needs.
Requirements for clean customer, supplier and item data and a structured invoice layout, so the move to electronic invoicing becomes a configuration step when the rules apply to you.
For suppliers to energy and government-linked operators, requirements to tag local spend, Omani staff and subcontractor data so commitment reports come from the ERP, not a spreadsheet.
Maps of import, clearance, warehousing and delivery flows through Sohar, Salalah or Duqm, including forwarders, clearing agents and the documents passed between them.
A numbered requirements document with owners and acceptance criteria, listing which invoices, quotations, statements and letters must print in Arabic, English or both.
A matrix showing how Zoho, Odoo, ERPNext or Dynamics 365 handle each requirement, separating standard features from configuration, add-ons and custom development.
Business first, technology second. You can hire me for one step - a BRD, a gap analysis, a vendor shortlist - or for the whole journey.
Evidence from real transactions
Requirements people can approve
Vendors measured on your scenarios
Oman applies VAT through the Oman Tax Authority, and the authority has been preparing an electronic invoicing framework. I keep the regulatory detail high level here because scope and timing are set by the authority and can change; confirm both with your tax advisor and the official guidance before you rely on them.
For the BRD, the useful work is to break tax into concrete, testable statements. I build a scenario register with finance and your advisor, and each row becomes one or more requirements:
For e-invoicing, I add data quality requirements: registration numbers validated on entry, no free-text customers, consistent units and descriptions. I do not interpret the law; I record what your advisor tells me. My ERP requirements gathering page describes the wider method.
A large part of Oman's private sector supplies oil, gas and other energy operators, along with government-linked infrastructure projects. These customers work through framework agreements, call-off orders, service entry sheets and vendor portals, and many expect suppliers to report on In-Country Value commitments such as local purchasing, Omani employment and training. In many supplier businesses those reports are still assembled by hand from several spreadsheets.
When I map this kind of business, the requirement set usually covers:
The exact ICV methodology belongs to each operator, so I document what your customers ask for rather than assuming a standard. These flows are drawn using my ERP process mapping approach.
With ports at Sohar, Salalah and Duqm and land routes into neighboring countries, many Omani companies import, store and re-distribute goods. Their requirements are dominated by movement and cost, and they are easy to underestimate in a module checklist.
I document how a shipment moves from purchase order to forwarder booking, arrival, customs clearance, warehouse receipt and onward delivery, and which documents travel with it at each step. From that map come requirements for landed cost allocation (freight, insurance, duty, clearing and handling) by value, weight or volume; goods in transit visible as stock; batch or expiry tracking for food and pharmaceutical lines; and delivery notes in both languages for government and project customers.
Payroll and HR requirements often appear here too, because logistics firms run drivers and warehouse crews. I record whether salary files for the Wage Protection System, social insurance data and Omanization reporting will come from the ERP or a separate HR product, and what has to pass between them. The resulting gap analysis then shows which platforms handle these flows without heavy customization. Background on distribution systems is in my ERP for trading article.
I begin with the owner or general manager to understand which customers, contracts and reports matter most, then hold separate sessions with finance, procurement, operations and HR. Many Omani firms are family businesses or groups where a few senior people hold the commercial rules in their heads, so those early conversations save a lot of rework later.
Workshops are scheduled on your Sunday to Thursday week in Gulf Standard Time, kept short and focused on one process at a time. I ask for real documents in advance, such as a customs declaration, a call-off order or a bilingual invoice, because walking through a document gets more accurate answers than abstract questions. Staff who cannot join live can answer a short questionnaire in Arabic or English.
All of this happens online; I have no base in Oman and visits are possible only by arrangement. Drafts are shared for comment and approved area by area, and the agreed BRD becomes the scope reference for whichever implementer you choose. See ERP BRD consulting for the document structure, my ERP consultant page for Oman for selection and implementation support, or the Oman overview.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
They will cover the data and process side: validated registration numbers, clean masters, structured invoice content and how errors are handled. Scope and timing come from the Oman Tax Authority, so confirm them with your advisor; I turn the confirmed position into requirements and tests.
Often yes, if the right data is captured at source. I document which spend, supplier and staff attributes your operators ask for and specify how they are tagged, so reports come from transactions. The methodology itself is defined by each operator.
Yes. Baisa precision, rounding per line or per document, and the totals shown on invoices, reports and bank files are written as explicit requirements and included in demo scripts, so each vendor has to show the result.
No. I am not a tax advisor. I build the scenario register with your finance team and advisor, record the treatment they confirm and make sure the system requirements and test cases follow it.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.