Digital Transformation Services in Saudi Arabia: What You Are Buying, and What Sets the Price

Transformation budgets can overrun when the buyer and the provider have not agreed on what is being bought. The same phrase can cover three different things with materially different costs, so if the requirement is not defined first, proposals may price different interpretations of one request.

So work in this order: specify which of the three levels you are buying, fill in the readiness matrix below, then ask for a proposal. That sequence reduces ambiguity before pricing, and it makes proposals comparable because they are written against the same description.

Name the level before you request a proposal

Three levels are sold under one name:

• Digitization — paper becomes digital. Contracts are scanned and stored. The procedure itself does not change.
• Technical modernization — an older system is replaced by a newer one, and the process stays as it was. HR moves to the cloud; hiring steps are untouched.
• Digital transformation — the process, the decision and the customer experience change together, and the change is measured.

What you do with this: state which of the three you are asking for in the first line of your RFP. A proposal that describes level three, prices level three and delivers level one is a gap you will discover after handover, not before it.

Three questions can help distinguish the levels in practice: Did anyone's daily steps change? Is a decision now made from data instead of judgement? Did a number you were measuring before the project move? Three “no” answers suggest that you may have bought a tool rather than delivered a transformation, whatever the contract called the project.

A digital transformation readiness matrix

AY prepared this matrix for this guide, and it is set out here for you to use yourself. There are ten questions worth answering before requesting a proposal. They do not carry equal weight: one unanswered question can be enough to defer the request if it touches a security or regulatory requirement or a critical dependency, while three lower-impact gaps may reasonably be handled inside a paid discovery phase. Judge by impact rather than by count.

What you do with this: take it to your own team first, not to a provider. The rows you cannot fill are your assessment scope, and they are also the rows a provider will price as risk. Answering some of them yourself reduces the uncertainty a provider would otherwise have to price.

What actually sets the price

Price in this work is not set by screen count. It is set by five things, and you control three of them before any proposal is written:

1. The state of your data. Inconsistent definitions across systems are a cost item that is often underestimated. Cleaning a sample before the proposal changes what a provider can estimate against.
2. How many systems the solution must integrate with. Each integration adds testing and maintenance, not just development hours.
3. Whether the process is agreed. A process that has not been agreed may be redesigned during delivery, creating additional cost — and where the answer is to rebuild rather than configure, custom software development is the scope that gets priced.
4. The regulatory surface. Personal data, payments and regulated activity each add controls that must be designed in, not added later.
5. What happens after go-live. Support, operation and continued development are ongoing costs. A proposal that omits them may cover handover only rather than the full operating requirement.

What you do with this: require every proposal to price the post-go-live line separately and explicitly, and compare proposals on that line first. It is the line that reveals who estimated a project handover and who estimated running a system.

On pricing models: a fixed price transfers risk to the provider and works when the scope is genuinely fixed — which the matrix above helps you judge. It should state what it is fixed against: the deliverables, the assumptions and the exclusions. Time and materials fits work where the scope is still being discovered, and needs a spending cap and a defined exit point. Neither model rescues an unagreed process.

The obligations that change the design, not the paperwork

Regulatory requirements matter here for one reason: three of them change what you must ask for in the specification, and adding them to a finished system is a redesign rather than a feature.

Personal data. Saudi Arabia's Personal Data Protection Law grants data subjects rights that systems may need to support, subject to the law, its implementing regulations and applicable exceptions. In practice, your system may need to locate a person's records, restrict and log access to them, and support responses to relevant requests within the required period. Include these capabilities in the system requirements rather than relying only on a separate policy. Confirm which requirements apply to your activity through a regulatory review rather than a general checklist.

Security controls. The National Cybersecurity Authority's Essential Cybersecurity Controls are among the relevant references, subject to their scope of applicability. What that means practically: make the controls part of your acceptance criteria rather than a final review, and watch the parallel-running period between the old and new systems — controls may be weakened during the transition even though data may exist in two places, so the parallel-running period requires explicit safeguards.

