La transformación digital en la fabricación es un problema de secuencia, no de tecnología

La secuencia es la parte difícil, y la que el material de los proveedores se salta, porque la versión honesta obliga a decirle a un cliente que compre menos este año. Esta página es ese orden.

Por qué encallan los proyectos de transformación digital en la fabricación

Cuatro causas explican la mayoría. Las cuatro son fallos de programa y no de producto, y ahí está el asunto: son las que la planta controla. El software también falla por sus propios motivos, y esa lista pertenece a la compra: diseño de la transacción, rendimiento a escala, un proveedor cuyo compromiso termina en la puesta en marcha.

La primera es un patrocinador sin un responsable debajo. Un patrocinador aprueba un presupuesto y acude a una reunión mensual; un responsable tiene horas de planta, autoridad para cambiar un proceso y un resultado personal ligado a que la fábrica funcione distinto dentro de un año. La segunda es un caso de negocio que da por hecho un dato que no existe, de modo que un plan para analizar las paradas se encuentra con una columna de texto libre en un parte de turno. La tercera es un piloto que nunca se construyó para escalar. La cuarta es comprar una plataforma antes de conocer la pregunta, con lo que la planta se queda con un sistema capaz y sin primer uso.

Cómo elegir el primer proyecto de digitalización

El primer proyecto debe salir de la restricción de la planta, no de la lista de módulos. En la mayoría de las fábricas la pérdida es poco lucida: cambios de formato más largos que el estándar, material que no aparece, paradas de dos minutos que nadie registra.

Tres preguntas filtran candidatos deprisa. ¿La pérdida ya aparece en la contabilidad de la propia planta, como desecho, horas extra, transporte urgente o penalización por entrega tardía? ¿Alguien actuaría distinto dentro del mismo turno si tuviera la respuesta? ¿Se puede saber en un ciclo de producción si ha funcionado? Ciclo y no trimestre: tres meses son una prueba razonable en trabajo repetitivo de alta variedad y no significan nada en aeronáutica o en una campaña farmacéutica, donde la unidad es una campaña o un pedido.

A veces el software es la respuesta equivocada: si la restricción es física, ningún dato hará la máquina más rápida. Lo que hace la medición es enseñar adónde se va la capacidad, y eso normalmente redirige la petición de inversión en lugar de confirmarla. El tiempo de marcha de la máquina candidata resulta peor de lo que nadie creía una vez se cuentan las microparadas, y aun así la mayoría de las horas que perdió no eran suyas: estaba desabastecida aguas arriba, bloqueada aguas abajo, en cambio de formato, o esperando a un operario que cubría dos puestos. La máquina nunca fue la restricción, y el dinero corresponde a otro sitio.

Qué medir antes de empezar, para poder demostrar el cambio después

La trampa es de definición. Antes de la puesta en marcha, la disponibilidad sale de un parte de turno donde las microparadas no se anotan; después, las paradas se detectan solas, así que el OEE medido baja porque por fin se cuentan pérdidas que siempre estuvieron ahí. Si nadie registró la definición antigua y la cifra antigua, el tercer mes parece un retroceso y el programa gasta su crédito defendiéndose.

Así que escriba entera la cifra actual y su definición: la base de tiempo sobre la que se calcula el porcentaje, de dónde sale el tiempo de ciclo ideal, cómo se clasifica la parada, si se excluye el mantenimiento planificado y qué se hace con el retrabajo. Las dos primeras deciden casi todo: tiempo calendario, tiempo programado y tiempo con personal dan tres cifras distintas en la misma planta a partir de datos idénticos, y el tiempo de ciclo ideal es el de placa, el mejor demostrado, o un número de la ruta fijado una vez y nunca revisado.

Después capture los hechos que cuesta más redefinir y se pueden conciliar con finanzas: unidades expedidas, horas pagadas frente a horas trabajadas, líneas de pedido entregadas tarde, abonos y horas extra. Que cueste más no significa que sea imposible, así que congele la definición y el sistema de origen de cada uno junto a la definición de OEE. El cumplimiento de plazos necesita su propia decisión por escrito, porque la base de fechas es la definición que más se rediscute en cualquier planta: compromiso original o última fecha revisada, pedido o línea, expedición o recepción.

Qué va primero: conectividad, datos maestros y después analítica

La conectividad y los datos maestros están debajo de todo, la analítica está encima y vale lo que valgan esas capas, y los datos maestros son la dependencia que se subestima siempre. Un sistema de ejecución no puede lanzar una operación que no está en la ruta, y un planificador no puede secuenciar sin tiempos estándar que alguien haya medido en esta década. Así que antes de comprometer una fecha, cuente las referencias sin ruta, los tiempos estándar en números redondos, las ubicaciones que existen en la práctica y en ningún sistema, y las listas de materiales duplicadas.

