Ampliar los sistemas que ya existen, no reemplazarlos.
Auglo Supply es una plataforma de servicios modulares que se integra sobre el ERP o WMS que la empresa ya usa y le agrega lógica desacoplada, automatización e inteligencia — sin migrar datos ni cambiar de sistema.
Antes de seguir: esto es una tesis de producto con una demo que la sostiene. No hay clientes ni sistema en producción. La demo es determinística sobre datos sintéticos y esquema real de SAP EWM. Todo lo que falta está listado abajo.
- No es
- Un ERPNi un WMS, ni un reemplazo
- Es
- Una capaModular y desacoplada
- Canal
- PartnersConsultoras e integradores
Del sistema del cliente a la respuesta, y de vuelta.
La capa se apila sobre el sistema existente: abajo queda lo que la empresa ya tiene, arriba lo que Auglo agrega. Seguí un movimiento de mercadería a través de las seis etapas.
Clientesistema existente
Task, Stock u Order
y devuelve resultado. Por eso el mismo servicio sirve para SAP, para Odoo o para un CSV.
El dato ya está adentro. Lo que falta es acceso.
Movés los parámetros de la operación y el asistente reinterpreta el estado del depósito. Cada respuesta muestra la consulta que ejecutaría contra las tablas del WMS.
/SCWM/AQUA,
/SCWM/LAGP, /SCWM/ORDIM_O, /SCWM/ORDIM_C) con campos
simplificados para lectura. La arquitectura con modelo de lenguaje y RAG está descrita arriba.
Por qué una capa y no un sistema nuevo
Una empresa con SAP lleva años cargando cada movimiento de mercadería. Toda la información para responder «¿dónde se me traba la operación?» ya está en la base. Lo que no existe es la forma de preguntarlo: hay que pedirle un reporte a Sistemas, esperar, y volver a pedirlo cuando la pregunta cambia un poco.
-
01
Reemplazar no es una opción realista
Migrar un ERP es un proyecto de años con riesgo operativo real. Ninguna empresa lo encara para tener mejores consultas. Cualquier propuesta que empiece con «cambiá de sistema» ya perdió.
-
02
La fricción de implementación es lo que mata la adopción
Las buenas ideas mueren en el «¿y esto cómo lo integramos?». Por eso el principio es augmentación sin interrupción: habilitar capacidades en horas o días, no en meses, y sin migrar datos.
-
03
La capa desacoplada es el producto
Servicios que operan sobre un modelo canónico se construyen una vez y sirven para cualquier sistema de origen. Lo específico de cada cliente vive en configuración o en un plugin, nunca en el núcleo.
Seis capas desacopladas
Cada capa tiene un único trabajo y no conoce el detalle de las demás. Esa separación es lo que permite construir una vez e integrar en cualquier lado.
cliente
solo lectura
canónico
modulares
IA
- Nunca acoplarse a la base del cliente. Se lee de réplica o de vistas, jamás de las tablas productivas, y nunca se escribe sobre el sistema de origen.
- Multi-tenant desde el día uno.
client_idobligatorio en todo el modelo. Un cliente pesado se aísla en base dedicada sin tocar la lógica de los servicios. - Sólo se persiste lo necesario. Resúmenes, snapshots y predicciones — no una copia del ERP. Cuanto menos dato propio se guarda, menos superficie de riesgo hay.
- Núcleo genérico, adaptadores específicos. Toda regla particular de un cliente vive en configuración o en un plugin. Si entra al núcleo, el producto deja de escalar.
- Despliegue híbrido con un solo núcleo. SaaS multi-tenant para el segmento medio; Docker autoalojado cuando el dato no puede salir de la empresa. Mismo código, distinto empaquetado.
- Cada respuesta es auditable. Se guarda la consulta ejecutada, el tenant, el rol y la latencia. Sin trazabilidad no hay confianza operativa, y sin confianza no hay adopción.
Construido para partners, no sólo para el cliente final
El enfoque no-code no apunta únicamente al cliente final: su objetivo es crear un ecosistema de distribución. Las consultoras, integradores de ERP e implementadores de WMS ya tienen la relación de confianza y el conocimiento del negocio. Lo que no tienen es tiempo para construir infraestructura de IA.
El partner aporta el dominio; Auglo Supply aporta la infraestructura para extender el sistema existente. Además, fuerza una disciplina sana de producto: si un tercero no puede integrarlo sin ayuda, la plataforma todavía no está terminada.
| Plataforma | Fortaleza | Qué se toma |
|---|---|---|
| Mendix | Integración empresarial compleja | Conectar sistemas legacy con capacidades nuevas mediante arquitectura modular |
| Appian | Automatización de procesos | Orquestación de flujos operativos y reglas de negocio |
| Quickbase | Apps operativas rápidas | Soluciones adaptadas al proceso específico de cada cliente |
| Glide | Apps móviles sin código | Interfaces rápidas para operarios y supervisores en piso |
| Airtable | Modelado flexible y automatizaciones | Configuración visual de datos, workflows y conectores |
Por qué ahora
Tres condiciones que hace tres años no estaban dadas al mismo tiempo.
-
01
La migración de WM clásico a EWM
SAP WM clásico está siendo sustituido por EWM en S/4HANA y hay una ola de proyectos de migración en curso. Es la ventana en la que una empresa vuelve a mirar su operación de depósito y acepta tocar cosas — el resto del tiempo, no.
-
02
El costo de integrar se derrumbó
Lo que antes era un proyecto de mapeo de meses hoy se acorta con modelos que leen esquemas y documentación técnica. La capa de traducción dejó de ser el cuello de botella económico de una integración.
-
03
El escepticismo juega a favor
Todo el mundo vio demos de chat sobre datos que se caen en producción. Eso favorece a quien llega con guardarraíles, trazabilidad y límites declarados en vez de magia. Es una ventaja para el que se toma el trabajo de hacerlo bien.
Lo que falta para producción
Conectar un modelo a una base de datos es la parte fácil y ya la hizo todo el mundo. Lo que decide si esto funciona en una operación real es esta lista.
- Mapeo semántico del esquema. Ninguna instalación de SAP es igual a otra: cada una tiene tablas Z propias y campos reutilizados para otra cosa. Ese mapeo es el trabajo real de cada implementación — y también el activo, porque el segundo cliente con el mismo sistema cuesta una fracción del primero.
- Guardarraíles contra alucinación. Generar SQL libre contra producción no es aceptable. Hace falta lista blanca de tablas, validación sintáctica y semántica previa, límite de filas, timeout y ejecución exclusiva sobre réplica de solo lectura.
- Permisos heredados del sistema de origen. El asistente no puede responder lo que el rol del usuario no podría ver en el ERP. Los permisos se heredan, no se reinventan.
- Trazabilidad completa. Cada respuesta guarda su consulta, tenant, rol y latencia. Si un jefe de operaciones toma una decisión con esto, tiene que poder auditarse después.
- Costo y latencia por consulta. Sobre tablas de millones de filas hay que resolver caché, agregados precalculados y presupuesto de tokens por tenant, o el modelo de negocio no cierra.
- La promesa no-code tiene un asterisco. Es real recién cuando existe un catálogo maduro de conectores. El primer cliente de cada sistema es artesanal, y decirlo de entrada evita vender algo que todavía no es.
- Validación de mercado. Falta lo más importante: un depósito real, con su esquema real, diciendo si esto le resuelve algo. Todo lo anterior es criterio; esto sería evidencia.
Feedback, y conversar en serio.
Publico esto para contrastarlo con gente que está construyendo cosas parecidas en Uruguay. Si estás en logística, ERP, integraciones o IA aplicada a operaciones: me interesa tu crítica.
Y si hay afinidad, me interesa sumarme a un equipo o construir esto con alguien. Lo que más me sirve es que me digas dónde está mal.
Pendiente antes de publicar: correo, LinkedIn y nombre en el pie.