El problema aparece cuando las cosas van bien
Con tres pedidos al día, reescribirlos a mano es soportable. Con treinta ya no, y el cuello de botella pasa de las ventas a la administración.
La paradoja es que cuanto mejor funciona la tienda, más trabajo manual genera. Es el momento en que casi todos nos llaman.
Primera decisión: quién manda sobre qué
Es la elección que determina todo lo demás. Para cada tipo de dato hay que establecer qué sistema es la fuente autorizada.
Normalmente la gestión manda sobre productos, precios y stock; la tienda manda sobre pedidos y clientes registrados online. Pero las excepciones existen y se deciden antes, no durante el desarrollo.
Segunda decisión: cuándo viajan los datos
No todo debe ser instantáneo. El stock normalmente sí, porque un error ahí significa vender algo que no existe. El catálogo puede actualizarse cada hora. El histórico puede viajar de noche.
Sincronizar todo en tiempo real parece lo mejor, pero cuesta más y carga los sistemas sin necesidad.
Tercera decisión: qué pasa cuando algo falla
Un sistema caído, un producto sin código correspondiente, un pago retenido: son casos normales, no emergencias. El proyecto debe establecer de antemano si la operación se encola, si se detiene y a quién se avisa.
Una conexión sin gestión de errores funciona perfectamente hasta el primer problema, y después hace más daño que el trabajo manual.
Plazos realistas
Para una conexión completa entre tienda y gestión, probada con pedidos reales, un proyecto típico va de cuatro a diez semanas. El análisis es breve pero decisivo: casi todos los problemas que surgen a mitad nacen de un caso particular no declarado al inicio.
Preguntas frecuentes
Nuestra gestión no tiene API. ¿Se puede igual?
En la mayoría de casos sí, mediante acceso a la base de datos o intercambio programado de archivos. Conviene verificarlo antes con el proveedor.
¿Hay que parar las ventas durante el cambio?
No. La conexión se prueba en paralelo a la introducción manual y se activa solo cuando los datos coinciden.