La otra costura que conviene definir al principio y no al final es la integración con el ERP, donde la dificultad es el acuerdo y no el código: qué significa una confirmación a cada lado y si la notifica la planta o un backflush, cómo aterrizan las cantidades parciales y las divisiones de orden, qué pasa con una anulación cuando el material ya se ha movido, dónde se imputa el desecho contra el coste estándar. Cada respuesta es una decisión entre departamentos que nunca han tenido que ponerse de acuerdo.

Dos dependencias de plazo largo casi nunca aparecen en una hoja de ruta técnica. Un registro de ejecución que atribuye producción, paradas y desecho a un operario con nombre es, en Alemania y en buena parte de Europa, un sistema capaz de controlar el rendimiento individual, así que necesita un acuerdo negociado con el comité de empresa antes de la puesta en marcha. La aprobación lleva meses, así que arránquela en el primer año junto con los datos maestros. El contenido es breve: si se guarda o no la identidad del operario, quién la ve, durante cuánto tiempo, y si el reporting está agregado por diseño.

La segunda afecta a la producción regulada. En farmacia, producto sanitario y buena parte de la alimentación, un sistema que registra o impone una decisión de calidad sobre un lote entra en alcance validado: plan de validación, cualificación, pista de auditoría, obligaciones de firma y, después, un control de cambios más lento. El reporting, la captura de paradas y la programación quedan fuera de esa línea; el bloqueo de lote, la liberación y la versión de modelo que usa un sistema de inspección quedan dentro. Defínalo antes de comprar el módulo, porque la validación suele ser la partida más larga del programa.

Por qué el MES va antes que el APS, y el dato de calidad antes que la IA de predicción de calidad

Si a la planificación avanzada se le da el supuesto de ayer sobre dónde está el trabajo, la secuencia se reordena a mano antes de que empiece el turno, el planificador vuelve a la hoja de cálculo en pocas semanas y el veredicto es que el software de programación era malo. No era malo, era ciego.

Los datos en vivo hacen que una programación sea factible, no ejecutable, y en esa distancia vive la mayor parte de la decepción con el APS. Una programación sobre datos perfectos se sigue ignorando si optimiza el objetivo equivocado, minimizando la preparación mientras a la planta se la juzga por fechas de entrega; si faltan las restricciones secundarias, porque las secuencias reales las deciden el utillaje, la matriz de polivalencia y la mano de obra compartida; o si no hay nada congelado, porque un optimizador que recalcula sin parar entrega al encargado un plan nuevo cada vez que mira. Acuerde un periodo congelado y deje que la optimización siga recalculando fuera de él.

La predicción de calidad tiene la misma forma: un modelo que pronostica el desecho necesita el desecho registrado en la operación donde ocurrió, con causa y contexto de proceso, desde la máquina y el útil hasta el lote de material.

El mantenimiento tiene una distinción que se pasa por alto en la venta. La detección de anomalías sobre firmas de vibración o de consumo funciona sin histórico de averías, lo cual no es lo mismo que funcionar sin datos: necesita semanas de datos en estado sano que cubran todo el rango de funcionamiento, o alarmará en cada cambio de formato en lugar de ante un daño, y sensores montados y muestreados para los modos de fallo que importan. Aun así solo dice que algo es inusual, y saber qué anomalías importaron exige un histórico de órdenes de trabajo con sus modos de fallo.

Una cámara que enseña apto o no apto en una pantalla tampoco ha cambiado la planta: el veredicto tiene que quedar ligado a una orden de trabajo, un lote y una versión de modelo dentro del registro de ejecución y de calidad, lo que convierte la inspección en una capacidad tardía y no en una puerta de entrada. Otras guías tratan la programación con capacidad finita, qué tiene que cumplir una programación de APS, y dónde termina un CMMS y empieza el mantenimiento predictivo.

Quién dirige el programa, y por qué los operarios se resisten a introducir datos en planta

Informática es socio, no dueño: cuando Informática es la dueña del programa, se optimiza para la integración y la seguridad, las hace bien, y después encalla en la adopción, porque nadie en esa línea responde de que un operario use la pantalla. Debajo del responsable están los usuarios clave, uno por área, con nombre y con horas asignadas: ellos deciden qué pide una pantalla y en qué orden, y la planta les escucha.

