Un grupo con dos marcas, seis canales de venta, varios almacenes y dos mercados no tiene un problema de software: tiene un problema de coordinación. Este es el sistema que lo resolvió, y el que los otros cinco consumen.
¿Dónde vive el catálogo maestro? ¿Quién decide el precio? ¿Qué pasa cuando el mismo producto se vende a la vez en la tienda en línea, en el marketplace y por teléfono? ¿Cómo entra una factura de proveedor? ¿Quién autoriza una compra?
Sin una pieza central que responda a esas preguntas, cada área construye su propia versión de la verdad y la empresa acaba discutiendo cifras en las juntas en lugar de decidir sobre ellas.
El sistema que la propia documentación del proyecto define como la pieza central que sustenta todas las operaciones del grupo. Cubre el negocio de punta a punta y da servicio simultáneo a almacén, compras, contabilidad, televentas, distribución mayorista, comercio electrónico y dirección comercial.
Márgenes de inventario, reglas de asignación de paquetería, políticas de escasez por producto, campos de pedido, promociones y frecuencias de los procesos automáticos se administran desde la aplicación. Cambiar una política no requiere esperar un desarrollo.
La integración es bidireccional y profunda: publica el catálogo, levanta los pedidos, mantiene el inventario actualizado en vivo desde el piso del almacén, genera etiquetas de envío y gestiona devoluciones. Sobrevender ahí no solo pierde una venta: penaliza la cuenta.
Lo resolvimos otra vez, para otro clienteDecenas de perfiles distintos, verificados en la gran mayoría de las pantallas, para que el personal de piso no vea finanzas y compras no toque inventarios. El control de acceso creció con los módulos, no se añadió al final.
Cada uno es un problema de negocio real que solo se resuelve con decisiones de ingeniería correctas.
Todo —inventarios, pedidos, facturas, tableros, faltantes— estaba acoplado al ERP heredado. El cliente decidió cambiarlo, y había que desconectar y reconectar todos los subsistemas de una empresa que vende a diario en seis canales.
Primero la base de autenticación contra el ERP nuevo, después las facturas, después el envío de pedidos. Cada dominio se validó en producción antes de tocar el siguiente.
Durante toda la transición ambos ERP convivieron tras un interruptor, que se retiró semanas después de que el corte demostrara ser estable.
La desconexión final se ejecutó en un solo día de trabajo concentrado sobre inventarios, pedidos, facturación y tableros.
La operación no se detuvo un solo día.
El almacén propio y el ERP externo mantienen cada uno su estado de inventario. Divergen por errores de red, transacciones a medias y operaciones concurrentes de piso. Un inventario divergente rompe el surtido y sobrevende en el marketplace.
La preparación de los traspasos está separada de su ejecución, lo que hace el proceso idempotente: si se interrumpe, se retoma sin duplicar.
Lo que falla queda en una cola persistente con su propio contador, en lugar de desaparecer en un registro.
Un proceso reconstruye el inventario completo desde el ERP, con un manual de operación documentado paso a paso.
Un vigilante compara ambos inventarios y reporta el porcentaje de divergencia antes de que se convierta en un pedido mal surtido.
El desajuste se detecta como número, no como queja del cliente.
Calcular inventarios óptimos es difícil porque el histórico de ventas miente: cuando hubo quiebre de stock, la venta registrada es cero —no porque no hubiera demanda, sino porque no había producto. Promediar ese histórico subestima la demanda y perpetúa el desabasto.
El sistema arma la serie temporal diaria por producto cruzando el histórico de inventario contra las ventas reales y rellena los huecos de días sin operación.
El modelo identifica los periodos donde stock y demanda son ambos cercanos a cero y los interpreta como demanda a estimar, no como demanda real.
Aplica el coeficiente de crecimiento detectado en el propio histórico y proyecta el mes en curso y el siguiente.
Si la cobertura de un producto cae por debajo de unos pocos días, dispara una alerta al equipo de planeación.
Es un problema de datos censurados, resuelto con IA. No es un asistente conversacional.
Decenas de trabajos automáticos con frecuencias que van del minuto al día. Había que poder encenderlos y apagarlos sin tocar la configuración del servidor, y garantizar que ninguno se relance mientras el anterior sigue vivo.
Cada tarea tiene su ruta, su recurrencia y su próxima ejecución, administrables desde la aplicación.
El orquestador captura el identificador real del proceso del sistema operativo: mientras la tarea corre, no puede relanzarse.
Un trabajo caído libera su lugar y notifica al equipo, en vez de dejar su ranura ocupada para siempre.
Nació de un incidente real de pedidos duplicados y se convirtió en política del ecosistema.
Dar a personal de piso y almacén —muchos compartiendo una tableta— acceso seguro a la documentación corporativa, con una autenticación que no fuera un lastre en mitad del turno.
La sesión caduca en segundos en la tableta compartida y en minutos en el dispositivo personal. La seguridad se ajusta al contexto físico.
Es recuperación aumentada con control de acceso: cada empleado consulta solo la documentación que le corresponde.
El empleado pregunta hablando, con las manos ocupadas.
La actividad del kiosco se resume con IA para descubrir qué no está quedando claro en la operación.
El acceso a la información dejó de depender de tener un escritorio asignado.
Todo lo de esta lista existe hoy en producción, en un negocio que factura todos los días.
Ver todos nuestros serviciosForma parte de un ecosistema de seis sistemas que comparten un mismo corazón de datos. Recórrelos, o vuelve a la visión de conjunto.
Si algo de lo que acabas de leer se parece a lo que vives todos los días, hablemos. La primera conversación es de diagnóstico, no de venta.