Hosting. Applicable cloud cybersecurity controls may assign responsibilities to both the provider and the subscriber; contractual terms do not necessarily remove obligations imposed by law or regulation. Hosting requirements can depend on data classification, national data-governance rules and sector-specific obligations. Confirm what applies to your case through a regulatory review. What you do with this: classify your data before deciding where it will be hosted, because classification helps determine the permitted destination and reduces the risk of paying for a second migration. The full authority map, and what each one expects you to be able to prove, is the subject of its own guide. Where the decision lands on the hosting layer itself, cloud and IT infrastructure covers it.

What to measure, and when to record it

A measurement failure worth guarding against is not choosing the wrong indicator. It is recording the baseline only after the project has started, which weakens any later comparison — the figure you measure against then includes part of the change itself.

Pick indicators from the process you are changing, not from a generic dashboard. A practical starting set includes three types: a duration (how long the process takes end to end), a quality figure (rework, errors, cancellations), and an adoption figure (share of work done inside the designed process rather than around it).

What you do with this: record a baseline before you sign, over a period and sample that represent the process. Two weeks may suit a high-frequency daily process; a seasonal or monthly cycle needs longer, and a low-volume process may need a different approach altogether. Record the method and its limits alongside the number.

If a pre-change baseline is not available, say so and choose a substitute deliberately: reliable historical records, a sample reconstructed from system logs, or a comparison against a similar process. Disclose the uncertainty rather than dropping measurement — an imperfect baseline still supports a defensible comparison if its limits are stated. Note also that collecting it is not free: it takes staff time, and sometimes access approvals and data-handling checks.

On how long results take: a duration quoted before reviewing your data, integrations and process is not a reliable estimate. Where feasible, scope an early complete, measurable result within 90 days; longer initiatives should include interim evidence so that schedule and budget risks remain visible.

Three failures that recur regardless of the technology

No owner on your side. A project owned only by the provider produces something technically correct that does not match how the work is done. What you do: name one owner in your organisation with the authority to settle process disputes, and allocate dedicated time rather than adding the role to an already full workload.

Running both systems indefinitely. Keeping the old way "as a backup" means people keep using it. What you do: define retirement criteria and a target date for the old process as part of the go-live plan, allowing only the parallel-running period the transition requires.

Training on buttons instead of on the method. A session that explains screens does not change behaviour; changing what is asked of people and what they are measured on does. What you do: identify which old tasks should stop as new ones are introduced, and adjust the team's targets for the transition period.

Resistance to change may reflect these issues rather than being a separate obstacle. It can also be a reasonable response: for the person doing the work, a new system is a cost before it is a benefit.

The adjacent decisions, and where they are made

• Which of my existing systems do I keep, replace or retire? The digital modernization guide.
• Who decides what once the change lands? The digital operating model guide.
• How do I evaluate and compare transformation companies? The guide to choosing a transformation company.
• Do I build this capability in-house or buy it? The guide to choosing a transformation provider.
• How do I get this approved and funded internally? The transformation business case guide.

How AY works

AY works in this specific area: scoping digital transformation for enterprises and government entities, then building and running the systems. The principle this guide recommends is the one we work to — settle which level is being bought, and close what can be closed of the readiness questions, before pricing. A price built against an undefined scope is likely to change later.

Scope, pricing and post-go-live arrangements are agreed per engagement. Put the questions this guide suggests to us as you would to any provider — they were written to be used that way. Examples of delivery are in our work, and the scope is set out in enterprise digital transformation.

This article is not a substitute for regulatory review: which requirements apply to a specific organisation depends on its activity and its data.

Next step

Fill in the matrix with your own team and start recording one baseline indicator. Neither needs a supplier, though both take staff time and the baseline may need access approvals — and together they can improve the quality of the proposals you receive afterwards.

If rows stay empty and their impact on scope, security or dependencies is material — typically the data, integration and ownership rows, because answering them requires inspecting systems rather than asking people — that is the point at which involving an outside party becomes useful. Talk to us about whether an assessment fits your case and what it would cover — the scope and outputs of any assessment are agreed before it starts rather than assumed in advance.