¿Cómo organizar la colaboración entre el integrador, la software house y el departamento de mantenimiento en un mismo proyecto?

Por qué este tema es importante hoy

La colaboración entre el integrador, la empresa de desarrollo de software y el departamento de mantenimiento ha dejado de ser una mera cuestión de comodidad organizativa. En la práctica, hoy determina si un proyecto puede ponerse en marcha sin conflictos sobre el alcance, si un cambio en el software puede bloquear la aceptación técnica y si la planta será capaz de mantener la solución de forma segura una vez implantada. Cuanta más lógica de proceso se traslada a la capa de software y menos permanece en las funciones estándar de controladores y equipos, mayor es la importancia de definir con precisión los límites de responsabilidad. Si no se establecen desde el principio, el coste del proyecto normalmente no crece de forma lineal, sino por correcciones realizadas en el lugar equivocado: el integrador corrige interfaces, la empresa de desarrollo rehace la lógica de negocio y el departamento de mantenimiento solo al final hace visibles requisitos operativos que nadie había documentado antes.

También es una cuestión presupuestaria, no solo técnica. En muchos proyectos, la pregunta sobre la colaboración entre las partes se convierte muy rápido en otra: qué representa realmente el software a medida para la industria dentro del presupuesto de inversión, si un componente de la inversión, un coste de mantenimiento o una combinación de ambos. Si la arquitectura de la solución prevé que funciones clave del proceso, de la generación de informes, de las recetas, de la trazabilidad de lotes o de la integración con los sistemas de planta se desarrollen fuera del alcance estándar de la automatización industrial, esto debe identificarse antes del pedido y no después del primer prototipo. El criterio práctico es sencillo: si la ausencia de un único responsable de las decisiones en la frontera entre la automatización, la aplicación y la operación impide asignar con claridad los requisitos, las pruebas y los costes de los cambios, el proyecto ya ha entrado en una zona de alto riesgo y requiere corregir el modelo de colaboración.

Esto se aprecia con especial claridad en una modernización de línea en la que el integrador responde del control y de la puesta en marcha, la empresa de desarrollo de software de la capa de aplicación y del intercambio de datos, y el departamento de mantenimiento debe asumir después el sistema para la operación continua. Si el departamento de mantenimiento solo se incorpora en la fase de aceptación, suelen aflorar problemas que no son «fallos», sino carencias en la toma de decisiones: ausencia de un procedimiento de recuperación tras avería, falta de requisitos para las cuentas de servicio, ventanas de actualización no definidas, dependencia no prevista de un proveedor externo o visibilidad insuficiente de los errores. En ese momento, la discusión ya no gira en torno a la calidad del código o a la corrección del cuadro de control, sino a quién debe asumir el coste de adaptar el sistema a la realidad de la planta. En este punto, el tema se conecta de forma natural con los costes ocultos del proyecto y de la conformidad, porque el retraso en la aceptación o un cambio tardío en las funciones de seguridad, la documentación técnica o la validación suele ser consecuencia precisamente de una colaboración mal organizada, y no de un único error de ejecución.

El aspecto de la conformidad aparece cuando el reparto de tareas influye en las características del producto, en las funciones relacionadas con la seguridad, en la documentación o en la forma de poner la solución en servicio. No toda integración de una aplicación con una máquina activa las mismas obligaciones, pero la mera falta de claridad sobre quién responde de la descripción de funciones, de la gestión del cambio y de la integridad de la documentación ya es una señal de alerta. Esto afecta especialmente a los proyectos ejecutados dentro de la propia planta, a las modernizaciones realizadas por etapas y a las soluciones construidas para uso propio, donde la frontera entre «trabajo de mantenimiento» y fabricación o modificación sustancial puede tener relevancia legal. Por eso, la decisión sobre el modelo de colaboración no debe tomarse cuando aparece el primer conflicto, sino cuando se define el alcance: quién describe los requisitos operativos, quién aprueba la arquitectura, quién responde de las pruebas entre capas y quién asume el sistema tras la puesta en marcha con capacidad real para mantenerlo.

Dónde suelen aumentar el coste o el riesgo

