Lo que costaba correr la planta así
- · Planillas de Excel, papeles y memoria del supervisor. Sin un sistema único, no había forma de saber en tiempo real qué tarea estaba en cada operario, cuánto le faltaba, ni si un pedido iba a estar listo a tiempo. El estado real de la planta se reconstruía a mano cada mañana.
- · Estimaciones a ojo del capataz. El supervisor armaba los compromisos a partir de su experiencia — un conocimiento que se iba con él cada vez que renunciaba o se jubilaba. La calidad de las estimaciones dependía de quién estaba en el puesto.
- · Atrasos descubiertos cuando el cliente preguntaba. No había forma de detectar temprano que una tarea se estaba pasando del tiempo razonable. El primer aviso de un problema era el cliente llamando por su pedido.
Lo que cambió con DibAI
- · Visibilidad en tiempo real del estado de cada tarea. El supervisor ve quién está haciendo qué, desde cuándo, en qué estado. La foto de la planta se actualiza sola, sin pedirle a nadie que reporte.
- · Estimaciones de tiempo que mejoran con el uso. El modelo de regresión aprende de cada tarea cerrada. La próxima vez que aparece una tarea parecida, sugiere un tiempo más ajustado a la realidad de la planta.
- · Detección temprana de atrasos, antes de que el cliente los vea. El dashboard marca qué tareas se están pasando del tiempo estimado. El supervisor puede reprogramar o reasignar antes de que se vuelva un problema de entrega.
Dos servicios, dos lenguajes, una sola fuente de verdad
La app tiene que sentirse como un único producto para el operario, pero por debajo conviven Node.js (que maneja toda la API y la orquestación) con Flask (que solo expone el modelo de ML). Diseñamos el flujo así:
- 1 Node.js es la cara visible para el cliente. React consume una sola API. La app no sabe — ni le importa — qué corre del otro lado para resolver una estimación.
- 2 Flask solo se despierta cuando hace falta predecir. El servicio de ML está aislado: recibe features por HTTP, devuelve un número. Nada de estado, nada de bloqueos en cascada.
- 3 PostgreSQL guarda todo lo transaccional. Tareas, usuarios, histórico, logs. El modelo se entrena leyendo desde la misma base, así no hay drift entre lo que ve el sistema y lo que aprende.
- 4 El reentrenamiento se dispara a mano, desde un panel. El admin decide cuándo se actualiza el modelo. Cero sustos en producción por una corrida automática que rompe algo.
┌──────────────────┐
│ React WebApp │ ◄── Vistas para operario y supervisor
│ (operario + │
│ supervisor) │
└────────┬─────────┘
│ REST + JSON
▼
┌──────────────────┐
│ Node.js + │ ◄── API, auth, CRUD de tareas, orquestación
│ Express │
└────┬─────────┬───┘
│ │
│ │ Llama cuando hace falta estimar
▼ ▼
┌─────────┐ ┌────────────────┐
│Postgres │ │ Flask + scikit │ ◄── Regresión lineal
│ + Redis│ │ -learn │ (servicio aislado)
└────┬────┘ └────────┬───────┘
│ │
│ Lee histórico│
└────────►───────┘
│
▼
Panel admin dispara
reentrenamiento manual Lo que nos llevamos como aprendizaje
- 01
El ML no reemplaza al supervisor, lo potencia
El modelo sugiere un tiempo estimado. El supervisor lo acepta, lo corrige o lo descarta. La inteligencia artificial es una herramienta más, no la que decide. Esto baja la resistencia al cambio y mantiene al humano en el loop.
- 02
Reentrenar a mano es una feature, no una limitación
En producción, un modelo que se reentrena solo puede romperse solo. Darle al admin el botón de reentrenar significa que alguien está mirando el resultado antes de promoverlo. Cero sustos.
- 03
El dashboard por área es lo que hace que la app se use
Si la app fuera un Excel glorificado, no la iban a usar. Lo que hace que un supervisor entre cada mañana es ver de un golpe el estado de su área — taller, diseño, depósito, ventas. La UI es la que cierra el ciclo.
Pasamos de correr la planta con planillas y memoria del supervisor a tener visibilidad real de cada tarea. Y ahora cuando un cliente pregunta cuándo está su pedido, la respuesta sale del sistema, no de un cálculo a ojo.
Testimonial parafraseado.
¿Tenés una planta que sigue corriendo en planillas?
Conversamos 20 minutos sobre tu operación, vemos el alcance, la arquitectura y dónde tiene sentido meter ML. Sin compromiso.