El obstáculo declarado para la adopción es casi siempre la gente; el obstáculo real suele ser el diseño de la transacción. Observe una confirmación durante un cambio de formato, con guantes puestos y la siguiente orden esperando. Si introducir un motivo de parada no cambia nada visible, la entrada es un impuesto sobre el turno, que se paga lo más tarde posible y normalmente como un bloque de ficción al final. Si avisa a mantenimiento, actualiza el panel de turno o resecuencia la siguiente orden, pasa a formar parte del trabajo.

El buen diseño de entrada es concreto: terminales en la máquina, manejo con una mano y con guante, valores por defecto tomados de la orden, y una lista corta de motivos por tipo de máquina en lugar de una taxonomía de la que solo se usan cuatro códigos. Cuando la transacción encaja en el trabajo, la formación es lo bastante breve como para darla en la máquina durante un turno. Cuando no encaja, no hay horas de aula que lo arreglen, y una petición de más formación es a menudo un problema de diseño mal diagnosticado como un problema de personas.

En casi todos los planes de formación se olvidan dos cosas. La primera son las correcciones: confirmar una cantidad buena es fácil de enseñar, mientras que anular una equivocada o deshacer una confirmación imputada a la orden que no era es donde un usuario sin formar hace daño de verdad. La segunda es que la formación no es un hecho puntual, porque los encargados necesitan más que los operarios, y las nuevas incorporaciones, el personal de ETT y una planta multilingüe llegan de forma continua.

Escalar un piloto a toda la planta: qué hace que un piloto sea copiable

Los pilotos no escalan por razones que se les diseñaron dentro: la mejor línea, las máquinas viejas evitadas, el proveedor en planta a diario, datos maestros depurados a mano. Un piloto construido para escalar se ejecuta en una línea representativa, incluye al menos un activo incómodo, y registra las horas por línea, porque ese coste unitario es el único dato honesto para el plan de despliegue.

Los criterios de salida y la fecha de decisión del despliegue se acuerdan antes de arrancar el piloto, y el tramo final se hace sin el proveedor. De ese tramo importa lo que cubre más que lo que dura, porque los pilotos rara vez fallan durante la marcha normal. Fallan en el primer cierre de periodo, cuando las cifras tienen que conciliar con el ERP y alguien encuentra desecho imputado dos veces, y en el primer arranque después de una parada, cuando las pasarelas vuelven y los recuentos almacenados en local no. Así que especifique la cobertura: un cierre de periodo con su conciliación, toda la mezcla de producto que fabrica esa línea, y una parada planificada con su arranque. En la mayoría de las plantas eso es un mes o un ciclo completo, no quince días.

Qué cubre un presupuesto de transformación digital, y el coste recurrente que viene después

La licencia es la línea que más se negocia, y las líneas que deciden el resultado están en otra parte: la integración con el ERP y con las máquinas; el hardware, desde pasarelas y paneles hasta sensores de retrofit; la limpieza de datos maestros; la formación y el tiempo de producción que consume; y el esfuerzo interno. El esfuerzo interno es la línea que más se omite: usuarios clave, el responsable, Informática, técnicos montando pasarelas, producción perdida en el cambio al nuevo sistema. Si nadie ha costeado esas horas, el presupuesto está mal por muy bien que se haya negociado la licencia.

El trabajo físico se divide en dos categorías que se planifican distinto. Las tiradas de cable, los puertos de switch y la segmentación entre la red de control y la red corporativa son ingeniería ordinaria con plazos largos, y pueden avanzar con la planta en marcha. Lo que hay dentro del armario eléctrico de una máquina, no: eso es trabajo con la máquina aislada, con bloqueo y etiquetado y una parada planificada, y en la mayoría de las plantas con una prohibición permanente de abrir un cuadro en tensión. Así que la restricción real del calendario de conectividad es cuántas ventanas de parada quedan este año y cuánto de cada una ha reclamado ya mantenimiento. La conectividad se planifica contra el calendario de mantenimiento, no contra el plan de software.

Y luego el coste recurrente, que ningún presupuesto de proyecto contiene y que el director financiero pregunta el primero: lo que cuesta en el cuarto año. La suscripción o el soporte anual siguen, y los paneles y las pasarelas industriales se gastan antes que el hardware de oficina. Sobre todo, alguien de casa opera el sistema cuando el proveedor se va: mantenimiento de datos maestros, cambios de motivos de parada y de rutas, administración de usuarios, adopción de cada versión. Presupueste aparte los cambios de los doce meses siguientes a la puesta en marcha, porque las peticiones que merece la pena financiar solo llegan cuando la planta se cree lo que el sistema le dice.

