Noticias

A medida que las fábricas se automatizan más, el mayor riesgo operativo no siempre es un controlador fallido, una unidad dañada o una interrupción de la red. En algunas instalaciones, el problema más difícil es la persona que no está allí cuando algo sale mal.

Una línea de producción puede tener operadores de guardia, técnicos de mantenimiento en el lugar e ingenieros disponibles por teléfono, pero aun así carecer de la experiencia necesaria para recuperar un proceso automatizado crítico. Un ingeniero de control puede ser el único empleado que entiende un programa PLC heredado, una secuencia de robot personalizada, una arquitectura de red indocumentada o la historia detrás de varios años de cambios de software.

Cuando ese empleado no está disponible, la planta puede descubrir de repente que su nivel de personal aparente no refleja su cobertura técnica real.

Esta forma de riesgo de concentración es cada vez más relevante a medida que los fabricantes implementan sistemas de automatización industrial más sofisticados, plataformas de control conectadas, robótica, historiadores, sistemas de supervisión y redes industriales. La automatización reduce muchas formas de trabajo manual, pero también puede hacer que el conocimiento especializado sea más importante. Un entorno de producción estable puede ocultar, por lo tanto, una frágil dependencia de un pequeño número de personas.

El problema no es necesariamente que una planta tenga muy pocos empleados. El problema es si los empleados disponibles durante un fallo tienen las capacidades adecuadas para responder.

Un técnico puede ser capaz de reemplazar un módulo de E/S, pero no tener autorización para modificar un programa de PLC. Un operador puede reconocer una alarma, pero no saber cómo recuperar la copia de seguridad de configuración correcta. Un especialista en TI puede entender la red, pero tener poca experiencia con un sistema de control a nivel de máquina. Mientras tanto, el ingeniero que conoce el sistema completo puede estar trabajando en otro sitio o no disponible hasta el próximo turno.

Esto crea lo que los fabricantes deberían tratar como un único punto de fallo humano.

La planificación tradicional de la fuerza laboral a menudo se centra en los títulos de los puestos, el número de empleados y la finalización de la capacitación. Esas mediciones siguen siendo útiles, pero no necesariamente muestran si un activo automatizado crítico tiene una cobertura de respaldo genuina.

Una planta podría tener cinco empleados de mantenimiento y tres ingenieros de control, por ejemplo, pero aun así depender casi por completo de un individuo para una plataforma PLC en particular. Otra instalación puede tener varios especialistas en automatización, pero nadie calificado para soportar una interfaz heredada que conecta una máquina de producción con una base de datos más antigua.

La diferencia es la concentración de capacidad.

Para los fabricantes que operan sistemas PLC, plataformas DCS, sistemas de seguridad, celdas robóticas y redes de comunicación industrial, el primer paso es identificar qué activos requieren soporte especializado. La lista debe basarse en las consecuencias operativas en lugar de la popularidad de la tecnología.

Un sistema puede considerarse crítico porque su fallo afecta la seguridad de los trabajadores, la calidad del producto, los controles ambientales, el rendimiento de la producción o el tiempo de recuperación. En una instalación, eso podría significar un controlador de seguridad o una celda de robot. En otra, podría ser un sistema de control de procesos, un historiador, una plataforma de supervisión o una integración personalizada entre equipos de producción y software empresarial.

Una vez identificados esos sistemas, las empresas deben definir cómo se ve realmente una respuesta exitosa.

Simplemente decir que alguien necesita "conocimientos de PLC" no es suficiente. La capacidad requerida puede implicar varias tareas diferentes, incluyendo reconocer la falla, recopilar información de diagnóstico, verificar las alarmas, localizar una copia de seguridad aprobada, restaurar una configuración conocida y buena, verificar el estado del sistema y escalar el problema cuando excede la autoridad del empleado.

La modificación de software es otro asunto.

Una persona capaz de restaurar una configuración aprobada puede no estar calificada para realizar un cambio de programa. De manera similar, alguien que puede diagnosticar una falla de comunicación puede no tener la autorización para alterar la configuración de la red. Separar estas capacidades crea una imagen más realista de la preparación de la fuerza laboral y reduce la tentación de tratar cada habilidad técnica como intercambiable.

El mismo principio se aplica a la robótica y otras plataformas de automatización avanzadas. Saber que existe un robot en la planta no significa que un técnico esté listo para recuperarlo después de una falla del controlador o una actualización de software. La competencia práctica puede depender del modelo exacto de robot, la generación del controlador, el entorno de programación, la configuración de seguridad y los procedimientos de mantenimiento utilizados en la instalación.

La situación se complica aún más en múltiples turnos.