En los proyectos desarrollados conjuntamente por el integrador, la empresa de desarrollo de software y el departamento de mantenimiento, el coste rara vez aumenta por un único gran error. Normalmente se incrementa en la interfaz entre responsabilidades, es decir, allí donde nadie tiene la obligación completa de llevar el asunto hasta el final. Lo más costoso no son los errores técnicos en sí mismos, sino las decisiones aplazadas o adoptadas sin un responsable claro: falta de una arquitectura de comunicación acordada, límites no definidos entre la lógica de control y la capa de aplicación, ausencia de un método de prueba tras los cambios y asunción del sistema para su explotación sin capacidad real de mantenimiento. En la práctica, esto significa correcciones realizadas ya después de la puesta en marcha, disputas sobre el alcance contractual y traslado de la responsabilidad por las paradas a una fase en la que cualquier cambio resulta más caro. Un criterio sencillo para evaluar la situación es preguntarse si para cada función crítica puede identificarse una parte responsable del requisito, otra de la ejecución y otra de la aceptación. Si la respuesta es «depende», el proyecto ya está expuesto a un riesgo organizativo.

Un segundo ámbito de pérdidas aparece cuando las decisiones de diseño se toman sin la participación del área de mantenimiento o, a la inversa, cuando mantenimiento impone soluciones cómodas para el servicio, pero incoherentes con la arquitectura del sistema. El integrador suele mirar el proyecto desde la puesta en marcha y la interacción con los equipos, la empresa de desarrollo de software desde la lógica de negocio y las interfaces, y mantenimiento desde la disponibilidad, el diagnóstico y el tiempo de recuperación del servicio. Si estas perspectivas no convergen en la fase de definición de requisitos, más adelante reaparecen en forma de costes de cambio: señales adicionales, rediseño de permisos, ausencia de registro de eventos necesarios para el diagnóstico, imposibilidad de realizar actualizaciones de forma segura o falta de un procedimiento para operar ante una avería. Es el momento en que el hilo conduce de forma natural al papel del responsable de proyecto de ingeniería, porque el problema deja de ser una decisión técnica aislada y pasa a ser la gestión de dependencias, plazos de coordinación y responsabilidad en la escalada.

Un ejemplo práctico típico es una implantación en la que la aplicación de nivel superior debe gestionar órdenes, recetas e informes, mientras que el integrador es responsable del controlador, los accionamientos y la secuencia de la máquina. Si el límite de responsabilidad se describe solo de forma funcional, sin indicar estados intermedios, condiciones de error y comportamiento ante la pérdida de comunicación, cada parte construirá sus propios supuestos «seguros». La empresa de desarrollo de software asumirá que la falta de confirmación implica repetir el comando, el integrador dará por hecho que el comando se ejecuta una sola vez, y mantenimiento recibirá un sistema que no se puede diagnosticar durante una parada. El resultado es previsible: una puesta en marcha larga, errores ambiguos, correcciones de interfaces y tensión en torno a la pregunta de quién responde por una parada no planificada. Al evaluar una situación así, conviene medir no solo la fecha de entrega, sino también el número de cambios en las interfaces tras la aprobación del proyecto, el número de incidencias detectadas únicamente en campo y el tiempo necesario para reconstruir la causa de la avería. Si estos indicadores aumentan a pesar del avance de los trabajos, el problema suele estar en la organización de la colaboración, y no en el rendimiento de un proveedor concreto.

Otra fuente de riesgo es tratar las pruebas y la documentación como un subproducto de la puesta en marcha. Allí donde el sistema influye en el funcionamiento de la máquina, el acceso del operario, el diagnóstico, los parámetros del proceso o las funciones relacionadas con la seguridad, un cambio tardío no es una simple corrección de software. Puede requerir una nueva evaluación de los supuestos de diseño, la actualización de la documentación técnica, la repetición de parte de los ensayos y, en determinados supuestos de hecho, también volver a analizar las obligaciones del usuario o de la entidad que introduce el cambio. Esto no puede resolverse de forma abstracta e igual para todos los proyectos, pero la regla práctica es sencilla: cuanto más influya el cambio en el comportamiento del sistema en estados normales y anómalos, menos debe gestionarse «mediante acuerdos de trabajo». Aquí empieza también el ámbito de los errores típicos que se encuentran en la construcción y modernización de máquinas: ausencia de bloqueos frente a configuraciones erróneas, falta de imposición de la secuencia de acciones y ausencia de mecanismos que eviten errores del operario o del servicio técnico. Si estas salvaguardas no se incluyen en el alcance desde el principio, más adelante vuelven en forma de coste, parada o disputa sobre responsabilidades; en contextos así, una auditoría de seguridad de máquinas y líneas de producción encaja de forma directa con los riesgos descritos.

