Transformation Before Platform: The Decision the Software Cannot Make for You
· 13 min read · Faceela
There is a budget. There is a steering committee that meets fortnightly. There is a shortlist, or a signature, and a slide with a timeline on it. Somebody has used the words digital transformation in a board pack without being asked what they mean.
The question you are actually holding is narrower than the programme name. When this is finished, will anything about how the company runs be different — or will the same people make the same decisions in the same order, on screens instead of paper?
The answer decides whether the money produces a changed business or an expensive photocopy of the current one, and it is available now, before anyone configures anything — it sits in what has already been decided and what has been left open.
What the phrase has come to mean, and why it is nearly useless as written
Ask ten people in a GCC head office what their transformation programme is, and you will get three genuinely different answers wearing the same label.
Replacing a system. The old software is out of support, the vendor is pushing a version, the finance team cannot close in under three weeks. This is a re-platform. It is legitimate, often necessary, and it is not a transformation. Nobody's authority changes.
Digitising documents. Forms become screens. Signatures become approvals. PDFs move from a shared drive into a system with a search box. This is worth doing and it is the least ambitious thing on the list.
Changing how decisions are made. Who approves what, at which threshold, on what evidence, and how quickly. Which numbers the company is run on and who owns them. What the company stops doing. Only this one deserves the word.
The phrase is useless because all three arrive under it, and the first two are far easier to fund, staff and finish. A steering committee that cannot say which of the three it is chairing will end up chairing the first, whatever the charter says — replacing a system has a delivery date, and changing decision rights does not.
Before anything else, write one sentence naming which of the three this is. If it is the first or second, stop calling it a transformation and the programme immediately becomes more honest and easier to run. If it is the third, keep reading, because the platform is now the smallest part of the work.
Digitising a process is not changing it
Here is the failure in one picture. A purchase requisition needs four signatures. It waits on desks, it gets chased over WhatsApp, and the elapsed time from request to purchase order is measured in weeks, most of which is waiting rather than working.
The programme goes live. The requisition is now a record in the system. It needs four approvals. It waits in four inboxes. It is still chased over WhatsApp, because nothing in the new system chases for the requester.
The paper form became a screen. The approval chain stayed. The elapsed time is roughly what it was, and now there is a licence fee attached to it.
There is one real benefit hiding in that outcome, and it is worth naming because it is the seed of the actual work: the system now measures the delay it inherited. For the first time you can see, per approver, how long a document sits. That measurement is the input to the decision nobody has made — do four people need to approve this at all?
That decision is the transformation. It has nothing to do with software. It can be taken today, on the current system, by someone with the authority to remove two approvers and accept the risk that removal creates. When people say a transformation programme "did not deliver", this is almost always what they mean: no such decision was ever taken, so the work is the same work.
The test that takes five minutes
Take any process in scope and answer three questions in writing.
- Which steps will not exist afterwards? Name them. Not "streamlined" — deleted.
- Which decision will be made by someone different, or at a different threshold? Name the person and the number.
- What will the business stop asking for? A report nobody reads, a second approval, a monthly reconciliation between two systems that will now be one.
If all three answers are blank for every process in scope, you are not running a transformation. You are running a procurement, and it should be governed, budgeted and judged as one.
The operating model is the decision; the platform is the instrument
"Target operating model" is a phrase that has been ruined by diagrams. Ignore the diagrams. In practice it is a small set of written answers that any competent implementer will otherwise have to invent on your behalf during configuration workshops.
- Who decides what, at which threshold. Not job titles in a hierarchy — decisions with numbers on them. Who approves a credit limit of half a million. Who approves a variation order. Who releases a payment above a stated value. Who can override a stock reservation.
- What evidence a decision requires. A signed measurement sheet, a three-quote comparison, a costing that reconciles to the ledger. If the evidence is not defined, the system will ask for whatever the consultant made mandatory, and people will type anything into it.
- Where work is done. Centralised shared service, or at the entity. This single answer changes the chart of accounts, the approval matrix, the licence count and the headcount plan. Deciding it after selection means re-implementing.
- What the company is run on. The handful of numbers the executive committee will actually use, defined precisely enough that two departments cannot each produce a defensible version. If you have ever sat through a meeting where two teams reported different figures for the same month and both were right, you already know the cost of skipping this; it is the same pathology behind dashboards that are technically correct and still misleading.
None of this requires knowing which product you will buy. All of it changes what you should buy.
Process ownership means one name, not a department
"Finance owns it" is not ownership. A department cannot be in a meeting, cannot decide, and cannot be held to a date.
Every end-to-end process in scope needs one named person with three properties: they understand how the work is done today, they have the authority to change it, and they will still be in the role after go-live. If you cannot fill all three, that is the finding, and it matters more than any requirement in the document: the process runs on convention rather than on anybody's decision, and a system will not supply the missing authority.
Nominate the owners before selection, not after. Owners chosen after a contract is signed inherit decisions somebody else already made in a workshop, and they know it. That is the fastest way to turn a capable manager into an obstacle — and worth reading alongside why the people who resist hardest usually have the best reasons.
Somebody has to be allowed to say no
Every programme that ends badly has the same missing role: one person, named, whose job is to refuse scope.
Not the sponsor, who is too senior to be in the detail and too invested to refuse a colleague. Somebody with explicit written authority to say: that is a real requirement, it is not in this phase, and here is where it is recorded.
If nobody holds that authority, every request is accepted, because accepting is polite and refusing is not. Scope then grows quietly until the date slips, and the date slip is reported as a delivery problem rather than what it was — a governance vacancy that existed from week one. This is the part of the work we treat as non-optional when we sequence a transformation programme, because it is the cheapest control on the list and the one most often left unfilled.
Executive sponsorship is a schedule item, not a sentiment
Every programme claims executive sponsorship. Most have a sponsor who opens the kickoff, appears in the steering deck, and is unavailable for the months in which every consequential decision is taken.
Sponsorship is not enthusiasm. It is calendar time and decision latency, and both are measurable this week.
- Hours in the diary. Look at the sponsor's calendar for the next month. Count the hours committed to this programme. If the answer is one fortnightly status meeting, the programme has a spectator, not a sponsor. Decisions that need them will queue.
- Decision latency. From the day a decision is raised to the day it is made, in working days. Track it from week one and plot it. A rising line is the earliest reliable signal that a programme is in trouble, and it rises months before any milestone slips.
The useful version of sponsorship is unglamorous: a standing weekly hour with the authority to settle whatever has queued, and a written record of what was settled. A sponsor who gives that hour is worth more than one who gives a speech.
Sequencing: what has to be true before a platform question is even answerable
The platform question — which product, which partner, which edition — is answerable only after a specific set of decisions exist in writing. Asked earlier, it gets answered by demos, and a demo answers whichever question it was designed to answer.
| # | Stage | The question it settles | What done looks like | Skip it and |
|---|---|---|---|---|
| 1 | Decision rights | Who decides what, at which threshold | A written approval matrix signed by the people named in it | Configuration workshops become where decision rights get invented, by whoever turns up |
| 2 | Process ownership | Whose name is on each end-to-end process | One person per process, with authority to change it | Every design question escalates, and the implementer answers it by default |
| 3 | Baseline | What the work costs and how long it takes today | A handful of measures taken before anything changes, with the method written down | Benefits get decided retrospectively, by whoever writes the closing report |
| 4 | Constraints | What is genuinely non-negotiable — statutory, contractual, audit | A list where every line names its source document | Compliance arrives as a change request in month seven, at change-request prices |
| 5 | Redesign on paper | What the work should look like when it is done | The new process drawn with deleted steps marked as deleted | You automate the current process, faster and at greater cost |
| 6 | Data reality | Whether the data can support the redesign | A profile of the master data, and a named owner per domain | The go-live date is set by a data problem discovered in month nine |
| 7 | Platform selection | Which instrument fits the decisions already made | A shortlist scored against your redesign, not against feature lists | The demo writes your requirements |
| 8 | Phasing | What goes live first, and what it pays for | Each phase usable on its own and funding the next | One big date that slips as a single object, taking everything with it |
Two notes on that table, because they are where the money is.
Stage 3 is the one people skip and the one that decides how the programme is judged. If you did not measure the close, the order-to-cash cycle or the cost per invoice before, you cannot claim an improvement after, and everyone in the room knows it. Baselines are cheap in month zero and impossible in month twelve.
Stage 6 is where timelines actually die. Not in configuration. Anyone who has watched a programme lose a quarter to duplicate customers and unfilled mandatory fields will recognise the pattern in what data migration does to a project timeline. The redesign you drew at stage 5 assumes data your systems may never have captured.
Only at stage 7 does the product question become sensible — and by then it is a much smaller question, because the decisions have narrowed the field more than any feature comparison would have. If you are approaching that point, the vendor-neutral guide to choosing an ERP in the UAE covers the selection itself, including how to run a demo that answers your questions instead of the vendor's.
How to tell it is failing while there is still time to act
Programme reporting is built from lagging indicators: milestones, percentage complete, budget consumed. All three stay green until the moment they cannot. The signals below appear weeks or months earlier, and every one can be observed without asking anyone to admit anything.
| Signal you can observe this week | What it usually means | What to do about it |
|---|---|---|
| Decision latency is rising week on week | The decision rights are wrong, or the sponsor is not in the room | Fix the matrix, or book the standing hour. Do not add a governance layer |
| No step has been deleted from any process | This is a re-platform wearing a transformation label | Force the deletion question per process, in writing, with an owner |
| "Phase two" is being used to end arguments | Scope is being deferred into a phase with no date, budget or owner | Give phase two a date and a budget, or refuse the item honestly |
| Steering committee members send delegates | The people with authority have decided this is not their problem | Cancel the meeting and replace it with fewer, shorter, decision-only sessions |
| Requirements exist that no named person owns | Nobody will defend them at cut-over, and nobody will use the result | Assign or delete. An unowned requirement is scope with no sponsor |
| Training is being scheduled before process decisions are signed | The programme is filling time it does not know how to use | Move training after sign-off. Training on a process that then changes destroys trust |
| The spreadsheet count is not falling — or nobody is counting | The old process is still the real process | Keep an open register of shadow spreadsheets and chat approvals, and report the count |
| Progress is reported as configuration completeness | Configured is not adopted; you are measuring the easy half | Report on transactions posted by real users in a real process |
| Nobody has said no to anything all quarter | Either the plan was perfect, or there is no refusal authority | Name the person who can refuse scope, in writing |
Two of these deserve a note.
The spreadsheet register is the most honest instrument in a transformation programme: an open list of every spreadsheet, chat thread and paper form doing work the system is supposed to do. Its count is the truest adoption measure available, it costs nothing, and it is uncomfortable enough that most programmes quietly stop maintaining it — which is itself the signal.
And "configured is not adopted" is the one that survives go-live. The period in which a programme is genuinely at risk is not the launch weekend but the weeks after it, when the workarounds either die or become permanent; what happens in the first ninety days determines which.
You have already bought the platform. Now what.
Most people reading this are past the signature. The licences are paid, the partner is on site, and the contract is not being unwound. That is a workable position, and it does not require pretending the sequence above was followed.
Accept that the licence is sunk and decides nothing. The product you own constrains how things will be done. It does not decide what the business does, who approves it, or what stops. Those decisions are still open, and they are still yours. Nothing in a signed contract obliges you to reproduce the current approval chain.
Stop configuration where the operating decision has not been made. Not the whole programme — the specific areas where the design is being drafted by someone with no authority to set it. Every hour of configuration built on an unmade decision is an hour that will be rebuilt.
Write the decisions retrospectively, fast. The approval matrix, the process owners, the refusal authority, the handful of numbers the business will be run on. This is days of work, not months, when the people involved are the right ones. If it takes months, the delay is the finding.
Triage scope against the go-live gate. Split everything into what must be live to keep the business legal and trading, what makes the process genuinely different, and what was requested because a demo made it look attractive. Fund the first two. Record the third somewhere it can be argued for later on its own merits.
Take a baseline now, even a late one. A measurement taken this month is imperfect and infinitely better than an argument next year about whether things improved.
Get an independent read before the next phase is funded. If the numbers coming out of your existing systems already disagree with each other, integrating them will faithfully carry both versions forward — which is the trap set out in what goes wrong when you connect systems that disagree. Establishing which system holds the truth, who owns each data domain, and where the licence spend is actually going is the substance of an independent audit of what your systems are doing, and it is considerably cheaper before a phase is funded than after.
None of that requires a new contract, a new vendor, or an admission in a board meeting. It requires deciding things that are currently undecided.
The question worth asking on Monday
Pick one process in the programme's scope. Ask the person who owns it — the named person, not the department — a single question:
"When this is live, which step disappears, and who stops being asked?"
If they can answer in a sentence, the programme is doing transformation work and the platform is serving it.
If the answer is that the same steps will happen in a better system, you now know exactly what you are buying. That may still be the right purchase. But price it as a system replacement, judge it as a system replacement, and stop expecting it to change the company.
The instrument was never the decision.