Operational Platform Regionalization

strategic design • ux governance

One product, five countries, one question: what should be common and what should stay local?

Context

Within Cencosud, teams worked with an internal platform created to improve store operations, with regional reach. Not just an app, an operational ecosystem used by different business units and countries.

As the platform grew, each country and business unit resolved its own needs in isolation. This generated a constant tension: the same digital capability looked and worked differently depending on the country — even within the same business unit.

5

countries

Argentina, Brazil, Colombia, Chile and Perú

3

business units

Supermarket, Home improvements y Department Stores

4

functionalities

Prioritized to pilot the model

The challenge

Creating a more orderly, scalable and governable way to evolve the platform at a regional level.

What should be common across the entire region, what could be adapted locally and under what conditions

The problem was that each country and business unit had different needs, processes, speeds, technical maturity and priorities. Without a shared model, there was a risk of ending up with multiple versions of the platform: difficult and expensive to maintain, with low reuse and greater technical debt.

The main issue

Find the balance where every point solves something real and sacrifices something real.

Regionalize to scale

Consistency, efficiency and reuse for an increased risk of imposing a single model without considering operational, cultural differences.

vs.

Adapt to local

Closeness to context and local market responsiveness — but difficult to scale, govern and maintain, increasing the debt that grows the platform.

rom UX, the approach was pragmatic. More than defining an extreme, it was about setting a specific criteria for each decision:

Not everything should be regional.

Not everything local is justified.

The decision should be based on operation, regulation, culture, data, technical feasibility and business value.

Regional or local decision framework

To facilitate the decision, we defined what types of elements are repeated regionally and what is more effectively addressed locally.

regional

Core flow
Common patterns
Reusable components
Cross-cutting capabilities
Design System y standards
Core integrations

Local

Specific regulations
Operational particularities
Validated cultural differences
Concrete local priority
Country-specific adaptations
Exceptional flows

What I did

My role was not limited to interface design. It was a strategic, systemic and articulating role between business, product, technology and operations. In total, my work involved:

Information gathering across countries and business units

Analysis of existing functionalities and identification of common digital capabilities

Definition of criteria for regionalizing or localizing

Alignment with Product, Technology and regional stakeholders

Documentation of flows by country and business unit

Deliverables and artifacts

This model was supported by different analysis, documentation and alignment artifacts that made decisions explicit and comparable across countries.

Regional functionality map

Matrix that crosses functionalities and digital capabilities by country and business unit.

Regional analysis base

Structure to organize what exists, where it exists, what is common, what is particular and what can scale.

Regional / local criteria

Decision framework to determine whether a functionality should be treated as a regional standard or local adaptation.

Country research

Specific information gathering by country to understand processes, operational differences and names of existing functionalities in each market.

Designing for five countries is designing for five different realities.

Empathizing, listening and working as a team is vital.