Cómo abordar el tema en la práctica

En la práctica, la colaboración entre el integrador, la empresa de desarrollo de software y el departamento de mantenimiento no debería organizarse en torno a las empresas, sino en torno a los límites de responsabilidad sobre decisiones técnicas concretas. Eso determina quién responde de la lógica de control, quién de la capa de aplicación y la comunicación, y quién de las condiciones de servicio, las copias de seguridad, la recuperación tras una avería y la implantación segura de cambios en campo. Si estos límites siguen definidos de forma general, el proyecto empieza a funcionar sobre suposiciones: el integrador asume que la planta aportará los requisitos de explotación, la empresa de desarrollo de software da por cerrada la lógica del proceso, y mantenimiento recibe un sistema que no puede mantenerse de forma eficaz sin el autor del código. La consecuencia no es solo organizativa. Aumenta el coste de la puesta en marcha, se alarga la resolución de incidencias y, en caso de conflicto, resulta más difícil determinar si el problema deriva de un error de implementación, de supuestos incompletos o de un cambio no controlado tras la recepción.

Por eso, la primera decisión no debería ser la elección de la herramienta ni el calendario de talleres, sino la adopción de un modelo común de responsabilidad para todo el ciclo de vida de la solución. Para un manager, el criterio práctico es sencillo: toda función que influya en el funcionamiento de una máquina o línea debe tener un responsable asignado en cuatro estados del proyecto: diseño, puesta en marcha, recepción y mantenimiento. Si para una función concreta no se puede responder de forma inequívoca quién aprueba el requisito, quién ejecuta el cambio, quién prueba sus efectos y quién asume la responsabilidad de restablecer el funcionamiento tras una avería, entonces el alcance no está listo para su ejecución. En este punto aparece de forma natural el papel del responsable de proyecto de ingeniería: no como la persona «de los plazos», sino como el propietario del orden de decisión entre disciplinas y proveedores.

La mayoría de los problemas surgen en la interfaz entre el control y el software a medida. Un ejemplo típico es una aplicación que cambia la forma de seleccionar recetas, parametriza la secuencia de trabajo o afecta a los permisos del operario. Para una empresa de desarrollo de software para la industria puede parecer un simple cambio funcional, pero para el integrador y el equipo de mantenimiento supone una intervención en el comportamiento del sistema, el diagnóstico y los procedimientos de cambio de formato. Si antes de la implantación no se ha definido dónde termina la responsabilidad sobre la interfaz y dónde empieza la responsabilidad sobre la lógica del proceso, una corrección realizada «en producción» puede exigir nuevas pruebas, la actualización de instrucciones y, en algunos casos, la revisión de los procedimientos de servicio. Es precisamente aquí donde el asunto entra también en el terreno presupuestario: el coste del software a medida para la industria no depende solo de escribir el código, sino de cuánta responsabilidad traslada el proyecto a la fase de validación, documentación y mantenimiento posterior.

Para evitarlo, conviene evaluar el estado del proyecto no por las declaraciones de los proveedores, sino por los entregables que pueden verificarse. El conjunto mínimo incluye una lista de interfaces acordada, una descripción del versionado, un procedimiento de notificación y autorización de cambios, escenarios de pruebas de aceptación y un plan de mantenimiento tras la puesta en marcha. Aquí funciona bien un filtro de decisión breve:

• si el cambio afecta a la lógica del proceso, a los parámetros de trabajo o al comportamiento del operario,
• si puede reproducirse, probarse y revertirse sin la participación del autor de la solución,
• si la documentación posterior a la implantación permite a la planta mantener el sistema sin depender de conocimientos ocultos en la bandeja de correo del contratista.

Si la respuesta a cualquiera de estas preguntas es «no», el proyecto necesita una definición más precisa del alcance, no acelerar los trabajos. Solo en esta fase tiene sentido remitirse a los requisitos formales: no para añadir reservas genéricas al contrato, sino para comprobar si la naturaleza de los cambios ya afecta a las obligaciones de documentación, aceptación o a la evaluación de responsabilidades por parte del usuario. Esto es especialmente importante allí donde la propia planta co-crea la solución, la desarrolla con sus propios medios o construye elementos del sistema para uso interno. En ese caso, la colaboración entre las tres partes deja de ser únicamente una cuestión de organización del proyecto y pasa también al ámbito de las obligaciones legales de la planta.