Una empresa puede tener dos o tres empleados que pueden solucionar de forma independiente un sistema de control crítico, pero si todos trabajan durante el día, el turno de noche todavía tiene un problema de cobertura. Un acuerdo de guardia puede reducir esa exposición, pero solo si la persona puede responder dentro del tiempo requerido y tiene acceso remoto, documentación y la autoridad necesaria.

Por eso, las evaluaciones de la fuerza laboral deben realizarse a nivel de sistema, turno y sitio, en lugar de simplemente a nivel organizacional.

Una evaluación de capacidad útil puede identificar al propietario técnico principal, al respaldo disponible, el nivel de habilidad demostrado del respaldo y la ruta de escalada. También debe mostrar si el respaldo tiene acceso a la documentación actual, archivos de configuración, herramientas de software, contraseñas u otros recursos autorizados necesarios para la respuesta asignada.

La distinción entre respaldo nominal y respaldo funcional es importante.

Agregar el nombre de otro empleado a una hoja de cálculo no crea redundancia. Un respaldo se vuelve significativo solo cuando esa persona puede realizar la tarea definida en condiciones operativas realistas.

Los fabricantes no necesitan interrumpir deliberadamente la producción para probar esto. Los ejercicios de resolución de problemas controlados, las ventanas de mantenimiento planificadas, los escenarios de mesa y los entornos de prueba aprobados pueden proporcionar evidencia sin crear riesgos operativos innecesarios.

Por ejemplo, una planta podría pedir a un técnico de respaldo que localice la documentación actual del PLC, identifique la última configuración aprobada, explique la secuencia de recuperación y determine cuándo se requiere una escalada. Otro ejercicio podría probar si el técnico sabe a qué proveedor o integrador de sistemas se debe contactar y qué información de diagnóstico se debe recopilar antes de realizar esa llamada.

Estos ejercicios a menudo revelan debilidades sorprendentemente básicas.

La documentación puede hacer referencia a un servidor que ya no existe. El archivo de respaldo puede estar almacenado en una ubicación a la que el técnico no puede acceder. Un acuerdo de soporte del proveedor puede cubrir solo el horario comercial normal, aunque el plan de recuperación de la empresa asuma asistencia nocturna. Una licencia de software puede estar vinculada a la estación de trabajo de un ingeniero. Una contraseña o un archivo de configuración pueden existir, pero no tener una propiedad documentada.

Ninguno de estos problemas representa necesariamente una falla tecnológica importante. Juntos, sin embargo, pueden extender significativamente el tiempo de inactividad.

Esto es particularmente importante para plantas con una infraestructura de automatización personalizada o envejecida. Un controlador moderno soportado por un gran ecosistema puede tener varios recursos de servicio disponibles. Una aplicación heredada con modificaciones indocumentadas puede ser mucho más difícil de transferir entre empleados.

El valor de la redundancia, por lo tanto, depende de las características del sistema.

Los fabricantes deben priorizar la cobertura según tres factores prácticos: la consecuencia de perder el soporte, el tiempo de respuesta requerido y la dificultad de transferir el conocimiento.

Un sistema de control crítico para la seguridad con un requisito de respuesta medido en minutos merece un modelo de dotación de personal diferente al de una aplicación de informes de producción que puede permanecer sin conexión durante la noche. Del mismo modo, una plataforma de automatización estándar puede ser más fácil de soportar a través de un proveedor de servicios externo que un entorno de control heredado altamente personalizado.

Este enfoque también cambia la forma en que las empresas deben pensar sobre la capacitación.

La finalización de la capacitación no es lo mismo que la preparación operativa.

Un empleado puede haber completado un curso de proveedor sobre un sistema PLC en particular, pero nunca haber realizado una recuperación independiente. Otro técnico puede haber trabajado con el equipo durante años, pero no tener experiencia con la última revisión del controlador. Un tercer empleado puede entender el proceso técnico, pero carecer de los derechos de acceso necesarios para ejecutarlo.

Por lo tanto, una evaluación de preparación significativa necesita evidencia de capacidad, no solo evidencia de asistencia.

Es probable que las organizaciones más eficaces combinen la capacitación formal con la resolución supervisada de problemas, la práctica específica del equipo, los procedimientos de recuperación documentados y las comprobaciones periódicas de competencia. Esto también facilita la identificación de dónde la capacitación cruzada adicional producirá la mayor reducción del riesgo operativo.

No todos los especialistas necesitan un reemplazo completo.

En muchas plantas, el objetivo no debe ser que todos los técnicos sean capaces de realizar todas las tareas de ingeniería. Eso sería costoso y, en algunos casos, innecesario. El objetivo más práctico es asegurar que la primera persona que responda a un problema pueda realizar de forma segura las tareas apropiadas para su función y localizar al especialista adecuado sin retrasos evitables.

