El desarrollo de la fábrica y la arquitectura IT/OT: ¿por qué las integraciones provisionales acaban pasándose factura al cabo de unos años?

Por qué este tema importa hoy

El desarrollo de una fábrica cada vez consiste menos en añadir una sola máquina o poner en marcha otra línea de forma aislada. Normalmente implica ampliar un entorno en el que los sistemas de producción, el mantenimiento, la calidad, la planificación, el almacén y la generación de informes para la dirección deben intercambiar datos y, al mismo tiempo, influyen entre sí en la disponibilidad del proceso. En este contexto, la arquitectura IT/OT deja de ser una cuestión técnica «que ya se resolverá más adelante» y pasa a ser una decisión de proyecto con consecuencias financieras y organizativas. Las integraciones provisionales funcionan en la fase de puesta en marcha porque resuelven un problema inmediato: conectan rápidamente una máquina nueva, exportan algunas señales a un informe o sortean las limitaciones de un controlador antiguo. El problema aparece al cabo de unos años, cuando la planta intenta aumentar la productividad, cumplir nuevos requisitos de conformidad o modificar de forma segura el modo de funcionamiento de la instalación. Entonces se hace evidente que el problema no es un cable o un script concreto, sino la falta de reglas coherentes de comunicación, responsabilidades y separación de funciones.

El mayor error consiste en tratar este tipo de soluciones como si fueran neutras en términos de coste. En realidad, solo desplazan el coste en el tiempo y, por lo general, lo hacen en el peor momento posible: durante una ampliación, una auditoría, un incidente o un cambio de proveedor. Desde la perspectiva del proyecto, la consecuencia no es únicamente que la implantación de la siguiente fase resulte más cara, sino también la pérdida de previsibilidad. El equipo deja de saber qué dependencias son críticas para la continuidad de la producción, dónde termina la responsabilidad del integrador y dónde empieza la del propietario de la planta, o qué cambios requieren una nueva evaluación del riesgo. En la práctica, aquí es precisamente donde empieza el ámbito de los costes ocultos de unas decisiones de proyecto erróneas: paradas adicionales, trabajos de servicio puntuales, nuevas recepciones, dificultades para documentar los cambios y disputas sobre el alcance de la garantía. Si la arquitectura no se ha descrito como un modelo consciente de desarrollo de la fábrica, cada etapa posterior quedará lastrada por deuda técnica y organizativa.

Una buena comprobación práctica no es preguntarse si la integración «funciona», sino si puede modificarse de forma segura y previsible dentro de dos o tres fases más de la inversión. Si una línea nueva exige mapear señales manualmente en varios puntos, el conocimiento sobre las conexiones está repartido entre distintos proveedores y reconstruir la trazabilidad completa de los datos requiere analizar el código de los controladores, bases de datos intermedias y servicios no documentados, el proyecto ya ha entrado en una senda de riesgo elevado. Conviene evaluar la situación con tres criterios medibles: el tiempo necesario para introducir un cambio controlado, la posibilidad de identificar de forma inequívoca al responsable de cada intercambio de datos y la capacidad de reconstruir el impacto de una avería o una modificación sobre la producción y la seguridad. Si estos tres aspectos no pueden determinarse con claridad, el problema no afecta a la comodidad del equipo, sino a la capacidad de control de toda la iniciativa.

El ejemplo práctico se repite con frecuencia: una planta pone en marcha una nueva área de producción y, para arrancar rápidamente, conecta los datos de proceso con los sistemas de negocio mediante soluciones intermedias creadas al margen de la arquitectura objetivo. Durante un tiempo, todo parece correcto, porque el flujo de datos basta para la elaboración de informes y la supervisión operativa. La dificultad aparece con una automatización posterior, con la integración con el mantenimiento o al cambiar la lógica de funcionamiento de la máquina. Entonces, una sola modificación en la capa operativa afecta a los informes, las alarmas, las recetas o el acceso remoto, y las dependencias dejan de ser evidentes. Si, además, la solución interfiere en funciones relacionadas con la parada, el corte de energía o el bloqueo del rearranque, el asunto deja de ser exclusivamente informático. Entra en el ámbito de la seguridad funcional y requiere un análisis independiente, incluida la verificación de si no se han vulnerado los supuestos relativos a la protección frente al arranque inesperado. En este punto, la arquitectura IT/OT se relaciona directamente con el análisis de riesgos en el proyecto de desarrollo de la fábrica y con decisiones que más adelante también afectan al alcance de la evaluación de la conformidad y de la documentación técnica.

