A transformation programme in Frankfurt and a transformation programme in Tashkent can carry the same name, the same vendor, and the same slide deck, and be entirely different undertakings.
The difference is not sophistication. It is that frameworks designed in mature markets assume conditions that do not hold across the MENA and Eurasian corridors: stable local currency, dense integration partner ecosystems, mature data infrastructure, harmonised regulation, and a labour market where the required specialists can be hired. Remove those assumptions and the standard sequencing produces expensive systems nobody uses.
This is a field guide for growth-stage enterprises operating across these corridors — written around what actually constrains the decision.
Start from the constraints, not the roadmap
Four constraints shape almost every programme in these markets.
Currency volatility makes multi-year software commitments a treasury decision. A licence priced in dollars against revenue earned in local currency is an unhedged position that grows for the length of the contract. The finance question — what happens to this cost line at a thirty per cent devaluation — must be answered before the vendor question.
Integration capacity is scarcer than software. Enterprise platforms are available everywhere. Teams that can implement them well, locally, in the client's language and time zone, are not. The realistic constraint on programme scope is implementation capacity, not budget.
Regulation is fragmented and moving. Data localisation requirements, e-invoicing mandates, and sector rules differ by country and change on short notice. A single regional instance that is compliant today may not be next year in one of five jurisdictions.
Process maturity varies more than in mature markets. A group operating in six countries may run six genuinely different versions of the same process, some of them undocumented. Standardising them is organisational work, and it is usually the longest task in the programme regardless of what the plan says.
The sequence that works
The common failure is starting with the most visible layer. Customer-facing digital work is easiest to fund and demonstrate — and it is built on data the organisation frequently does not yet have in usable form.
A more reliable ordering:
First: transactional integrity. Financial and operational records that are complete, timely, and reconciled. Every subsequent layer inherits the quality of this one. An analytics platform built on data nobody trusts becomes a second source of disputed numbers rather than a source of truth.
Second: process standardisation. Before automating a process, it must exist in one version. Automating six divergent variants produces six automated variants and a permanent maintenance burden.
Third: integration. Systems exchanging data without manual re-entry. This is where measurable operational gain usually first appears, and it is chronically underfunded because it produces nothing anyone can demonstrate in a meeting.
Fourth: analytics. Meaningful only after the first three. Analytics on unreliable data is expensively packaged guesswork.
Fifth: customer-facing digital. Portals, apps, self-service. These depend on everything above. A customer portal showing inventory the ERP cannot confirm damages trust faster than having no portal.
This ordering is regularly overridden by boards who want visible progress. It can be resequenced — but the dependency does not disappear, and the cost of ignoring it is paid later at a premium.
Build, buy, or postpone
Most decisions are framed as build versus buy. The third option is the most valuable and the least considered.
Buy for anything standardised and non-differentiating: accounting, payroll, HR administration, email, storage. Nobody in a regional trading group is winning on payroll software. Buy the market standard, accept its constraints, and preserve implementation capacity for elsewhere.
Build only where the process is genuinely differentiating and no adequate product exists. In these corridors, that is most often at the integration and workflow layer — connecting local banking, customs, or logistics systems that international vendors do not support. This is real, defensible engineering work.
Postpone anything whose prerequisites are not in place. Explicitly, on the record, with the prerequisite named and a review date attached. A postponed initiative with a documented dependency is a managed decision. The same initiative launched into its missing prerequisite is a write-off.
The hardest of these is postponement, because it looks like a lack of ambition. It is the opposite: it concentrates a scarce implementation resource on work that can actually complete.
Vendor orchestration in thin markets
Enterprises in these corridors typically end up with more vendors than they intended — a global platform vendor, a regional implementation partner, one or two local specialists per country, and a domestic provider for anything with a localisation requirement.
That is not necessarily bad. It becomes bad when nobody owns the seams.
One accountable integrator. Not necessarily the largest vendor — the one that owns end-to-end delivery and cannot redirect a failure to another party. Multi-vendor programmes without single-point accountability fail in the gaps, and the gaps belong to nobody.
Contract in the currency of the revenue it supports, or hedge the exposure deliberately. This is a treasury position whether or not anyone treats it as one.
Local presence is a delivery requirement, not a preference. Remote-only implementation partners in markets with language, regulatory, and relationship-driven business practices consistently underdeliver.
Test exit before entry. Data export format, migration path, contractual termination terms. Vendors are rarely selected on exit terms and are frequently regretted on them.
The operating model question
The structural decision behind all of this: centralise or federate.
Full centralisation — one instance, one process, one team — delivers the cleanest data and the lowest unit cost. It also collides with local regulatory divergence and drives significant local workaround activity where the central system does not fit the market.
Full federation — each country running its own stack — fits local conditions and makes group-level anything nearly impossible. Consolidated reporting becomes a monthly manual exercise.
Most groups in these corridors land, correctly, in between: centralised finance and reporting core, federated local operations, with a defined and enforced integration contract between the two. The success condition is that the boundary is explicit and governed. Where the boundary is implicit, it moves — usually toward whichever team last escalated.
Measurement discipline
Transformation programmes are notorious for unmeasurable benefit claims. Three practices help.
Establish the baseline before the programme starts. Cycle times, error rates, headcount per transaction, days to close. After deployment, the baseline is unrecoverable and every claim becomes an assertion.
Measure adoption separately from deployment. A system that is live and a system that is used are different states. Track actual usage — logins, transactions processed in-system, workarounds still running in spreadsheets.
Report the programme's failures. A transformation report with no failures is not a report on a real programme, and senior audiences know it. Credibility is what buys continued funding, and it comes from the negative results.
Where to start
For a growth-stage enterprise across these corridors: audit the transactional layer honestly, standardise the processes that must be standardised, fix integration before buying analytics, and postpone anything whose prerequisites are missing — explicitly, with the dependency named.
That is a less impressive-sounding programme than a full-stack transformation. It also completes, which most of the alternatives do not.
Our advisory approach across technology stack selection, vendor orchestration, and operating model design is set out under business units, with engagement detail in our case studies and further analysis under Insights. To discuss a specific programme, contact us.