Qué tener en cuenta durante la implantación

La mayoría de los problemas no aparecen cuando el equipo carece de competencias, sino cuando las partes del proyecto trabajan correctamente dentro de sus propios límites, pero nadie gestiona el punto de contacto entre ellas. En un proyecto en el que el integrador responde de la capa de ejecución y de las conexiones con la automatización, la empresa de desarrollo de software de la lógica de la aplicación y el mantenimiento de la continuidad operativa de la planta, una mala organización de la implantación casi siempre termina trasladando el riesgo a la fase de puesta en marcha. Es precisamente ahí donde se pone de manifiesto si las decisiones de proyecto se tomaron pensando en todo el ciclo de vida de la solución o solo en cerrar el alcance de cada contratista. Para el proyecto, esto suele traducirse en una de estas tres situaciones: correcciones costosas tras la puesta en marcha, una disputa sobre la responsabilidad de las averías o un retraso en la aceptación porque el sistema funciona solo en condiciones de laboratorio y no en el proceso real.

La principal trampa consiste en que la implantación suele tratarse como una fase técnica, cuando en la práctica es el momento en que se verifican las decisiones organizativas. Si el integrador puede introducir cambios en el control sin conocer plenamente sus efectos en la aplicación, la empresa de desarrollo crea funciones sin confirmar las limitaciones de los equipos y de la red industrial, y el equipo de mantenimiento se incorpora solo en la aceptación, entonces el problema no está en la comunicación, sino en un reparto defectuoso de responsabilidades. El criterio práctico de evaluación es sencillo: antes de entrar en planta, cada parte debe poder indicar qué cambios puede realizar por sí sola, cuáles requieren autorización conjunta y quién toma la decisión de detener los trabajos si aparece un riesgo para el proceso, la seguridad o la reproducibilidad de la configuración. Si la respuesta depende de «acuerdos sobre la marcha», la implantación todavía no está preparada, aunque el calendario encaje formalmente.

Un ejemplo típico se refiere a una modificación aparentemente menor: un cambio en la secuencia de trabajo de un puesto que, desde el punto de vista de la empresa de desarrollo, es una corrección de lógica; para el integrador implica tiempos de respuesta distintos de los equipos y, para mantenimiento, afecta al diagnóstico y a los procedimientos tras una avería. Si un cambio así llega a planta sin una revisión conjunta de sus efectos, después de la puesta en marcha resulta difícil determinar si el origen del problema está en el código, en la configuración del controlador, en los parámetros del accionamiento o en la forma de operación por parte del operario. En ese momento, el coste aumenta no solo por la propia corrección, sino también por el tiempo de parada, las pruebas adicionales y la implicación de personas que antes no tenían por qué participar en el análisis. Por eso conviene medir no solo la fecha de puesta en marcha, sino también el número de cambios de implantación sin una ruta completa de aprobación, el tiempo necesario para restaurar la versión anterior y la proporción de incidencias detectadas solo después de entregar el sistema para su explotación. Esto ofrece una imagen real de si la colaboración entre las tres partes está gestionada o simplemente sostenida de forma puntual.

En esta fase también aparece de forma natural la frontera entre una implantación convencional y una situación en la que la planta empieza a co-crear la solución de un modo que afecta a sus obligaciones formales. Si el departamento de mantenimiento no se limita a emitir su opinión, sino que modifica por sí mismo la lógica, selecciona elementos del sistema o asume parte de las decisiones de diseño, entonces el asunto deja de referirse únicamente a la organización de la colaboración y pasa también al ámbito de las máquinas fabricadas para uso propio. Esto no puede resolverse con una única regla válida para todos los proyectos; lo determinante es el alcance de la intervención, el grado de autonomía de la planta y quién define realmente las características de la solución. Lo mismo ocurre con el análisis de riesgos: si el cambio afecta a la función del proceso, al comportamiento del operario, a las condiciones de intervención de servicio o a la secuencia de estados de emergencia, entonces ya no se trata solo de «implantar o no», sino también de «si procede volver a evaluar el riesgo y actualizar los criterios de aceptación». En la práctica, es precisamente aquí donde más claramente se aprecia el papel de quien dirige el proyecto: no como mero intermediario de estados, sino como responsable de decidir cuándo termina una simplificación cómoda y empieza la responsabilidad técnica y legal. Para este tipo de decisiones, la gestión de proyectos y la certificación CE de máquinas marcan con claridad los límites de responsabilidad.