El contexto: el retail mexicano ante la revolución digital
El retail en México vive una transformación sin precedentes. La pandemia de 2020 aceleró en años lo que debió haber tomado una década. Los consumidores mexicanos descubrieron que podían comprar todo en línea: desde despensa hasta electrónica, desde ropa hasta medicamentos. Y no volvieron atrás.
Según la AMVO (Asociación Mexicana de Venta Online), el comercio electrónico en México alcanzó más de 750 mil millones de pesos en 2025, representando más del 15% de las ventas minoristas totales. Para 2026 se proyecta que supere los 900 mil millones. Los retailers que no tienen una operación digital sólida no solo están perdiendo cuota digital, están perdiendo clientes que esperan una experiencia omnicanal fluida.
Pero aquí está el problema: tener una tienda en línea es la parte fácil. Lo verdaderamente complejo es orquestar el inventario en tiempo real de cientos de sucursales, la logística de última milla, el fulfillment desde tienda (ship from store), click and collect, devoluciones omnicanal, y todo esto sincronizado con el ERP que maneja la contabilidad, las compras y los proveedores.
Soriana enfrentó este desafío y lo resolvió con una decisión arquitectónica clara: cada plataforma haciendo lo que mejor sabe hacer. Salesforce para experiencia de cliente, Azure para sistemas custom de orquestación, y SAP estrictamente para lo que SAP brilla. La historia tiene lecciones valiosas para cualquier empresa mexicana en el camino de la transformación digital.
---
El desafío de Soriana: escalar e-commerce sin romper la operación
Soriana es una de las cadenas de supermercados más grandes de México con más de 800 tiendas en todo el país, incluyendo formatos como Soriana Súper, Soriana Híper, MEGA Soriana, City Club y Sodimac. Con más de 100,000 empleados y operaciones en prácticamente todos los estados, cualquier cambio tecnológico tiene implicaciones masivas.
Los problemas específicos que enfrentaban
Front-end de e-commerce limitado. El sitio web existente no soportaba la velocidad de innovación que el mercado exigía. Cada cambio de UI tomaba semanas. Personalización por cliente, campañas segmentadas y experimentación A/B eran imposibles a la escala que el negocio requería.
Inventario fragmentado. Cada tienda manejaba su inventario de forma relativamente independiente. El sitio web no tenía visibilidad en tiempo real del stock disponible en cada sucursal. Esto generaba ventas de productos no disponibles, cancelaciones que frustraban al cliente y pérdida de ingresos por productos que sí estaban disponibles pero el sistema no lo mostraba.
Fulfillment ineficiente. Los pedidos en línea se procesaban con workflows manuales que involucraban llamadas telefónicas a las tiendas, verificación manual de disponibilidad y asignación de pedidos basada en reglas simples de proximidad sin considerar la capacidad real de cada punto de fulfillment.
Sin visión omnicanal del cliente. Un cliente que compraba en tienda física y también en línea era tratado como dos personas diferentes. No había historial unificado de compras, no se podían ofrecer promociones consistentes entre canales y la experiencia de devolución era diferente según el canal de compra original.
Operación de última milla costosa. La logística de entrega a domicilio operaba con procesos heredados que no optimizaban rutas, no ofrecían visibilidad en tiempo real del estado de entrega y tenían costos por pedido que hacían insostenible la operación de delivery sin un margen significativo.
SAP saturado intentando ser todo. El intento previo de extender SAP para soportar e-commerce a la velocidad del canal digital generaba cuellos de botella. SAP es extraordinario para finanzas, compras y operaciones, pero no fue diseñado para responder miles de peticiones de disponibilidad por segundo ni para orquestar la lógica de fulfillment de pedidos omnicanal.
---
La decisión arquitectónica: cada sistema en su rol justo
La decisión más importante del proyecto no fue de tecnología sino de arquitectura: dejar de exigirle a cada sistema cosas que no fue diseñado para hacer.
La conclusión fue clara: Salesforce para todo lo que tiene que ver con experiencia del cliente y omnicanalidad. Azure como plataforma para construir los sistemas custom de orquestación (OMS, TMS, pasarelas de pago) donde se necesita control absoluto y velocidad de iteración. SAP estrictamente para lo que SAP es insuperable: master data, órdenes de compra y la columna vertebral financiera de la empresa.
Esta separación no fue gratuita. Implicó reescribir la integración entre sistemas, capacitar al equipo de operaciones en herramientas nuevas y resistir la tentación de "tirar todo a SAP" que es la inercia natural en empresas con un ERP maduro. Pero permitió que cada plataforma operara dentro de sus fortalezas y que el equipo de TI dejara de pelearse contra las limitaciones del stack.
---
Arquitectura técnica detallada
Componentes principales del nuevo stack
| Capa | Plataforma | Responsabilidad |
|---|
| Front-end e-commerce | Salesforce Commerce Cloud | Sitio web, app, catálogo de cara al cliente, carrito, checkout |
|---|---|---|
| CRM y atención al cliente | Salesforce Service Cloud | Casos de soporte, vista 360 del cliente, omnicanalidad |
| Order Management System | Custom en Azure | Orquestación de pedidos, ruteo inteligente, promesa de entrega |
| Transportation Management System | Custom en Azure | Ruteo logístico, asignación de transportistas, tracking |
| Pasarelas de pago | Custom en Azure | Integración con procesadores, manejo de tokenización, antifraude |
| ERP | SAP | Master data de catálogo, órdenes de compra a proveedores, contabilidad, CFDI |
| Capa de integración | Azure Service Bus + APIs REST | Eventos asíncronos + queries síncronas entre sistemas |
Infraestructura cloud
Todo el stack custom (OMS, TMS, pasarelas, integraciones) corre en Microsoft Azure. Se eligió Azure por la afinidad operativa del equipo de TI, la integración nativa con el directorio corporativo y la madurez de servicios como Azure Service Bus, Functions, App Service y Cosmos DB para las cargas variables del e-commerce. La escalabilidad automática es crítica durante picos como Hot Sale, Buen Fin o temporada navideña, donde el tráfico puede multiplicarse por 10 en horas.
Salesforce Commerce Cloud aporta su propia infraestructura multi-tenant. SAP corre en su entorno tradicional, con conectividad segura hacia Azure para las integraciones.
---
Salesforce Commerce Cloud como front-end omnicanal
La plataforma de cara al cliente — sitio web, app móvil, experiencia de checkout — corre sobre Salesforce Commerce Cloud. La decisión de usar Salesforce no fue por costo (no es la opción más barata) sino por capacidades:
Velocidad de iteración. El equipo de e-commerce puede lanzar campañas, modificar layouts, probar nuevas experiencias en horas en lugar de semanas. Salesforce Commerce Cloud ofrece herramientas low-code para que el equipo de marketing modifique el sitio sin esperar a TI.
Personalización. El motor de personalización de Salesforce usa el historial de cada cliente para mostrar productos relevantes, promociones segmentadas y experiencias diferenciadas por perfil. Esto es prácticamente imposible de construir desde cero a la calidad que ofrece el producto.
Integración con Service Cloud. El soporte al cliente vive en Salesforce Service Cloud. Cuando un cliente llama por un problema con su pedido, el agente ve la información completa del pedido (que vive en el OMS de Azure) gracias a la integración bidireccional. El cliente nunca tiene que repetir información.
Omnicanalidad nativa. Los datos del cliente — historial de compras online y offline, interacciones en redes sociales, casos abiertos en soporte — viven unificados en Salesforce. Esto habilita capacidades imposibles antes: programa de lealtad consistente entre canales, devoluciones omnicanal, marketing automatizado basado en comportamiento real.
Salesforce Commerce Cloud delega el cálculo de disponibilidad real, el ruteo de pedidos y la promesa de entrega al OMS custom en Azure a través de APIs REST. Salesforce muestra al cliente lo que el OMS le dice que es posible.
---
OMS custom en Azure: el cerebro de la operación
El Order Management System es la pieza más estratégica de la arquitectura. Se construyó como aplicación custom en Azure porque las reglas de negocio de Soriana son específicas, evolucionan rápido y necesitan control total. Ningún OMS comercial empaquetado se adapta bien a la complejidad de 800 tiendas con formatos heterogéneos, dark stores y centros de distribución regionales.
Disponibilidad de inventario en tiempo real
Cuando un cliente busca un producto, la consulta de disponibilidad no va directamente a SAP (que no está diseñado para responder miles de consultas por segundo de forma eficiente). En su lugar, el OMS mantiene una vista agregada y optimizada del inventario de toda la red, actualizada en tiempo real a través de eventos publicados desde SAP al Service Bus de Azure. Esta vista considera no solo el stock físico sino también el stock reservado por pedidos en proceso, stock dañado o en cuarentena, stock en tránsito, y reglas de safety stock de cada ubicación que preservan producto para clientes de tienda.
Ruteo inteligente de pedidos
Cuando un cliente completa un pedido, el OMS decide automáticamente desde qué punto se va a surtir. Esta decisión considera la distancia entre el punto de fulfillment y la dirección de entrega, la disponibilidad completa del pedido en cada punto para minimizar envíos parciales, la capacidad de picking actual de cada tienda, el costo logístico de cada opción, y prioridades de negocio como preferir fulfillment desde dark stores para no afectar la experiencia en tienda.
Promesa de entrega dinámica
Antes del OMS la promesa era genérica ("entrega en 2 a 5 días hábiles"). Con el OMS la promesa se calcula en tiempo real para cada pedido considerando disponibilidad específica, capacidad logística actual, distancia y condiciones operativas. El resultado es una promesa más precisa y, más importante, una promesa que la empresa puede cumplir consistentemente.
Gestión de excepciones
Productos que se agotan entre el pedido y el picking, repartidores que no pueden entregar, clientes que quieren modificar su pedido. El OMS gestiona todas estas excepciones con reglas automatizadas: reasignar a otro punto de fulfillment si el producto no está disponible, notificar al cliente automáticamente si hay retraso, ofrecer alternativas o cancelación parcial cuando corresponde.
---
TMS y pasarelas de pago en Azure
Igual que el OMS, el TMS (Transportation Management System) y las pasarelas de pago se construyeron como aplicaciones custom en Azure. Las razones son las mismas: control de reglas de negocio específicas, velocidad de iteración y costos de operación predecibles a escala.
TMS en Azure
El TMS recibe los pedidos asignados desde el OMS y los convierte en órdenes de transporte óptimas. Considera la flota propia, transportistas externos, las restricciones de cada zona (peso, dimensiones, ventanas horarias) y optimiza rutas usando algoritmos que evolucionan con los datos de operación real. Da visibilidad en tiempo real del estado de cada entrega (tomado, en ruta, entregado) tanto al cliente como al backoffice.
Pasarelas de pago
Soriana procesa millones de transacciones por mes. Construir una capa propia de pasarelas permite negociar mejor con los procesadores, implementar lógica antifraude específica para el comportamiento de compra de retail, manejar tokenización propia para clientes recurrentes y abstraer al e-commerce del procesador específico de cada transacción. La capa de pagos integra múltiples procesadores y enruta cada transacción al más eficiente según el método de pago, BIN, monto y perfil del cliente.
---
SAP en su rol justo: master data y purchase orders
Una de las decisiones más contraintuitivas pero más impactantes fue reducir la responsabilidad de SAP. En el stack viejo, SAP intentaba ser todo: master de catálogo, motor de inventario en tiempo real, calculador de precios, generador de facturas y orquestador de pedidos. El resultado eran transacciones lentas y un SAP saturado.
En el stack nuevo, SAP hace lo que SAP hace mejor:
Master data de catálogo. SAP sigue siendo la fuente de verdad para el catálogo maestro: descripción de productos, atributos, categorización, jerarquía mercadológica. Los cambios en SAP se propagan a Salesforce Commerce Cloud (PIM + catálogo de cara al cliente) y al OMS (para reglas de fulfillment).
Órdenes de compra a proveedores. SAP gestiona la relación con miles de proveedores, las negociaciones de precio, las órdenes de compra, recepción de mercancía y los pagos. Esto es operación core de retail y SAP es insuperable en este dominio.
Contabilidad y CFDI. Todas las transacciones de venta (que ocurren en el OMS) y de compra (que ocurren en SAP) se consolidan en SAP para contabilidad, conciliación, reportería financiera y emisión de CFDI. SAP sigue siendo el cierre contable y el sistema de récord financiero.
Lo que SAP YA NO hace: servir el catálogo al sitio web en tiempo real (lo hace Salesforce con datos sincronizados desde SAP), calcular disponibilidad para el cliente (lo hace el OMS con su vista optimizada), orquestar fulfillment (lo hace el OMS), generar la promesa de entrega al cliente (lo hace el OMS), procesar pagos del e-commerce (lo hacen las pasarelas en Azure).
Esta separación libera a SAP de cargas para las que no fue diseñado y le permite hacer su trabajo correctamente. Y libera al equipo de TI de pelear contra las limitaciones de SAP en dominios donde existen mejores herramientas.
---
Integración: el proyecto más subestimado
La integración entre Salesforce, Azure y SAP es donde reside la complejidad real del proyecto. Es lo que determina si la experiencia del cliente es fluida o llena de fricciones.
Flujos principales
Catálogo SAP → Salesforce + OMS. Cuando SAP registra cambios en el master de catálogo (nuevos productos, modificaciones de descripción, cambios de jerarquía), publica eventos al Service Bus de Azure. Salesforce Commerce Cloud consume estos eventos para actualizar el catálogo de cara al cliente. El OMS consume los mismos eventos para actualizar sus reglas de fulfillment.
Inventario SAP → OMS. Cada movimiento de inventario en SAP (recepción de mercancía, venta en tienda, ajuste, traspaso) genera un evento que el OMS consume para actualizar su vista de disponibilidad. Latencia objetivo: menor a 30 segundos.
Pedidos Salesforce → OMS. Cuando un cliente completa un pedido en Salesforce Commerce Cloud, se envía vía API al OMS. El OMS hace el ruteo, asigna fulfillment, calcula promesa, y devuelve la confirmación que Salesforce muestra al cliente.
Pedidos confirmados OMS → SAP. Cuando un pedido se completa, la información fluye a SAP para generar la factura CFDI, registrar el movimiento de inventario correspondiente y alimentar la contabilidad.
Cliente Salesforce ↔ OMS. Los datos del cliente se mantienen consistentes entre Salesforce (que es la fuente de verdad para perfil, preferencias e historial) y el OMS (que necesita información del cliente para cada pedido).
La capa de integración usa Azure Service Bus para mensajería asíncrona (alta volumetría, tolerancia a latencia de segundos) y APIs REST para queries síncronas (disponibilidad de stock, creación de pedido, consulta de estado).
Una integración bien implementada es invisible para el usuario. Una mal implementada genera errores en precios, inventario fantasma, facturas incorrectas y un caos operativo que erosiona la confianza del cliente. En Soriana se invirtió tanto esfuerzo en la capa de integración como en cada uno de los sistemas individuales.
Agenda una consulta si tu empresa enfrenta desafíos similares de integración entre Salesforce, ERPs y sistemas custom.---
Resultados medibles: antes y después
| Métrica | Antes | Después | Mejora |
|---|
| Pedidos cancelados por falta de stock | 12-18% | 2-4% | -80% |
|---|---|---|---|
| Tiempo promedio de fulfillment | 48-72 horas | 8-24 horas | -70% |
| Costo por pedido de última milla | Alto (sin optimización) | Optimizado con TMS | -35% |
| Capacidad de pedidos por hora | Limitada por procesos manuales | Escalable automáticamente | +400% |
| Precisión de promesa de entrega | 65% | 92% | +42% |
| Velocidad de cambios en sitio web | Semanas | Horas (Salesforce low-code) | -95% |
| NPS canal digital | 32 | 68 | +112% |
Más allá de las métricas operativas, la transformación habilitó capacidades antes imposibles: usar las 800+ tiendas como mini centros de distribución durante picos, escalar la infraestructura automáticamente sin intervención manual, una vista 360 del cliente unificada, y un programa de lealtad consistente entre canales.
---
Lecciones aprendidas para retailers mexicanos
Lección 1: SAP es excelente, pero no para todo
SAP fue diseñado para gestión financiera, operativa y de cadena de suministro. Forzar a SAP a orquestar e-commerce a velocidad de canal digital genera cuellos de botella, mala experiencia para el cliente y frustración del equipo de TI. La solución es complementar SAP con sistemas especializados, no reemplazarlo.
Lección 2: Salesforce Commerce Cloud paga su precio en velocidad
Para un retailer con marketing maduro y ambición de personalización, Salesforce Commerce Cloud habilita un ritmo de innovación que un stack custom no alcanza sin un equipo grande. El costo de licencia se justifica con la velocidad de time-to-market y la reducción de dependencia de TI para cada cambio.
Lección 3: Custom en Azure tiene sentido para lógica de negocio única
OMS, TMS y pasarelas son dominios con reglas de negocio que cambian rápido y que diferencian competitivamente al retailer. Comprar productos empaquetados aquí significa adaptar la operación al software en vez del software a la operación. Construir custom en Azure (o cualquier cloud) es viable y a menudo más económico a largo plazo.
Lección 4: La integración es el proyecto más importante
La tecnología de cada componente (Salesforce, OMS, SAP, TMS) funciona bien de forma individual. La complejidad real está en hacer que todos estos sistemas se comuniquen de forma confiable, en tiempo real, procesando miles de transacciones por minuto sin perder datos ni generar inconsistencias.
Lección 5: Implementar por fases es ser inteligente
Un retailer con 800 tiendas no puede permitirse un fallo en producción que afecte a toda la operación. Implementar por fases permite aprender, corregir y escalar de forma controlada. Soriana ejecutó el proyecto en cuatro fases a lo largo de 16 meses.
Lección 6: Ship from store cambia el juego
Habilitar las tiendas como puntos de fulfillment transforma toda la economía del e-commerce. De repente, cientos de mini centros de distribución ubicados estratégicamente en zonas donde viven los clientes. La cobertura se amplía, los tiempos bajan y el costo logístico se reduce significativamente.
---
Preguntas frecuentes
¿Por qué no usar Salesforce para todo, incluyendo OMS?
Salesforce Order Management existe y para algunas operaciones es excelente. Pero para retailers con lógica de fulfillment muy específica, dark stores, ship from store en cientos de tiendas y necesidad de iteración rápida en reglas de negocio, un OMS custom en Azure ofrece más control y a menudo mejor TCO. La decisión depende del tamaño, complejidad y velocidad de cambio de la operación.
¿Por qué SAP en lugar de un ERP más moderno?
Soriana ya tenía SAP. Migrar el ERP es un proyecto multimillonario que no se justificaba para resolver los problemas de e-commerce. La estrategia fue dejar a SAP en su zona de fortaleza y construir alrededor lo que SAP no hace bien. Para una empresa que está eligiendo ERP desde cero el cálculo puede ser distinto.
¿Cuánto cuesta una arquitectura similar para empresas medianas?
Para empresas con 10 a 50 puntos de venta y un e-commerce existente, una arquitectura escalada de este tipo puede costar entre $5 y $20 millones de pesos en el primer año, según complejidad. Es una inversión significativa pero con ROI típico de 12 a 24 meses cuando el e-commerce representa porción material de las ventas. Para empresas más pequeñas existen opciones SaaS con costos accesibles.
¿Puedo usar otro cloud en lugar de Azure?
Sí. AWS y Google Cloud ofrecen capacidades equivalentes (SQS, Lambda, App Engine, Cloud Run). La elección suele ser por afinidad operativa del equipo de TI, integración con identidad corporativa y costos negociados. Lo importante es el patrón arquitectónico (cada sistema en su rol justo, integración robusta), no el proveedor cloud específico.
¿Cuánto tiempo toma ver resultados?
Los primeros resultados son visibles desde la Fase 1: la visibilidad de inventario en tiempo real reduce cancelaciones por falta de stock desde el primer mes. El impacto completo con ship from store, click and collect y optimización logística típicamente se materializa entre 6 y 12 meses conforme el sistema se calibra con datos reales.
---
Próximos pasos
La transformación digital del retail no es un proyecto de tecnología. Es una transformación de negocio habilitada por tecnología. Soriana entendió que la respuesta no era hacer que SAP fuera todo, sino combinar tres pilares — Salesforce para experiencia, Azure para sistemas custom, SAP para columna vertebral — cada uno en el rol donde es insuperable.
Si tu empresa está en el camino de la transformación digital y necesitas integrar Salesforce, ERP y sistemas custom, agenda una consulta gratuita con nuestro equipo. Analizamos tu arquitectura actual, identificamos los puntos de mejora más impactantes y te proponemos un roadmap realista.