Por eso este tema exige una decisión ahora, y no después de terminar la puesta en marcha. No porque toda integración deba ser compleja desde el principio, sino porque ya desde el inicio hay que distinguir entre una solución temporal y una solución que va a formar parte de la arquitectura permanente de la planta. Esa distinción debe tener consecuencias de proyecto: un responsable específico de la decisión, condiciones para retirar la solución provisional, requisitos de documentación y criterios de nueva evaluación en caso de ampliación. Si la planta prevé nuevas fases de inversión, la modernización de máquinas o la preparación para la evaluación de la conformidad, la ausencia de esta distinción casi siempre incrementa el coste del cambio y amplía el alcance de la responsabilidad por parte del inversor. Precisamente por eso, la arquitectura IT/OT ya no es un complemento del proyecto, sino una de las condiciones para mantener el control sobre el coste, el calendario y el riesgo.

Dónde suelen aumentar más el coste o el riesgo

Lo más costoso en el desarrollo de una fábrica no suelen ser las propias interfaces entre IT y OT, sino las consecuencias de decisiones tomadas «de forma provisional» que, al cabo de unos años, empiezan a funcionar como una arquitectura permanente. La integración improvisada acaba pasando factura no tanto porque fuera técnicamente imperfecta, sino porque nadie definió sus límites: quién responde de los cambios, qué datos son la fuente maestra, cómo restaurar la configuración tras una avería y en qué momento debe eliminarse la solución de compromiso. En la práctica, el coste aumenta cuando una solución temporal pasa a formar parte del mantenimiento, la producción, la calidad o el reporting de gestión sin una decisión formal de que, desde ese momento, se convierte en un elemento crítico. Para el proyecto, esto implica conflictos posteriores sobre presupuesto y alcance y, para la organización, también una dilución de responsabilidades: la avería parece un problema técnico, aunque su origen sea una decisión arquitectónica que nunca se cerró. Un criterio útil de evaluación aquí es una pregunta sencilla: tras la ampliación de la planta, ¿se puede identificar al responsable del proceso, al responsable de los datos y un procedimiento de cambio seguro sin recurrir a «la única persona que sabe cómo funciona»? Si no es así, el riesgo ya está incorporado al proyecto.

La segunda área en la que se acumulan costes es la falta de separación entre la capa de control y la capa de intercambio de datos de negocio. En la primera fase de la inversión, este atajo puede resultar tentador: el mismo servidor intermedia en la comunicación con la máquina, archiva datos, alimenta informes y gestiona el acceso remoto del servicio técnico. En una línea individual parece funcionar correctamente, pero en las siguientes fases de ampliación cada cambio orientado a un objetivo afecta a los demás. Una actualización impuesta por el sistema corporativo puede comprometer la continuidad de la producción, y la necesidad de generar informes más rápidos puede llevar a intervenir en la configuración de equipos que antes funcionaban de forma estable. En ese momento, los costes ocultos de decisiones de diseño erróneas no se limitan a la compra adicional de hardware o a los servicios del integrador. Mucho más gravosos son los costes de las paradas, las nuevas pruebas, el trabajo nocturno durante las implantaciones y la necesidad de reconstruir conocimientos que no quedaron documentados en ninguna parte. Desde el punto de vista de la gestión del proyecto, el mínimo razonable es evaluar si una avería o un cambio en la parte informática puede detener la función operativa de la máquina o de la línea. Si la respuesta es afirmativa, la arquitectura IT/OT requiere corrección, con independencia de que «por ahora funcione».

Un ejemplo típico aparece al conectar máquinas nuevas a la infraestructura existente de la planta. El proveedor pone el equipo en marcha rápidamente porque hace falta la recepción y el arranque de la producción, por lo que la comunicación con los sistemas de planta se resuelve mediante un ordenador adicional, un script que exporta archivos o un mapa de señales modificado manualmente. Al cabo de un año se incorpora otra máquina, a los dos años cambia el sistema superior y, a los tres, resulta que nadie es capaz de describir con claridad qué mensajes son críticos para el proceso, cuáles sirven solo para informes y cuáles son relevantes para el diagnóstico o la trazabilidad del lote. En este punto, el asunto entra ya parcialmente en el ámbito de la elaboración de instrucciones de uso de máquinas, porque si el operario, el personal de mantenimiento o el servicio técnico no disponen de pautas documentadas para actuar ante una pérdida de comunicación, una operación manual de bypass o la restauración de parámetros tras la sustitución de un componente, el problema deja de ser exclusivamente informático. Pasa a formar parte de la organización de una explotación segura y de la responsabilidad posterior por la forma de uso y por las modificaciones.

