diseño estratégico • Gobernanza UX
Regionalización de Plataforma Operativa
Un mismo producto, cinco países, una pregunta ¿qué se decide como core y qué queda local?
01
Contexto
Dentro de Cencosud, trabajé en una plataforma interna orientada a mejorar la operación en tienda, con alcance regional. No era solo una app, sino un ecosistema operativo usado por distintas unidades de negocio y países.
A medida que la plataforma creció, cada país y unidad de negocio fue resolviendo sus necesidades a su propio ritmo, con procesos, prioridades y niveles de madurez distintos. Finalmente, un mismo producto operando de múltiples maneras, sin un modelo común que definiera qué se decidía localmente y qué a nivel regional.
5
países
Argentina, Brasil, Colombia, Chile y Perú
3
Unidades de negocio
Supermercado, Mejoramiento del hogar y Tiendas por departamento
4
funcionalidades
Seleccionadas para pilotear el modelo
02
El desafío
Construir una forma más ordenada, escalable y gobernable de evolucionar a nivel regional.
Qué debía ser común para toda la región, qué podía adaptarse localmente y bajo qué condiciones.
El problema de fondo era que cada país y unidad de negocio tenía necesidades, procesos, velocidades y prioridades distintas. Sin un modelo común, existía el riesgo de terminar con múltiples versiones de la plataforma: difíciles de mantener, con baja reutilización y mayor deuda técnica.
03
El problema principal
Como lograr el punto de equilibrio donde cada extremo resuelve algo real y sacrifica algo real.
Regionalizar para escalar
Consistencia, eficiencia y reutilización pero asumiendo el riesgo de imponer un modelo único teniendo en consideración diferencias operativas y culturales.
vs.
Adaptar a lo local
Cercanía al contexto y respueestas ajustadas a cada mercado pero dificiles de escalar, gobernar y mantener haciendo que aumente la deuda técnica de la región.
Desde UX, la mirada fue pragmática. Más que defender un extremo, se trataba de poner criterio explícito sobre cada decisión:
No todo debe ser regional.
No todo lo local está justificado.
La decisión debe basarse en operación, regulación, cultura, datos, factibilidad técnica y valor de negocio.
04
Marco de decisión regional o local
Para destrabar la discusión, definimos qué tipo de elementos se repetían regionalmente y cuales efectivamente correspondían a lo local.
regional
- Flujo core
- Patrones comunes
- Componentes reutilizables
- Capacidades transversales
- Design System y estándares
- Integraciones core
Local
- Regulaciones específicas
- Particularidades operativas
- Diferencias culturales validadas
- Prioridad local concreta
- Adaptaciones necesarias por país
- Flujos excepcionales
06
Qué hice
El rol de UX no se limitó al diseño de interfaces, sino fue un rol estratégico, sistémico y de articulación entre negocio, producto, tecnología y operación. Vital en todo este proceso.
Levantamiento de información entre países y unidades de negocio
Análisis de funcionalidades existentes e identificación de capacidades digitales comunes.
Definición de criterios para regionalizar o localizar
Alineamiento con Producto, Tecnología y stakeholders regionales
Documentación de los flujos por país y unidad de negocio
06
Entregables y artefactos
Este modelo se apoyó en distintos artefactos de análisis, documentación y alineamiento que hicieron las decisiones explícitas y comparables entre países.
Mapa regional de funcionalidades
Matriz que cruzaba funcionalidades y capacidades digitales por país y unidad de negocio.
Base regional de análisis
Estructura para ordenar qué existía, dónde existía, qué era común, qué era particular y qué podia escalar.
Criterios regionales / locales
Marco de decision para determinar si una funcionalidad debía tratarse como estándar regional o como adaptación local.
Research por país
Levantamiento específico para entender procesos, diferencias operativas y nombres de funcionalidades existentes en cada mercado.
Diseñar para cinco países es diseñar para cinco realidades distintas.
Empatizar, escuchar y trabajar en equipo es vital.