Transformation that changes how the work is done

There is a steering committee, a budget and a programme with a year in its name

There are forty initiatives on a slide, each with an owner who has a day job, and a monthly meeting where most of them are reported as amber. Two years in, the branch manager still approves a discount by phone, the warehouse still writes the delivery on a pad, and the month still closes late enough that the numbers are history by the time anyone sees them.

What went wrong is nearly always the same thing. The platform was chosen before the operating model was written. A licence agreement was signed, an integrator was appointed, and the questions that actually decide the outcome — who sets pricing, who owns the customer record, what a branch manager may approve without asking — were never answered, because they are not software questions and nobody in the programme had the authority to settle them.

So the software arrives and the organisation routes around it, exactly as it did before, and the programme reports progress in percentage complete against a plan that measures activity.

Digital transformation consulting for Saudi Arabia and the GCC starts with the operating model

A target operating model is a short document that says how the business will run: the processes that matter, who decides what, which system holds which truth, and what each function is accountable for. It is written before a platform is chosen, because the platform is a consequence of it and not the other way round.

In Saudi Arabia there is usually an external clock as well. ZATCA's e-invoicing requirements put a hard date on the finance system that the programme does not control, and enterprise and government buyers ask about Arabic and localisation before they ask about capability. A roadmap that starts with the interesting projects and leaves the dated obligations for later runs out of goodwill at exactly the wrong moment.

Across the UAE, Qatar and Oman the pattern repeats in a different order. The compliance work is not optional and the discretionary work has to be sequenced around it.

How the programme runs, and what it produces

Diagnosis first: two weeks inside the operation, documenting how the work is actually done and where two systems disagree. Then the target design and a sequenced roadmap in which every phase pays for the next. That is a constraint rather than a slogan — if a phase cannot be described in terms of a cost it removes or a decision it makes possible, it does not get scheduled.

Metrics are agreed at the start against the baseline recorded in the diagnosis, so success is not decided retrospectively by whoever writes the closing deck.

Change management is aimed at the people expected to resist, because they usually have a reason worth hearing. The storeman who refuses to use the new receipt screen is often the only person who knows that deliveries arrive without paperwork after six o'clock, and the design has to answer that before it can ask him to comply.

Governance is the part everyone skips: named owners, a review cadence, and a standing escalation route so problems surface while they are still small.

Who this is for, and who should buy something smaller

Groups that have grown past the way they are run: a founder-led business where every exception still reaches the founder, a family group after a generational handover, or a company that has just acquired another and now has two operating models producing one set of accounts.

It is not for a company whose real problem is one system. If what you need is finance and inventory on a single platform, buy an ERP implementation and skip the programme. You will get the same outcome faster and for less, and a transformation wrapper around it adds governance you do not need yet. We say that in the first meeting when it is true, and it is true often.

It is also not for an organisation unwilling to change a decision right. If the answer to the question of who owns pricing is going to remain the owner, case by case, then no operating model will hold and the programme will produce documents instead of change.

Why programmes stall, and what determines the cost

Two failure modes account for most of it. The first is scope by inventory: every department lists what it wants, the list becomes the roadmap, and nothing is sequenced against anything. The second is a programme run by people without authority — a project office reporting status on decisions it is not allowed to make.

Cost is set by the number of entities and functions in scope, how many markets you operate in, how much of the current state is already documented, and whether you want us to run delivery or only to design and govern it. The design work is a fixed scope at a fixed price and is deliberately sold apart from delivery, so the roadmap cannot be read as a shopping list for our own services.

Nothing in the roadmap is contingent on Faceela delivering it. In most programmes several phases belong to somebody else, and the report names them as such.