Solo en esta fase se ve por qué la cuestión reaparece también al evaluar la conformidad, la documentación técnica y la presupuestación de cambios. Si la integración afecta a las funciones de la máquina, a la lógica de los enclavamientos, a la forma de confirmar estados o a la información transmitida al usuario, puede ser necesaria una nueva evaluación de riesgos y verificar si la documentación sigue correspondiéndose con la solución real. El alcance de esta evaluación depende de la naturaleza del cambio, por lo que no puede resolverse honestamente con una única frase universal, pero precisamente por eso las soluciones provisionales resultan tan costosas: dificultan determinar qué se ha modificado realmente y cuáles son las consecuencias legales y operativas. Para el equipo de decisión, el criterio práctico es el siguiente: si el cambio en la integración no puede describirse en la documentación de configuración, en el procedimiento de prueba y en las normas de explotación sin recurrir a conocimientos informales, el proyecto ya ha entrado en una zona en la que aumenta no solo el coste técnico, sino también la responsabilidad del inversor, del director del proyecto y de las personas que autorizan la puesta en servicio de la solución.

Cómo abordar el tema en la práctica

En la práctica, la pregunta no es si integrar IT y OT más rápido, sino dónde fijar el límite entre una solución temporal y una deuda arquitectónica que dentro de unos años bloqueará el desarrollo de la fábrica. Las conexiones provisionales suelen surgir bajo la presión de la puesta en marcha: hay que extraer datos de la máquina con rapidez, añadir una nueva línea, unir el sistema de calidad con los registros de producción o garantizar el acceso remoto del servicio técnico. El problema empieza cuando una solución implantada «para salir del paso» se convierte en la base de decisiones posteriores, como una decisión de proyecto con consecuencias económicas y organizativas. El equipo pierde una distribución clara de responsabilidades y cada ampliación exige reconstruir el conocimiento a partir de correos, configuraciones locales y la práctica de los operarios. Esto ya no es una pequeña incomodidad técnica, sino un factor que afecta al calendario, al coste del cambio y a la capacidad de demostrar quién autorizó una determinada solución para su puesta en servicio y sobre qué base lo hizo.

Por eso, el enfoque correcto empieza con una decisión de arquitectura, no con la elección de una herramienta. El responsable o propietario del área debe exigir que toda nueva integración tenga definido su objetivo operativo, un responsable a ambos lados de la frontera IT/OT y las condiciones de mantenimiento una vez puesta en marcha. Si no está claro quién responde por la fuente de datos, quién aprueba un cambio de configuración, quién verifica los efectos sobre el proceso y quién decide el modo de contingencia, en la práctica el proyecto traslada el riesgo a la fase de explotación. Ahí es donde empieza de forma natural el papel del jefe de proyecto en las decisiones IT/OT: no como coordinador de plazos, sino como la persona que obliga a definir las responsabilidades antes de que una solución provisional quede incorporada al presupuesto y al cronograma como «atajo rápido». El criterio práctico de evaluación es sencillo: si la integración prevista no puede mantenerse tras un cambio de proveedor, la sustitución del controlador o la ampliación de la línea sin la intervención del autor del apaño inicial, entonces no se trata de una solución temporal, sino de un coste futuro del proyecto.

Una buena prueba es la ampliación de una línea existente con un puesto adicional que debe enviar datos al sistema superior y, al mismo tiempo, reaccionar a los estados de la parte que ya está en funcionamiento. Si el equipo opta por conectar señales directamente y hacer una traducción informal de datos «porque así será más rápido», al principio todo puede funcionar correctamente. Sin embargo, con el tiempo aparecen efectos secundarios: resulta más difícil determinar si el fallo proviene de la lógica de la máquina, de la capa de comunicación o de la aplicación de informes; las pruebas de aceptación solo cubren escenarios estándar; la modernización de un elemento obliga a introducir correcciones en varios puntos a la vez. Es entonces cuando afloran también los costes ocultos de decisiones de diseño erróneas: paradas adicionales para diagnóstico, la costosa presencia del integrador en cada cambio, disputas sobre el alcance de la garantía y retrasos en las siguientes fases de la inversión. Por eso conviene medir no solo el tiempo de puesta en marcha, sino también el número de puntos de integración que requieren configuración manual, el tiempo necesario para analizar un incidente tras un cambio y la cantidad de modificaciones que deben probarse de forma transversal en lugar de local.

Solo en este contexto tiene sentido referirse a los requisitos de seguridad y conformidad. Si la integración afecta a los estados de funcionamiento de la máquina, a los enclavamientos, a las confirmaciones de señal o a la secuencia de arranque o parada, deja de ser un complemento informático neutral. Según la naturaleza del cambio, esto puede hacer necesaria una nueva evaluación de riesgos, la actualización de la documentación técnica y la verificación de si la forma de uso sigue ajustándose a las hipótesis adoptadas para esa máquina o línea. Esto se aprecia con especial claridad allí donde la capa de integración empieza a influir indirectamente en las condiciones de acceso seguro, el corte de energía o la prevención de una puesta en marcha inesperada. En ese caso, la decisión de arquitectura deja de pertenecer al ámbito de la comodidad de implantación y pasa al terreno de la responsabilidad jurídica y técnica. Si el equipo no es capaz de demostrar qué conexiones tienen un carácter exclusivamente informativo y cuáles influyen en el comportamiento de la máquina, es una señal de que el asunto debe salir del nivel de «integración de sistemas» y tratarse como un cambio relevante para la seguridad, el presupuesto y la responsabilidad de las personas que aprueban la solución.

