Para fabricantes mid-market que quieren un cockpit operativo
Un cockpit operativo, donde hoy viven catorce hojas de cálculo, un grupo de Telegram y un kanban de papel. La línea se mira en tiempo real, con OEE por estación. Las faltas suben por la BOM antes de que la orden se pare en ensamblaje, y los andones entran en la cola de mantenimiento como eventos rastreados.
La falta que se ve en línea de ensamblaje un martes es la misma que cualquiera en compras podía haber leído en la BOM tres días antes. Nada conecta con nada, y los operarios llevan el sistema en la cabeza.
Cuando el jefe de línea ve la línea al 41 por ciento, el turno que la produjo ya ha terminado hace rato. El número es correcto, y solo sirve para la reunión del lunes.
Andones a voz, averías anotadas a mano, y el turno que sigue lee el cuaderno si se acuerda de mirarlo. La misma avería la semana siguiente parece una coincidencia a todos menos al operario en turno.
El Gantt es del viernes pasado, la producción real vive en la cabeza de alguien, y atención al cliente llama a compras pidiendo las fechas.
Un cockpit operativo construido para una planta de seis líneas en Brescia. Un solo producto sustituye las hojas de cálculo, el grupo de Telegram del cambio de turno, y el kanban de papel clavado a la pared junto a la prensa.
La planta tiene seis líneas y un almacén en Brescia. Cuando llegamos por primera vez, lo digital era esto: un SharePoint con catorce hojas de cálculo, un grupo de Telegram para los cambios de turno, y un kanban de papel clavado a la pared junto a la prensa. Las faltas que aparecían en línea de ensamblaje una semana sí y otra no eran las mismas que cualquiera en compras podía haber leído en la BOM tres días antes. El brief decía una sola cosa: rehacer el cockpit que la planta llevaba años imaginando.
La primera semana entró la vista en vivo de línea con el OEE. A la segunda ya había también un pipeline de órdenes con kanban y Gantt. A la cuarta una BOM multinivel con propagación de faltas. Al segundo mes una sección de almacén con mapa de bins, un módulo de calidad, un registro de mantenimiento, y un área de informes encima del resto. Cada petición se absorbió y se llevó a producción, y nada volvió marcado como "fuera de scope".
La página de detalle de línea se lee como la checklist del operario. El OEE del turno en curso, el throughput frente al target en tiempo real, el ciclo en segundos, el uptime desde el inicio de turno. Debajo, una barra con todas las estaciones, donde cada celda tiene su propio ciclo, su target, y el operario asignado.
Ir más allá del nivel dashboard fue una decisión deliberada. Una línea al 41 por ciento es un dato. Una línea al 41 por ciento con la estación S4 parada, sin operario, y la S2 tirando a 26 segundos contra un target de 25 es una conversación completamente distinta. El botón "Raise Andon" en la cabecera de la línea escribe un evento real en la cola de mantenimiento, con la celda, la anomalía de ciclo, y la orden activa ya rellenas. El operario nunca reescribe lo que el sistema ya sabe.
El módulo BOM es multinivel. Cada producto tiene su propio árbol de subensamblajes, piezas y materia prima, con la revisión y los lead times de proveedor rastreados en cada nodo. Los flags de falta no se quedan parados en la pieza donde se abre el hueco. Suben por el árbol hasta el ensamblaje que los necesita, y entran en el pipeline de órdenes que depende de ese ensamblaje.
Una bobina que se está agotando aguas arriba llega al planificador de producción antes de que la orden en línea lea cero. La semana en que la planta había cogido cinco faltas en línea de ensamblaje con el sistema antiguo fue la semana en que escribimos la propagación. En esa misma semana, dos de esas faltas ya habrían sido visibles desde la BOM en vivo, con tres días de antelación.
La app móvil de planta pone a dos taps de la home las acciones que un operario repite cien veces al día: la salud de línea, el ciclo en curso, el registro de un problema de calidad, la apertura de un andon. El desktop lleva la planificación, donde el planificador de producción y el director de planta pasan el día. Ninguna es una versión adelgazada de la otra. La misma librería de componentes pinta las dos, y los temas claro y oscuro se pensaron juntos desde el principio, así el jefe de línea del turno de noche no entorna los ojos ante una pantalla blanca para leer el plan.
Un cockpit de operaciones no es un dashboard de business intelligence con colores más cuidados. Es el andon que el operario pulsa cuando la estación tres se queda atrás, la orden de trabajo que el planificador mueve de una línea a otra a las nueve y cuarenta porque la cartera de pedidos cambió, la BOM que el comprador mira el martes para que la falta no aparezca en línea de ensamblaje el viernes, y el informe que el director de planta lee el lunes para que la conversación con el cliente vaya informada antes de la llamada. Industria hace todo eso desde un solo producto, con un solo equipo que trabaja en la misma codebase.
El mismo producto es el que la segunda planta hereda cuando la empresa pasa a un segundo sitio. La librería de componentes, la lógica de la BOM, el flujo del andon, las plantillas de informe no se rehacen, se configuran. Es la parte que se capitaliza con el tiempo, y es la parte que el stack de hojas de cálculo nunca le dio a nadie.
Disponibilidad, rendimiento y calidad en tiempo real, hasta el ciclo individual. Las anomalías afloran mientras el turno todavía está en marcha, no a final del día en el informe de cierre.
Cada subensamblaje, pieza y materia prima vive en un árbol. Cuando una bobina se agota aguas arriba, el flag sube por el árbol hasta las órdenes que dependen de ese subensamblaje, y llega al planificador antes de que la línea lea cero.
Un solo dataset alimenta dos vistas. Arrastras una tarjeta y el Gantt se actualiza, mueves una fecha y el kanban se mueve con ella. La planificación deja de vivir en un PDF del viernes pasado.
El operario pulsa, y la cola de mantenimiento recibe un evento rastreado con la celda, la anomalía de ciclo, y la orden activa ya rellenas. La avería deja de vivir en la voz de alguien, y cada intervención entra en el historial de la máquina.
Salud de línea, ciclo en curso, registro de un problema de calidad, apertura de un andon. Todo a dos taps de la home. El jefe de línea del turno de noche no espera a volver a la oficina para anotar lo que pasó.
Las órdenes de trabajo nacen en el ERP y aparecen en el cockpit; la producción vuelve al ERP a final de turno. Del lado planta, los datos de ciclo suben desde los controladores industriales, y los comandos de inicio de orden bajan a la línea. Hemos trabajado con SAP, Dynamics y Sage X3 del lado ERP, y con los controladores de los principales fabricantes del lado planta.
Cada capa de este stack se amortiza dos veces. La primera cuando pones en marcha la primera planta. La segunda cuando despliegas a la segunda, o cuando aguantas una auditoría sobre la primera. El stack se construye alrededor de ese segundo momento.
El lado oficina vive dentro de un único proyecto Next.js. La planificación, la gestión de la BOM, los informes, la programación: las pantallas en las que el planificador de producción y el director de planta pasan el día. Las respuestas se sirven desde los nodos edge más cercanos a la oficina, y las mismas rutas pintan en versión móvil para el jefe de línea que quiere mirar el plan entre dos rondas.
Los datos de cada planta quedan separados directamente en la base de datos, y la separación se impone en la fila, no en el código de aplicación. La razón es simple. La segunda planta no quiere compartir datos con la primera por accidente, y esa es también la primera pregunta del auditor. Sobre las órdenes de trabajo el sistema funciona por eventos: cada cambio es replayable, cada trazabilidad de la materia prima a la unidad enviada se reconstruye con una consulta en lugar de con arqueología de hojas de cálculo.
La línea se actualiza en tiempo real sin un polling que ahogue al gateway de planta. Ciclos, andones, estado de estación, salud de línea llegan en un canal que la app móvil del operario y la dashboard del planificador leen igual. Operario y planificador ven la misma línea en el mismo segundo.
Para hablar con los controladores industriales, vive en la planta un pequeño gateway. Donde existe un protocolo estándar (OPC-UA), nos apoyamos en él. Donde no existe, escribimos nosotros una capa de traducción con un contrato documentado. El gateway es la única pieza en hardware del cliente. Todo lo demás vive en la nube, y se actualiza sin una visita a la planta.
Los documentos de trazabilidad (fotos de no conformidad, manuales de máquina, documentación de lote, informes regulatorios) viven dentro de un object storage cifrado en reposo, con claves gestionadas por la planta. El acceso pasa solo por URL firmada, y cuando el auditor pide dos años de informes de no conformidad en un solo zip no se convierte en una sorpresa en la factura del mes siguiente.
Todo el código está escrito en TypeScript, desde las definiciones de los mensajes que llegan de los controladores hasta los componentes de la interfaz. Cuando el jefe de turno que había construido las reglas de la línea cuatro deja el equipo, el cockpit no pierde lo que la línea cuatro había aprendido a hacer bien.
Normalmente nos sentamos al lado. El MES sigue siendo la fuente de verdad para las órdenes de trabajo y las recetas, y el cockpit es el producto que la planta y la oficina miran de verdad. Si el MES es una instalación de hace cinco años que nadie quiere ya, hemos sustituido uno. Las dos opciones siguen sobre la mesa.
Donde el controlador habla un protocolo estándar, nos apoyamos en él. Donde no lo habla, escribimos una pequeña capa de traducción que corre en un servidor de planta, con un contrato documentado y versionado. El gateway publica eventos hacia el cockpit y acepta comandos de orden de trabajo de vuelta.
El gateway de planta sigue escribiendo en un registro local durante la caída, y reproduce cuando vuelve el enlace. La app móvil de planta cachea el último estado y mete las acciones en cola. Nada del lado del operario se queda esperando una respuesta del servidor.
Cada planta queda separada por defecto dentro de la base de datos, con un único identity provider delante. El catálogo compartido (piezas, proveedores, recetas) vive en un esquema común, y los datos operativos (órdenes de trabajo, ciclos, andones) por sitio. La segunda planta recibe el mismo cockpit que la primera, no un fork.
Sí. Las órdenes de trabajo nacen en el ERP y aparecen en el cockpit; la producción vuelve al ERP vía job programado o webhook, según lo que exponga el ERP. Ya lo hemos hecho con SAP, Dynamics y Sage X3.
Una llamada para enmarcar el proyecto, un número concreto en la primera respuesta, y nada de pitch deck con case studies que parecen todos iguales.
Founders SaaS, de pre-seed a Series A
Founders fintech que desarrollan neobancos, wallets, lending, pagos
Founders que desarrollan productos cloud para consumer y utility apps
Equipos del sector público que entregan servicios a los ciudadanos