Process improvement in Qatar should start with one process that either touches cash or carries a compliance deadline — usually quote-to-cash, procurement-to-payment, or the monthly WPS payroll run — mapped as it actually operates, measured on lead time and rework, and fixed at its constraint before any software is bought. Baseline that single process for two to four weeks, change it with the people who run it, and only then standardise and automate. Launching ten initiatives at once is the most common reason improvement programmes stall in Doha.
That advice is deliberately narrow, because the failure pattern is consistent. A management team returns from a conference or a board offsite with a list of ambitions — digitise, lean, automate, reduce overhead — and asks three departments to pursue all of them in parallel. Six months later nothing has moved, the ERP project has absorbed the attention of the finance team, and the original operational problem is still there, now with a steering committee attached to it.
The alternative is unglamorous and works: choose the process where errors cost the most, understand it properly, measure it honestly, and fix the constraint. This guide sets out how to do that in a Qatari operating environment, where approval chains are hierarchical, documentation is often bilingual, and several steps in any process sit outside your building entirely.
The loudest complaint in the business is rarely the most expensive problem. Finance teams tend to complain about month-end; operations teams complain about procurement; sales complain about credit control. The right starting point is the process where a single failure produces a regulatory consequence, a lost receivable, or a customer dispute — and where the same failure is repeating.
Use the table below as a triage. The middle column matters more than the symptom itself: it separates a process defect from a staffing or systems defect, which need different responses.
| Symptom you are seeing | What it usually indicates | First number to establish |
|---|---|---|
| Invoices issued late or reissued | Handoffs between sales, operations and finance; approval sitting with someone who does not know the commercial terms | Days from delivery or milestone to invoice, and the count of credit notes per month |
| Month-end close keeps slipping | Reconciliation done after the fact; receipts and supplier bills unposted until the deadline | Working days to close, and unreconciled bank lines at day five |
| Payroll always runs to the deadline | Attendance, leave and overtime assembled manually into the WPS file each cycle | Hours of manual preparation per run, and rejected salary files per cycle |
| Purchases bought outside the process | Thresholds unclear, or the approval route is slower than the operational need | Share of purchase orders raised after delivery, and average approval time by value band |
| Stock counts never match the system | Receiving not matched to the purchase order; issues recorded late or not at all | Number of lines adjusted at each stocktake, and the value of unexplained variance |
Pick one row. If two rows share the same upstream step — for example, both late invoicing and stock variance trace back to goods being received without a matching document — that is your real starting point, and the scope is now obvious.
Most Qatari businesses have a documented procedure that describes the intended flow and an actual flow that has drifted from it. In Doha the drift is predictable: the formal step lives in the ERP, the coordination lives in WhatsApp, the exception approval lives in an email thread, and the reconciliation lives in a spreadsheet maintained by one person who is now indispensable.
Map the actual flow by walking it. Sit with the person who raises the document, then follow the same transaction to the person who approves it, the person who posts it, and the person who chases payment. Ask at every handoff:
Record the map as a simple sequence of steps with an owner, a system, a typical waiting time and an exception path for each. It does not need to be a polished swimlane diagram. It needs to be recognisable to the people doing the work — if they correct it, the map is doing its job.
Without a baseline, improvement is an opinion. You do not need a data warehouse to establish one; you need a log kept for two to four weeks on the transactions as they happen. Three measures carry most of the diagnostic value:
A useful sanity check comes from Little's Law, a standard result from queueing theory: the amount of work in progress equals throughput multiplied by cycle time. In practical terms, if your team can complete five transactions a day and there are forty open, the average transaction will take about eight days regardless of how hard anyone works. That reframes the conversation from effort to queue size, which is usually the real lever.
Once the process is mapped and measured, the constraint is normally visible: one step where work accumulates, one approval that everything waits on, or one reconciliation that only happens weekly. Improving anything upstream of that point simply builds inventory in front of it.
Common constraints in Qatari operating environments, in our experience, fall into four types. Batching — approvals, payments or postings done once a week when they could be done as they arrive. Serial sign-off — three or four approvers in sequence where the decision only needs two. Missing thresholds — every purchase, however small, routed to the same senior authority. And unclear ownership — a step that two functions both believe the other performs, so it is performed late and reluctantly.
Each has a process answer, not a software answer. Batch work into a daily cut-off rather than a weekly one. Approve in parallel where the checks are independent. Set value thresholds so routine spend moves without senior review while exceptions still escalate. Name one owner per step.
Approval design deserves separate attention because it is where most of the delay in a Doha process is created, and where generic templates imported from another market fail. A structure that works here usually separates three questions: what the decision is worth, what risk it carries, and who is accountable if it is wrong.
| Decision type | Sound approval design | What to avoid |
|---|---|---|
| Routine operating spend | Budget holder approves within a value band; finance checks after the fact against budget | Every item routed to the general manager or owner |
| Customer pricing and credit | Commercial owner approves price; finance holds a documented credit limit and exception rule | Two parallel approvals with no clear tie-breaker |
| Payroll and WPS release | Maker-checker with a fixed calendar: data cut-off, review window, file generation, bank submission | Manual assembly each month with no named owner of the final file |
| Regulatory filings and tax positions | Preparer and reviewer separated, with evidence retained for each figure | One person preparing and submitting with no review trail |
| Cross-entity or group decisions | Written delegation of authority by entity, reviewed when ownership or structure changes | Assumed authority that varies by who is in the room |
Two Qatari details are worth building in from the start. First, documents that move between Arabic-speaking operations and English-speaking finance need a single agreed version of record, or reconciliation becomes a translation exercise. Second, decisions that depend on an external approval — a ministry, a bank mandate change, a municipality permit — should be tracked as a separate queue with its own owner, because you cannot compress a timeline you do not control, only prepare for it properly.
The sequence that works is eliminate, simplify, standardise, then automate. Automating an unexamined process simply makes the wrong steps faster and harder to change, because the logic is now embedded in configuration. This is why so many ERP implementations in Qatar deliver a system that faithfully reproduces the chaos it replaced.
Once the process is genuinely simplified and written down, the automation step is usually straightforward. On Zoho, that typically means workflow rules and approvals in Zoho Books, blueprints and assignment rules in Zoho CRM, and reorder or transfer rules in Zoho Inventory — all of which encode a decision you have already made rather than inventing one. On Odoo, it usually means approval routes, automated actions, reordering rules and access rights mapped to the roles you defined, with the advantage that purchasing, inventory, manufacturing and accounting share one record instead of four.
The test for readiness is simple: if you cannot describe the new process on one page, in the order the work happens, with a named owner for each step, the system is not the next step. Configuration choices made at that point tend to be guesses that get expensive to reverse.
A standard operating procedure earns its place only if someone reaches for it during an exception. That means one page, one process, and a structure that answers the questions people actually have: what starts this, what are the steps in order, which system each step happens in, what the exceptions are and who decides them, and who owns the document.
Keep a revision date and a named owner on every SOP, and write the operational version in the language the person doing the work reads most comfortably — in many Doha businesses that means an Arabic summary alongside the English detail, particularly for warehouse, production and site roles. A document that exists only in head-office English will not be used on a site in Industrial Area. Our consulting services include this documentation work precisely because it is the step most often skipped once the workshop ends.
Change one team, one branch or one product line first, and run the new procedure for four to six weeks before rolling it out. Measure with the same definitions you used for the baseline — same start trigger, same end event, same rework definition — or the comparison will be meaningless. Change one thing at a time where you can; if you change the process and the system in the same week, you will never know which one produced the result.
Expect the pilot to expose design flaws, and treat that as the point rather than a setback. A procedure that survives contact with a live month-end, a WPS cycle and a customer dispute is one you can scale. A procedure that only worked in the workshop is not.
| Weeks | Focus | Output you should hold |
|---|---|---|
| 1–2 | Select one process and map it by walking it with the people who run it | A step-by-step map with owners, systems, waiting points and exception paths |
| 3–4 | Baseline lead time, touch time and rework on live transactions | A measured baseline with the definitions written down and agreed |
| 5–8 | Redesign around the constraint; agree the approval matrix; pilot in one team | A revised procedure, a written approval matrix, and pilot results against the baseline |
| 9–12 | Standardise, train, and configure the workflow in Zoho or Odoo | A one-page SOP, trained users, configured approvals, and a control that shows the process is holding |
Twelve weeks is a planning envelope, not a promise. Scope, decision speed and the availability of the people who actually run the process will move it either way. What should not move is the order: understand, measure, fix, standardise, then automate.
A process improvement engagement has succeeded when five things are true: the process is documented as it now runs, the baseline and the new measurement use the same definitions, the new procedure is written on one page with named owners, the approval matrix has been formally agreed rather than assumed, and the team can run the monthly cycle without the consultant in the room. If any of those is missing, you have bought activity rather than change.
BNF Consulting works on process improvement with companies across Doha from our office in West Bay. As an Authorised Zoho Partner and Official Odoo Partner, we can carry a redesigned process through to configured workflows in the system you already use — or help you choose between them — and we will tell you when the honest answer is that the process should be fixed before any software is touched. Call +974 7703 0026 or email sales@bnf-consulting.com to discuss a specific process, or use the contact page to arrange a conversation.
Start with one process that carries a compliance deadline or directly affects cash, such as quote-to-cash, procurement-to-payment or the monthly WPS payroll run. Map it as it actually operates rather than as the manual describes, baseline lead time and rework for two to four weeks, then fix the constraint before considering software. One process done properly beats ten initiatives launched in parallel.
A single process can usually be mapped and baselined in about four weeks, redesigned and piloted over the following month, and standardised by the end of a 90-day cycle. Timelines move with scope, decision speed and the availability of the people who run the process. Multi-site or cross-entity programmes take longer because each site needs its own pilot and its own approval matrix.
No. Most process problems in Doha are created by batching, serial approvals without thresholds, unclear ownership and workarounds that live in spreadsheets and messaging apps. These are fixed by redesigning the procedure and agreeing an approval matrix, not by buying a system. Software comes last, once the new process is simple enough to describe on one page.
Cost cutting reduces spend by removing people, suppliers or activity, and often damages capacity in the process that follows. Process improvement removes waiting, rework and unnecessary approvals while keeping the same output, which lowers cost per transaction without removing capability. In practice the savings from rework and delay are usually more durable than a headcount reduction.
Use the same three definitions before and after: elapsed lead time from trigger to outcome, touch time spent actually working on the transaction, and the rework rate at each handoff. Comparing like with like is what makes the result credible, so write the definitions down before the pilot starts. A reduction in lead time without an increase in rework is the clearest sign the redesign held.