Un modelo de soporte escalonado puede ayudar.

Un operador puede ser responsable de identificar la condición anormal y asegurar el proceso. Un técnico de mantenimiento puede realizar la sustitución de hardware aprobada o los procedimientos de restauración. Un ingeniero de control puede manejar el diagnóstico a nivel de programa y los cambios autorizados. Un integrador de sistemas externo o un OEM puede ser llamado cuando el problema requiera una experiencia más profunda.

Tal estructura aclara las responsabilidades y evita que las empresas asuman que un empleado debe ser capaz de manejar cada capa de la pila de automatización.

La planificación de la sucesión también debe extenderse más allá de los puestos de trabajo.

Una compañía puede tener un plan de sucesión para su gerente de automatización, pero no tener un reemplazo para el ingeniero que entiende una integración heredada particular. El puesto puede estar cubierto, pero el conocimiento del sistema no.

Por esta razón, las organizaciones deben considerar la creación de mapas de capacidades en torno a los activos de automatización críticos en lugar de depender únicamente de los organigramas convencionales. La pregunta no es solo quién puede reemplazar a un empleado. Es quién puede apoyar los sistemas que ese empleado apoya actualmente.

Estos mapas de capacidad también necesitan un mantenimiento regular.

Los entornos de automatización rara vez permanecen estáticos. Una actualización del controlador puede alterar los procedimientos de solución de problemas. Una nueva celda de producción puede introducir dependencias de comunicación adicionales. Un proyecto de ciberseguridad puede cambiar los permisos de acceso. Una migración de software puede invalidar un antiguo proceso de copia de seguridad. Incluso un cambio en los acuerdos de soporte del proveedor puede afectar la fiabilidad de un plan de escalada.

En consecuencia, la cobertura de la fuerza laboral debe revisarse después de cambios tecnológicos importantes, incidentes, cuasi accidentes y cambios organizativos significativos, en lugar de solo durante un ciclo de capacitación anual.

La revisión debe tener un propietario claro. Alguien debe verificar que la documentación esté actualizada, las copias de seguridad sean accesibles, los permisos sigan siendo válidos, los contactos de escalada sean correctos y los respaldos designados aún puedan realizar sus tareas asignadas.

Esto es particularmente importante a medida que los fabricantes aumentan el uso de la automatización conectada, el soporte remoto y los sistemas de producción basados en datos. Cuanto más interconectados estén los sistemas, más difícil puede ser definir dónde comienza y termina la responsabilidad técnica.

Un ingeniero de control puede ser el dueño del PLC. TI puede gestionar la red. Un OEM puede soportar la máquina. Un equipo de ciberseguridad puede controlar el acceso remoto. Operaciones puede ser el dueño del proceso de producción. Durante el funcionamiento normal, estos límites pueden funcionar bien. Durante un incidente, sin embargo, la responsabilidad poco clara puede crear retrasos adicionales.

La respuesta no es eliminar la especialización. La experiencia profunda sigue siendo esencial para la fabricación moderna.

En su lugar, las empresas necesitan comprender dónde se concentra esa experiencia y decidir qué dependencias son aceptables.

Las plantas automatizadas más resilientes no serán necesariamente aquellas con los equipos de ingeniería más grandes. Serán las que comprendan las capacidades necesarias para mantener operativos los sistemas críticos y tengan alternativas creíbles cuando un especialista clave no esté disponible.

La automatización está diseñada para reducir la dependencia de la intervención manual. Eso no significa que los fabricantes puedan ignorar la dependencia de la experiencia humana.

Si un sistema de producción solo puede ser recuperado por un empleado, la planta tiene un riesgo que puede no aparecer en su arquitectura de automatización, programa de mantenimiento u organigrama. El equipo puede ser redundante. La red puede ser resistente. Las copias de seguridad pueden existir.

Pero si el conocimiento necesario para usarlos pertenece a una sola persona, la operación sigue teniendo un único punto de fallo.

Para los operadores industriales, la prueba práctica es sencilla: cuando el especialista principal no está disponible, ¿puede otro empleado debidamente capacitado y autorizado realizar la respuesta requerida de forma segura, utilizando la documentación actual y dentro del plazo de recuperación previsto?

Si la respuesta nunca se ha demostrado, la organización debería tratar esa capacidad como un riesgo en lugar de asumir que está cubierta.

Escrito por: Daniel Mercer — Un escritor de tecnología de automatización y controles industriales con más de una década de experiencia cubriendo sistemas PLC, robótica, control de procesos, redes industriales y estrategia de fuerza laboral de fabricación.