Qué tener en cuenta en la implantación

La mayoría de los problemas no se deben a la integración IT/OT en sí, sino a que en el proyecto se la trata como un recurso rápido para activar una nueva función y no como un elemento duradero de la arquitectura IT/OT de la fábrica. Es precisamente entonces cuando las conexiones provisionales pasan factura al cabo de unos años: al ampliar la línea, sustituir controladores, cambiar de proveedor del sistema superior o durante una auditoría de seguridad de máquinas y líneas de producción, resulta que nadie puede identificar con claridad al responsable de la interfaz, sus reglas de funcionamiento ni las consecuencias de un fallo. Para el proyecto, esto no solo implica el coste de la deuda técnica, sino también un coste organizativo: más coordinaciones, pruebas transversales más largas, recepciones más complejas y un mayor riesgo de que el retraso aparezca justo al final, cuando el cronograma ya es menos flexible. En este punto, el tema pasa de forma natural al ámbito de los costes ocultos de decisiones de diseño erróneas, porque el origen del problema no es un fallo puntual de ejecución, sino la decisión de dejar para más adelante una arquitectura sólida.

Por eso, durante la implantación conviene evaluar la solución no por si «funciona ahora», sino por si puede mantenerse y modificarse con seguridad de forma previsible. El criterio práctico es simple: si la integración prevista no tiene definido el alcance de responsabilidades, el modo de fallo, las reglas de versionado y el procedimiento de pruebas tras un cambio, entonces todavía no está lista para su implantación en producción, aunque funcione en un puesto de pruebas. Esto es especialmente importante allí donde la misma interfaz debe dar servicio a la fase actual de la inversión y a una futura ampliación. El desarrollo de la fábrica casi siempre incrementa el número de dependencias entre sistemas, y las soluciones provisionales funcionan peor precisamente cuando crece el número de excepciones, atajos y acuerdos locales. Desde la perspectiva del jefe de proyecto, esto implica la necesidad de decidir desde el principio quién aprueba las decisiones de frontera entre automatización, mantenimiento, informática y conformidad, porque sin ello la responsabilidad se diluye exactamente allí donde después surge la mayor disputa sobre coste y plazo.

Un ejemplo práctico típico es añadir el intercambio de datos entre la línea y el sistema de reporting mediante un script intermedio o un servicio no documentado ejecutado en un servidor que «ya está en planta». En la fase de puesta en marcha, la solución parece razonable: no exige cambios por parte del proveedor de la máquina, acorta la implantación y permite mostrar rápidamente un resultado de negocio. El problema aparece después. Tras una actualización del sistema operativo, un cambio de direccionamiento, la restauración de una copia de seguridad o la sustitución de un equipo, nadie tiene la certeza de si la lógica de mapeo de señales sigue correspondiéndose con la realidad del proceso. Si este mecanismo interviene en confirmaciones, bloqueos, cola de órdenes o condiciones de arranque, la avería deja de ser un incidente informático y empieza a afectar a la disponibilidad de la línea, a la calidad de la producción y a la responsabilidad por la puesta en servicio de la solución. En ese momento, la cuestión pasa de forma natural al análisis de riesgos dentro del proyecto de ampliación de la fábrica, porque hay que evaluar no solo la probabilidad de fallo, sino también las consecuencias de una información errónea, una secuencia incorrecta y una reacción equivocada del operario.

Solo en este contexto tiene sentido remitirse a los requisitos formales. Si la capa de integración sigue siendo exclusivamente informativa y esto puede demostrarse técnicamente, el alcance de las obligaciones será distinto que cuando influye en el comportamiento de la máquina o de la línea. Sin embargo, si afecta a la lógica de funcionamiento, a las condiciones de arranque, parada, confirmación o bypass, la implantación debe tratarse como un cambio con relevancia técnica y potencialmente de seguridad, y no como una simple ampliación del sistema. Esto puede implicar la necesidad de volver a verificar las hipótesis de la evaluación de riesgos, la documentación técnica y las condiciones de conformidad adoptadas para esa solución. En la práctica, la decisión segura no es «si esto se puede conectar», sino «si después de la implantación seremos capaces de demostrar qué hace esta interfaz, quién es responsable de ella y cómo controlamos el cambio» dentro de una arquitectura IT/OT. Si la respuesta no es inequívoca, el coste de la decisión arquitectónica aplazada suele reaparecer en la siguiente modernización, certificación o incidente, y entonces ya no será solo un problema técnico, sino también de gestión.