Cómo secuenciar una hoja de ruta de smart factory a tres años

Un calendario añade lo que el orden de dependencias no puede: quién decide en cada frontera, y cómo se reparten el dinero y las horas. El primer año cierra las decisiones caras de revisar, y las cierra el responsable con finanzas, Informática y el comité de empresa, no el equipo de proyecto: definiciones de KPI, estructura de datos maestros, la costura con el ERP, la identidad del operario y, en una planta regulada, el alcance de validación. El esfuerzo interno alcanza aquí su máximo respecto al gasto en licencia, así que un presupuesto con la forma de un proyecto de informática convencional ya está mal. Hay una partida que corresponde al primer año y que las plantas aplazan: medir las mayores cargas eléctricas para establecer una línea base, que es instrumentación y no modelado, y que a menudo no es discrecional bajo una norma de energía o una auditoría.

La frontera con el segundo año es un juicio, no una fecha, y se cruza cuando la planta discute con la cifra del sistema en lugar de ignorarla. Cerrar un lazo significa que un encargado o un responsable de calidad entrega una decisión a una regla, así que ese alcance se negocia con las personas cuya autoridad se mueve, y el gasto se desplaza de horas internas hacia licencia e integración. El tercer año se gana la capa basada en modelos sobre dos años de registro, y su condición de frontera es la propiedad: cada capacidad necesita una persona con nombre que sea dueña del umbral y del calendario de reentrenamiento. La energía atribuida por pieza va aquí, porque atribuir exige el registro de ejecución que construyeron los dos primeros años.

Dos condiciones de parada corresponden a la aprobación. Si la planta no se fía del dato del primer año, el segundo no empieza. Y adelantar el tercer año porque el consejo ha pedido una iniciativa de IA produce el proyecto encallado que describe el principio de esta página.

Cómo saber si continuar: criterios de paso de cada etapa

Cada etapa necesita una puerta con evidencia que se le pueda enseñar a un escéptico. Después de la conectividad, ¿la producción capturada coincide con un recuento manual durante un turno completo, dentro de una tolerancia acordada antes de la prueba? Después de la primera cifra reportada, ¿se sigue manteniendo la hoja de cálculo antigua en paralelo? Cuando deja de actualizarse sin que nadie lo anuncie, la cifra ha sido aceptada.

Hay una puerta que corresponde a la primera puesta en marcha de la ejecución y que casi siempre se salta: qué hace la línea cuando el sistema no está. En cuanto los operarios confirman en la máquina y calidad bloquea lotes por regla, la caída de un switch o de una interfaz detiene la producción: la planta ha cambiado un portapapeles por un único punto de fallo. Así que defina y pruebe primero el modo degradado: qué almacena el terminal en local y durante cuánto tiempo, cuál es el respaldo en papel, quién puede autorizar trabajar sin el sistema, y cómo se reintroduce el pendiente sin contarlo dos veces. Pruébelo tirando de la conexión durante un turno en marcha, porque una conmutación que nunca se ha probado es la razón habitual de que una puesta en marcha acabe en incidente de producción.

Después del registro de ejecución, ¿puede reconstruir una orden completa, con sus paradas, su desecho y quién la fabricó al nivel de identificación acordado, sin preguntarle a nadie? Antes de planificar, ¿el trabajo en curso es exacto al principio de un turno? Una tendencia importa más que cualquier puerta suelta: si cada línea nueva cuesta lo que costó la anterior, el programa ha construido instalaciones a medida en lugar de un método.

Dónde encaja Meta Smart Factory

Meta Smart Factory cubre las capas anteriores como módulos separados, desde MES, MRP y APS hasta calidad, mantenimiento, almacén y visión artificial, e integración con ERP. La modularidad hace comprable esa secuencia, pero la primera compra no es solo un módulo. Es un módulo contra una restricción concreta en un área, más el cimiento que va debajo: conectividad, limpieza de datos maestros, la costura con el ERP y las definiciones acordadas. Ese cimiento es la mayor parte del esfuerzo del primer año y no aparece en ninguna lista de precios, así que corresponde que figure en la aprobación como línea propia, no dado por incluido dentro de una licencia.

Las partes difíciles sobreviven a cualquier elección de plataforma. Acordar qué significan las cifras, limpiar los datos maestros, diseñar transacciones que los operarios completen sin que haya que perseguirles, y elegir qué se deja de hacer son trabajo compartido. Si ahí es donde está usted, una conversación sobre la secuencia para su restricción vale más que una demostración de producto.