Caso

Cuando los sistemas de comercio no comparten un registro

Pedidos, clientes, catálogo, fulfillment y pagos estaban “integrados”. La operación igual reconstruía la verdad a mano.

Un plan en papel fijado a una pared

Antes

Una operación de medios y entretenimiento que corría pedidos por OMS, CRM, PIM, fulfillment, pagos y herramientas internas. Cada sistema tenía dueño. Ninguno tenía el pedido completo.

Fricción

Los flujos entre esos sistemas no tenían trazabilidad, reintentos, idempotencia ni un log que alguien fuera a leer. Cuando algo fallaba, los equipos reprocesaban a mano y discutían cuál registro era el vigente.

Resultado

Flujos conectados con trazabilidad y una forma común de ver una falla. Menos retrabajo manual entre áreas, y decisiones técnicas que se podían atar a la operación y no a un backlog local.

A la empresa no le faltaban integraciones. Le faltaba un contrato de lo que una integración podía hacer cuando fallaba. Los mensajes se movían. La confianza no.

El trabajo de diseño fue poco glamoroso y específico: identificar los flujos críticos, darle un rastro a cada uno, hacer seguros los reintentos y dejar un log que un operador pueda usar a las 7 p.m. sin llamar a quien escribió el conector.

Ese es el patrón que sigo buscando en stacks de comercio y operación. Un diagrama de flechas no es un sistema. Un sistema puede explicar un pedido fallido sin una reunión.