Gestión de proyectos de automatización: dirigir proyectos de PLC, SCADA y sistemas de control desde la URS hasta la puesta en marcha

Qué es la gestión de proyectos de automatización

La gestión de proyectos de automatización es la disciplina de planificar, ejecutar, coordinar y entregar proyectos de automatización industrial que instalan, configuran e integran sistemas de control (PLC, SCADA, DCS, sistemas de seguridad) en una planta de producción o una instalación de proceso. Se sitúa en el cruce entre la gestión de proyectos de ingeniería, la gestión de proyectos de IT y la gestión de proyectos operativos, toma de las tres pero no se reduce a ninguna, porque los proyectos de automatización tienen rasgos propios que los enfoques genéricos de gestión de proyectos no cubren por completo.

La definición y dónde encajan los proyectos de automatización

Un proyecto de automatización empieza cuando una organización de fabricación decide instalar nueva tecnología de control o modernizar los sistemas de control existentes, y termina cuando el sistema instalado funciona de forma segura y fiable en producción y cumple los requisitos operativos definidos al principio. El alcance suele incluir la selección y adquisición del hardware, la configuración y programación del software, la integración con los sistemas de planta existentes, las pruebas en varias etapas, la validación de seguridad y ciberseguridad, la formación de los operadores y la entrega formal a operaciones. Los tipos de proyecto habituales son las instalaciones greenfield (planta nueva, sin herencias), las modernizaciones brownfield (sustitución de sistemas de control obsoletos en una planta en marcha), las ampliaciones de capacidad (nuevas líneas de producción dentro de una arquitectura de automatización existente) y las actualizaciones de sistemas de seguridad (llevar instalaciones existentes a normas vigentes como la IEC 61511 Edición 2).

En qué se diferencian de los proyectos de fabricación habituales

Un proyecto de automatización no es un proyecto de fabricación habitual, aunque tenga lugar dentro de una empresa de producción. Cuatro diferencias son decisivas. Primera, el resultado es un sistema y no un producto: lo que se obtiene es una arquitectura de automatización en funcionamiento, no un único producto listo para vender, de modo que los criterios de éxito se centran en el rendimiento operativo y no en las características de un producto. Segunda, el trabajo es multidisciplinar por naturaleza de un modo que no lo son los proyectos de fabricación corrientes: mecánica, electricidad, software de control, infraestructura de IT e ingeniería de proceso deben converger en la misma fecha de instalación, a menudo con distintos contratistas responsables de distintas disciplinas. Tercera, el orden de validación es obligatorio e irreversible: FAT antes que SAT antes que puesta en marcha, sin atajos posibles, porque las dependencias físicas imponen la secuencia. Cuarta, los requisitos de seguridad y cumplimiento suelen tener un peso normativo que los proyectos de fabricación genéricos no afrontan con la misma intensidad, desde las normas de seguridad funcional hasta los requisitos de ciberseguridad y las regulaciones específicas del sector.

En qué se diferencian de los proyectos de IT

A veces los proyectos de automatización se gestionan por error como proyectos de IT, porque ambos incluyen software. Las diferencias son considerables. Los proyectos de IT suelen permitir el despliegue iterativo, la salida por fases a subconjuntos de usuarios y las correcciones rápidas tras la publicación. Los proyectos de automatización se despliegan en una instalación física donde el software controla procesos físicos con consecuencias reales: parchear un PLC en caliente en un reactor químico no es el mismo tipo de cambio que parchear una aplicación web. Los proyectos de IT se pueden pausar; las plantas en marcha, a menudo no. El fracaso de un proyecto de IT provoca por lo general pérdida de datos o molestias para el usuario; el fracaso de un proyecto de automatización puede provocar incidentes de seguridad, vertidos ambientales o incumplimientos normativos. Por eso existe la disciplina FAT-SAT-puesta en marcha y por eso recortarla genera consecuencias caras que los responsables de proyectos de IT quizá no reconozcan al principio.

Las seis fases de un proyecto de automatización: de la URS a la puesta en marcha

Los proyectos de automatización siguen una estructura consolidada de seis fases que se ha convertido en estándar en todos los sectores: química, farmacéutica, alimentación y bebidas, energía y fabricación general. Las fases son: Especificación de Requisitos de Usuario (URS), Especificación de Diseño Funcional y de Detalle (FDS, DDS), ingeniería y construcción, prueba de aceptación en fábrica (FAT), instalación y prueba de aceptación en sitio (SAT), y puesta en marcha. Cada fase tiene entradas, salidas y criterios de puerta definidos, y la disciplina de hacer cumplir los criterios de puerta entre fases separa los proyectos de automatización que se entregan a tiempo de aquellos que agotan su presupuesto en retrabajos en fases tardías.

Fase 1: Especificación de Requisitos de Usuario (URS)

La URS define qué debe lograr el sistema de automatización desde el punto de vista operativo: rendimiento objetivo de producción, especificaciones de producto, filosofía de control, requisitos de seguridad, restricciones normativas, expectativas de la interfaz de operador y puntos de integración con los sistemas de planta existentes y la IT corporativa. Una URS bien redactada, de forma parecida a un acta de constitución del proyecto, es funcional y no técnica: describe el resultado deseado sin prescribir la solución técnica. La calidad de la URS es el mejor predictor individual de los resultados de un proyecto de automatización, porque cada fase posterior hereda la ambigüedad o la exhaustividad de ese documento. Los proyectos que se saltan la URS o la tratan como una formalidad descubren una y otra vez, en el SAT o en la puesta en marcha, que distintas partes interesadas tenían supuestos diferentes sobre funciones básicas, y en ese momento el coste de alinearlas es órdenes de magnitud mayor de lo que habría sido en la fase de URS.

Fase 2: Especificación de Diseño Funcional y de Detalle (FDS, DDS)

La FDS traduce la URS en un diseño funcional: qué PLC, qué SCADA, qué topología de red, qué lazos de control, qué funciones de seguridad, qué alarmas y cómo se conectan entre sí y con la infraestructura de planta. La DDS llega después hasta el nivel de detalle técnico necesario para la ingeniería y la adquisición: modelos concretos de hardware, recuentos de E/S, planos de cableado, disposición de armarios, arquitectura de software, diseños de pantallas HMI. Las fases FDS y DDS incluyen revisiones de diseño con el cliente, y la aprobación al final de la DDS es el equivalente al congelado del diseño del proyecto de automatización. Los cambios posteriores a ese punto requieren gestión formal de cambios y, por lo general, alargan el cronograma.

Fase 3: Ingeniería y construcción

La ingeniería y la construcción abarcan la adquisición de hardware, el montaje de armarios, el desarrollo de software (código de PLC, pantallas SCADA, lógica de seguridad, configuración del historian), la instalación de la infraestructura de red y el montaje mecánico y eléctrico en sitio. Esta fase discurre en paralelo entre varias disciplinas y proveedores, y es aquí donde la coordinación entre disciplinas consume la mayor parte de la atención del director de proyecto. Los componentes de largo plazo de entrega identificados durante la FDS (instrumentos especiales, controladores con certificación de seguridad, equipos de red especializados) deben haberse pedido con antelación suficiente para que la ingeniería avance sin esperar al hardware. El desarrollo de software para PLC y SCADA suele realizarse tras la DDS, en paralelo con la adquisición del hardware, de modo que ambos estén listos juntos para el FAT.

Fase 4: Prueba de aceptación en fábrica (FAT)

El FAT se realiza en las instalaciones del proveedor o del integrador, antes del envío al sitio. El sistema de control completo (hardware de PLC, software SCADA, sistemas de seguridad) se monta y se prueba en un entorno controlado con entradas y salidas simuladas. El FAT valida que el hardware se ajusta a la DDS, que el software implementa correctamente la lógica funcional, que las alarmas y los enclavamientos se comportan según el diseño, que las pantallas HMI muestran la información especificada y que la integración entre subsistemas funciona. El FAT es la última oportunidad rentable de detectar defectos: las correcciones en FAT cuestan alrededor de diez veces menos que las mismas correcciones en SAT y cien veces menos que los fallos detectados en la puesta en marcha. Saltarse o recortar el FAT es la causa aislada más frecuente de sobrecostes caros en automatización.

Fase 5: Instalación y prueba de aceptación en sitio (SAT)

Tras la aprobación del FAT, el sistema se envía al sitio, lo instalan contratistas mecánicos y eléctricos y pasa el SAT. El SAT verifica que la instalación se ajusta a los planos, que las E/S físicas están correctamente conectadas a instrumentos y actuadores, que la integración con los sistemas de planta existentes funciona según el diseño y que las pruebas funcionales de extremo a extremo se superan en condiciones reales de instalación. En proyectos de SCADA y de proceso continuo, el SAT suele incluir una prueba prolongada de una a dos semanas para demostrar un funcionamiento estable sin incidencias mayores. Cuando varios subsistemas de distintos proveedores deben probarse juntos, tras los SAT individuales se realiza una prueba de integración en sitio (SIT), introducida formalmente en la IEC 62381:2024, para demostrar el funcionamiento integrado.

Fase 6: Puesta en marcha

En la puesta en marcha, el sistema validado se traslada a la producción en marcha. La puesta en marcha en frío prueba los sistemas sin material de proceso o con medios inocuos. La puesta en marcha en caliente introduce de forma gradual material de proceso real, con ajuste de lazos de control y secuencias y optimización hacia el rendimiento objetivo. La puesta en marcha termina con la entrega formal a operaciones, que requiere la formación completa de los operadores, la entrega de documentación (planos as-built, manuales de operación, instrucciones de mantenimiento), la disponibilidad de repuestos y el cumplimiento de los criterios de aceptación acordados. Los periodos de soporte posteriores a la puesta en marcha (por lo general de 30 a 90 días) permiten al integrador resolver los problemas que solo aparecen en condiciones reales de producción.

La columna vertebral de la validación: FAT, SAT, SIT y puesta en marcha

Las etapas de validación entre el final de la ingeniería y el inicio de la producción estable constituyen la disciplina que define la gestión de proyectos de automatización. Su orden es obligatorio y no se puede recortar: el hardware y el software deben validarse primero en un entorno controlado (FAT), verificarse después en el entorno instalado (SAT), integrarse a continuación con los subsistemas vecinos (SIT) y demostrarse por fin en condiciones reales de proceso (puesta en marcha). Cada etapa tiene objetivos distintos, criterios de aceptación distintos y una economía radicalmente distinta a la hora de detectar y corregir defectos.

FAT: detectar los fallos en el punto más barato

La prueba de aceptación en fábrica se realiza en las instalaciones del proveedor, en presencia del cliente o de un inspector independiente. El sistema de control completo, o un subconjunto funcionalmente completo, se monta en el banco de pruebas del proveedor y se prueba frente a un entorno de planta simulado con simuladores de E/S, estimulación de HMI y guiones de prueba funcional derivados de la FDS. El alcance típico del FAT cubre la verificación de E/S y la comprobación de lazos (cada canal de entrada y salida funciona y está correctamente asignado), las pruebas de lógica de control y funciones (enclavamientos, permisivos, alarmas y secuencias validadas frente a los P&ID y la especificación funcional), la inspección de hardware y cableado (dimensiones de armarios, etiquetado de conductores, puesta a tierra, montaje de componentes), las comprobaciones de calibración e instrumentos y la validación de ciberseguridad para los sistemas conectados en red. Un FAT bien ejecutado dura por lo general de uno a cinco días en las instalaciones del proveedor, según la complejidad del sistema. La razón económica de un FAT riguroso es clara: corregir un fallo en fábrica cuesta por lo general órdenes de magnitud menos que en campo, porque la corrección en fábrica no afecta al cronograma de la planta, no genera costes logísticos de sitio, no interrumpe operaciones ni exige removilizar cuadrillas.

SAT: verificar la instalación real y la integración

La prueba de aceptación en sitio se realiza tras la instalación en las instalaciones del cliente. Confirma que la instalación se ajusta a los planos, que las E/S físicas están correctamente conectadas a instrumentos y actuadores en la planta real, que la integración con los sistemas de planta existentes (procesos aguas arriba y aguas abajo, interfaces con MES y ERP) funciona según el diseño y que las pruebas funcionales de extremo a extremo se superan en condiciones reales de instalación. El SAT suele destapar problemas que el FAT no pudo captar: instrumentos mal cableados, configuraciones erróneas de dispositivos de campo, discrepancias de integración con sistemas heredados, interferencias electromagnéticas de instalaciones vecinas. En instalaciones de SCADA y de proceso continuo, el SAT suele incluir una prueba de estabilidad prolongada de una a dos semanas para demostrar que el sistema funciona de forma continua sin incidencias mayores. La aprobación del SAT es la puerta hacia la puesta en marcha.

SIT: integrar varios subsistemas

Las instalaciones industriales modernas rara vez se apoyan en una única plataforma de automatización. Una instalación de proceso típica integra varios PLC, controladores DCS, sistemas de seguridad, sistemas de detección de fuego y gas, unidades de paquete, centros de control de motores, variadores de frecuencia, analizadores, sistemas de protección eléctrica, historians, sistemas de gestión de activos y puestos de operador, a menudo de proveedores distintos. Cada subsistema puede superar el FAT y el SAT por separado, pero en cuanto los sistemas empiezan a intercambiar datos reales de proceso surgen a menudo problemas de integración. La prueba de integración en sitio (SIT), introducida formalmente como etapa estándar en la IEC 62381:2024, prueba todos los subsistemas de automatización actuando juntos como una única solución de control de proceso. El SIT es la respuesta adecuada a la complejidad de varios proveedores que los FAT y SAT individuales no pueden abordar.

Puesta en marcha: demostrar la preparación para producción

La puesta en marcha traslada el sistema validado a la producción en marcha. La puesta en marcha en frío comprueba el sistema sin material de proceso o con simulantes inocuos: las bombas funcionan, las válvulas se mueven, las secuencias se ejecutan, las alarmas informan, pero ningún producto está en riesgo. La puesta en marcha en caliente introduce de forma gradual material de proceso real, ajusta los lazos de control (parámetros PID, configuraciones en cascada, prealimentación) y optimiza las secuencias (recetas de lote, procedimientos de arranque y parada) hacia el rendimiento objetivo. La puesta en marcha es el momento en que se hace visible la calidad acumulada de URS, FDS, ingeniería, FAT y SAT: un proyecto que hizo bien las fases anteriores se pone en marcha en días o semanas, mientras que un proyecto que se saltó o recortó fases anteriores puede pasar meses en la puesta en marcha resolviendo problemas que deberían haberse detectado antes.

Coordinación multidisciplinar en los proyectos de automatización

Los proyectos de automatización son multidisciplinares por naturaleza de un modo que no lo son los proyectos de fabricación corrientes, un terreno en el que ayudan los principios del lean management aplicado a la gestión de proyectos. Un proyecto de automatización de tamaño medio típico implica al menos cinco disciplinas de ingeniería distintas trabajando en paralelo, a menudo de empresas diferentes, que deben converger en las mismas fechas de instalación y puesta en marcha. Coordinar los traspasos entre estas disciplinas absorbe la mayor parte de la atención del director de proyecto de automatización, y reducir la fricción en los traspasos es la mayor palanca sobre la duración total del proyecto.

Ingeniería mecánica y construcción

Los contratistas mecánicos instalan la infraestructura física de la que depende la automatización: tuberías, válvulas, actuadores, soportes de motores, bastidores de instrumentos, bandejas de cable. Su trabajo precede a la instalación eléctrica y de control, y los retrasos en la construcción mecánica se propagan a cada disciplina posterior. El alcance mecánico también incluye el suministro de aire y de hidráulica que necesitan instrumentos y actuadores, lo que debe coordinarse con la selección e instalación de instrumentos para evitar discrepancias en la puesta en marcha.

Ingeniería eléctrica e instalación

Los contratistas eléctricos instalan la distribución de energía, los centros de control de motores, el tendido de cables, el cableado de armarios y las conexiones de dispositivos de campo. Su secuencia sigue a la construcción mecánica y precede a la puesta en marcha del sistema de control. Los contratistas eléctricos suelen responsabilizarse también del esquema de puesta a tierra y equipotencialidad, decisivo tanto para la seguridad (protección eléctrica) como para la fiabilidad del sistema de control (supresión de ruido en los cables de señal). La coordinación entre los contratistas eléctricos y los integradores de sistemas de control en torno a listas de cables, disposición de armarios y listas de bornes es una fuente permanente de fricción en el proyecto que los directores de proyecto de automatización experimentados anticipan y rodean con su planificación.

Ingeniería e integración de los sistemas de control

El integrador del sistema de control se responsabiliza de la selección y programación del hardware de PLC, la configuración de SCADA y el desarrollo de pantallas, el diseño y la validación del sistema de seguridad, la arquitectura de red y la configuración del historian y los informes. Es la disciplina que entrega de forma más directa la funcionalidad de automatización que usará operaciones. Los integradores de sistemas de control a menudo subcontratan elementos concretos (programación del sistema de seguridad, evaluación de ciberseguridad, diseño de red) a empresas especializadas, lo que añade otra capa de coordinación que el director de proyecto debe gestionar.

Ingeniería de redes IT y OT

Los sistemas de automatización modernos están integrados en red y requieren su propia infraestructura de red, separada de la IT corporativa, con interfaces definidas allí donde se solapan. La ingeniería de redes IT/OT abarca la arquitectura de la red de control (por lo general variantes de Ethernet industrial), la segmentación entre la zona de control y la corporativa, las medidas de ciberseguridad conforme a la IEC 62443, las políticas de acceso remoto y la integración con el historian de planta y los sistemas MES. Los ingenieros de IT/OT quedaban históricamente fuera de los proyectos de automatización y se incorporaban tarde, pero los proyectos modernos se benefician de sumarlos desde la URS, porque las decisiones de red influyen en el diseño físico de los armarios y en el tendido de cables.

Ingeniería de proceso y operaciones

Los ingenieros de proceso aportan la filosofía de control que implementan el PLC y el SCADA: qué lazos necesitan qué estrategia de control, qué enclavamientos protegen frente a qué modos de fallo, qué alarmas deben ver los operadores. Operaciones aporta el conocimiento operativo que se convierte en el contenido de la URS: cómo funciona realmente la planta, qué necesitan los operadores en sus pantallas, qué secuencias requieren qué opciones, qué información ayuda a diagnosticar averías a las tres de la madrugada. Los proyectos de automatización que mantienen implicadas a la ingeniería de proceso y a operaciones desde la URS hasta la puesta en marcha superan de forma sistemática a los proyectos que las tratan como partes interesadas consultadas y no como participantes activos del proyecto.

Escollos habituales en los proyectos de automatización

Cinco patrones de fallo se repiten en los proyectos de automatización, sea cual sea el sector, y cada uno se puede prevenir con contramedidas concretas. Nombrar los patrones permite reconocerlos antes en proyectos futuros, cuando aún pueden atajarse por una fracción del coste de resolverlos en la puesta en marcha.

URS insuficientemente especificada llevada a ingeniería

El primer patrón es tratar la URS como una formalidad temprana en lugar de como el cimiento sobre el que descansa todo el proyecto. La URS se redacta deprisa para liberar la ingeniería, las ambigüedades permanecen en el documento con el supuesto de que se aclararán más tarde, y la ingeniería avanza frente a un conjunto de requisitos mal definido. Las consecuencias aparecen en el SAT y en la puesta en marcha: operaciones descubre que el sistema no hace algo que daba por hecho, o hace algo que nunca quiso, y resolverlo exige un rediseño que una URS sólida habría evitado. La contramedida es invertir el tiempo de calendario en una URS rigurosa con aprobación explícita de las partes interesadas y criterios de aceptación definidos antes de empezar la ingeniería, aunque parezca que retrasa el proyecto.

FAT recortado u omitido

El segundo patrón es tratar el FAT como un paso opcional que se puede recortar cuando el cronograma aprieta. El proveedor ha terminado el software y el hardware está montado, pero el cliente decide que el FAT es innecesario porque el proveedor prueba bien internamente, o que el FAT puede reducirse a una demostración en lugar de una prueba funcional completa. Las consecuencias aparecen en el SAT y en la puesta en marcha, donde cada defecto que el FAT habría atajado cuesta ahora entre diez y cien veces más resolver. La contramedida es tratar el FAT como innegociable con independencia de la presión de plazos y estructurar el alcance del FAT de forma tan concreta que una demostración no pueda pasar por una prueba.

Lagunas en la coordinación de varios proveedores sin SIT

El tercer patrón es dar por sentado que los FAT y SAT individuales de los proveedores bastan cuando varios subsistemas deben trabajar juntos. El sistema de cada proveedor supera sus propias pruebas, pero las interfaces entre sistemas no se validaron de forma conjunta, y los problemas de integración aparecen durante la puesta en marcha, cuando resolverlos es más caro. La contramedida es planificar una prueba de integración en sitio explícita cuando el proyecto incluye varios subsistemas de distintos proveedores, y definir el alcance del SIT ya durante la URS, para que los proveedores sepan que están obligados por contrato a participar en pruebas integradas y no solo a validar su propio subsistema.

Retrasos de disciplinas vecinas que se contagian a la automatización

El cuarto patrón es tratar la duración del proyecto de automatización como si fuera independiente del resto de disciplinas del sitio. La construcción mecánica se retrasa, la instalación eléctrica se retrasa, y el equipo de automatización llega para empezar el SAT solo para descubrir que la planta no está lista para recibirlo. Los cronogramas del equipo de automatización no suelen poder desplazarse en la misma dirección, porque las ventanas de puesta en marcha están ligadas a paradas de planta o a ventanas de arranque fijadas con mucha antelación. La contramedida es integrar de forma explícita los cronogramas del proyecto de automatización con los cronogramas mecánico y eléctrico, con hitos de preparación de cada disciplina para las actividades de automatización y con disparadores de escalado cuando una disciplina se desvía más allá del margen.

Validación de seguridad y ciberseguridad aplazada

El quinto patrón es tratar las pruebas de seguridad funcional y la validación de ciberseguridad como actividades ceremoniales del final en lugar de flujos de trabajo continuos a lo largo de todo el proyecto. Las funciones de seguridad exigen validación frente a la especificación de requisitos de seguridad durante todo el ciclo de vida, desde el diseño pasando por el FAT y el SAT hasta la puesta en marcha, y la ciberseguridad conforme a la IEC 62443 exige igualmente medidas en tiempo de diseño en lugar de una auditoría al final del proyecto. La contramedida es definir flujos de trabajo de seguridad y ciberseguridad con entregables explícitos por fase, dotarlos de recursos por separado de las pruebas funcionales y tratar la aceptación de seguridad y ciberseguridad como puertas propias en lugar de puntos de una lista de aceptación general.

Seguridad y cumplimiento en los proyectos de automatización

Los proyectos de automatización operan dentro de marcos normativos y de normas que los proyectos de fabricación genéricos rara vez afrontan con la misma intensidad. La seguridad funcional, la ciberseguridad, las regulaciones específicas del sector y las normas industriales plantean todas requisitos que deben incorporarse a la estructura del proyecto desde la URS, no añadirse en la puesta en marcha. Un fallo de cumplimiento en la entrega es en el mejor de los casos caro y en el peor bloquea las operaciones, y la disciplina de incorporar el cumplimiento al flujo del proyecto separa a los directores de proyecto de automatización que entregan a tiempo de los que pasan el último mes buscando evidencias para la auditoría.

Seguridad funcional conforme a IEC 61511 e IEC 61508

Los sistemas de seguridad en la industria de proceso siguen la IEC 61511 (con la IEC 61508 como norma de base). Los requisitos del ciclo de vida incluyen el análisis de peligros y riesgos, la asignación de funciones de seguridad a funciones instrumentadas de seguridad (SIF) con niveles de integridad de seguridad (SIL), la especificación de requisitos de seguridad, el diseño y la ingeniería con verificación de SIL, la validación en la instalación y la puesta en marcha, y los procedimientos de operación y mantenimiento. La seguridad no se puede añadir en la puesta en marcha; debe estar presente en cada fase. Los proyectos de automatización que tratan la seguridad como un flujo de trabajo propio desde la URS generan evidencias listas para auditoría como resultado natural del proyecto, mientras que los proyectos que tratan la seguridad como una actividad de aceptación final suelen descubrir tarde que las lagunas de documentación o los problemas de diseño exigen retrabajo.

Ciberseguridad conforme a IEC 62443

Los sistemas de automatización y control industrial se enfrentan a amenazas de ciberseguridad que los marcos de seguridad de IT no cubren por completo. La IEC 62443 define los requisitos de ciberseguridad para la automatización industrial, incluidas la segmentación de red entre las zonas de IT y OT, el acceso remoto seguro, la gestión de parches de los sistemas de control, el registro de eventos de seguridad y la gestión de vulnerabilidades. Los requisitos de ciberseguridad deben definirse durante la URS y trasladarse a la FDS, la DDS y la ingeniería. Añadir la ciberseguridad en la puesta en marcha es caro y rara vez da resultados satisfactorios, porque las decisiones fundamentales de arquitectura ya se han tomado.

Regulaciones específicas del sector

Distintos sectores industriales añaden requisitos de cumplimiento específicos a los proyectos de automatización. Los proyectos farmacéuticos y de ciencias de la vida siguen el Anexo 15 de las GMP de la UE, que reconoce expresamente el papel del FAT y el SAT en la cualificación y exige evidencia documentada de la instrumentación crítica, la calibración y la verificación del proceso. La FDA 21 CFR Part 11 se aplica a los registros y firmas electrónicos en ciencias de la vida. Los proyectos de alimentación y bebidas siguen los principios HACCP con normas sectoriales de diseño higiénico y trazabilidad. Los proyectos de energía y utilities siguen la NERC CIP para la ciberseguridad de la red. Los proyectos de industria general requieren evidencia del marcado CE y las normas ISO pertinentes de seguridad, rendimiento y especificaciones técnicas. Los requisitos del sector deben identificarse durante la URS, y el cronograma del proyecto debe contemplar las actividades de auditoría y documentación que imponen.

Gestionar varios proyectos de automatización a nivel de cartera

Una empresa de ingeniería que entrega proyectos de automatización, o un fabricante con varias iniciativas de automatización simultáneas, rara vez tiene un solo proyecto en marcha. Lo más habitual es que la cartera incluya varios proyectos en fases distintas que compiten por el mismo talento de ingeniería, las mismas instalaciones de prueba, la misma capacidad de integración y las mismas ventanas de puesta en marcha. La vista de cartera es donde la gestión de proyectos de automatización pasa de ser una disciplina de proyecto a una capacidad organizativa, y donde están disponibles las mayores mejoras en el rendimiento global.

El panel de cartera de proyectos de automatización

Un panel de cartera de proyectos de automatización muestra todos los proyectos activos clasificados por fase (URS, FDS, ingeniería, FAT, SAT, puesta en marcha), con visibilidad de qué proyectos se acercan a revisiones de puerta, cuáles están bloqueados y cuántos hay en cada fase. El panel revela patrones que las vistas de un solo proyecto ocultan: cuellos de botella sistemáticos en la planificación del FAT con el mismo integrador, ventanas de puesta en marcha que se agolpan en franjas estrechas del calendario, competencia por recursos en capacidades especializadas como la programación de sistemas de seguridad. El reconocimiento de patrones a nivel de cartera impulsa la mejora sistémica en lugar de la extinción de incendios reactiva proyecto a proyecto.

Competencia por recursos en capacidades especializadas

Los proyectos de automatización dependen de capacidades especializadas que suelen ser escasas: programadores de sistemas de seguridad, especialistas en ciberseguridad, arquitectos de red, expertos en determinadas plataformas de PLC, ingenieros de puesta en marcha con experiencia sectorial. Los recursos compartidos se convierten en la mayor fuente de retrasos no planificados en una cartera de varios proyectos. La competencia por recursos, invisible a nivel de proyecto, se hace visible a nivel de cartera, donde el mismo especialista que aparece a la vez en varios cronogramas de proyecto pone de manifiesto la doble reserva que los directores de proyecto individuales no pueden ver. Una gestión de cartera eficaz detecta pronto estos cuellos de botella y, o bien añade capacidad, o bien secuencia los proyectos para reducir la competencia, o bien acepta los retrasos como decisiones de cartera visibles.

Estandarización entre proyectos

Las carteras maduras de proyectos de automatización estandarizan los elementos recurrentes: plantillas de URS por tipo de proyecto, estructuras de FDS, formatos de guiones de prueba de FAT, criterios de aceptación de SAT, listas de comprobación de puesta en marcha, plantillas de documentación de seguridad, procedimientos de evaluación de ciberseguridad. La estandarización evita reinventar los elementos rutinarios en cada proyecto y libera la atención de ingeniería para las partes que de verdad difieren. La estandarización también posibilita el aprendizaje entre proyectos: un patrón de fallo detectado en el FAT de un proyecto actualiza las plantillas, de modo que los proyectos posteriores atajan antes la misma clase de defecto. Las empresas de ingeniería con una estandarización madura entregan proyectos más rápido y con menos variabilidad que las empresas donde cada proyecto reinventa su propio enfoque.

Planificación de capacidad y decisiones de oferta a nivel de cartera

La visibilidad a nivel de cartera de la carga actual de proyectos y de la disponibilidad prevista de recursos respalda las decisiones comerciales que las empresas de ingeniería toman de forma continua: a qué ofertas presentarse, qué fechas de entrega comprometer, cuándo contratar, cuándo decir que no a determinadas oportunidades. Las empresas sin datos de capacidad a nivel de cartera suelen sobrecargarse en las fases optimistas y contenerse en las conservadoras, y la variabilidad de entrega resultante deteriora las relaciones con los clientes y la retención del personal. Las empresas con datos de cartera pueden tomar decisiones de oferta a partir de la capacidad de entrega real y no a partir del optimismo sobre cuánto puede asumir el equipo.

Caso de estudio A: Smart Automation, ejecución disciplinada de la cartera

Smart Automation es una empresa de ingeniería de Olsztyn, Polonia, activa en la automatización industrial desde 2009. La empresa diseña y entrega sistemas de automatización completos, desde conceptos de máquina y análisis de viabilidad hasta la programación de sistemas de control y los sistemas de visión artificial, la automatización robotizada de procesos y la construcción de máquinas especializadas. La experiencia del equipo suma más de 300 años en automatización, robótica y mecatrónica. La empresa ha completado más de 1000 proyectos para clientes como IKEA, Michelin, Siemens Energy, Unilever y Danone, lo que en la práctica significa varias decenas de proyectos simultáneos en cualquier momento, distintos en alcance, complejidad y ubicación.

El punto de partida antes de implantar FlexiProject era familiar para las empresas de ingeniería: los presupuestos se gestionaban en soluciones en torno al sistema ERP, porque allí residen las facturas, los pagos y los costes, pero cada director de proyecto había desarrollado un enfoque personal para el control financiero. Las herramientas de planificación de cronogramas, seguimiento de riesgos y planificación de recursos faltaban en lo esencial. No había una visión completa ni de un solo proyecto, y menos aún de toda la cartera. La empresa decidió buscar un sistema de gestión de proyectos dedicado que reuniera cronogramas, presupuestos, riesgos y recursos en un solo lugar y se convirtiera en la única fuente de información sobre los proyectos.

La implantación abarcó toda la organización. En tres meses, los 51 proyectos activos de complejidad diversa se trasladaron a FlexiProject. Hoy todos los empleados y los subcontratistas clave usan el sistema, 37 personas en total, lo que resultó viable gracias a un pool de licencias flexible. Más importante aún: la empresa entendió la implantación como una oportunidad para construir un estándar común de gestión de proyectos, no solo para sustituir una herramienta. Ahora cada proyecto empieza igual: con un acta de constitución que define objetivos, alcance y responsabilidades, y con un modelo de fases que ordena el trabajo desde el concepto hasta la entrega. Los cronogramas se crean a partir de una plantilla común con dependencias de Gantt e hitos, y cada plan se guarda como línea base: un punto de referencia aprobado frente al que se miden las desviaciones de plazo y coste.

Los datos de presupuesto debían mantenerse coherentes con el sistema ERP, así que FlexiProject se integró con el ERP de modo que la información de costes fluye entre los sistemas sin doble registro. Más allá de los proyectos, la estructura flexible permitió reflejar el proceso de oferta y el servicio de garantía y posgarantía. Dos factores impulsaron la adopción. Primero, el director general actuó como patrocinador activo del proyecto, exigió de forma constante que toda la información de proyecto viviera en un solo sistema y esperaba actualizaciones periódicas de cada director de proyecto. Segundo, la barrera de entrada fue baja: construir cronogramas y presupuestos era lo bastante intuitivo como para que cualquier director de proyecto, sea cual fuera su experiencia, pudiera empezar la formación introduciendo un proyecto real propio en lugar de practicar con ejemplos artificiales. Los resultados se aprecian en las decisiones: desviaciones de presupuesto con previsión hasta la finalización, uso de recursos como insumo para las decisiones de oferta y los planes de contratación, revisiones de proyecto cada dos semanas para los proyectos activos y mensuales para los proyectos en fase de planificación, todo a partir de los datos del sistema en lugar de presentaciones elaboradas a mano.

Caso de estudio B: la crisis de automatización del Model 3 de Tesla, 2017-2018

El aumento de producción del Model 3 de Tesla entre 2017 y 2018 es uno de los fracasos de proyecto de automatización mejor documentados públicamente de la historia industrial, insólito por la disposición de Elon Musk a admitirlo con sus propias palabras. El Model 3 se anunció en 2016 como el primer vehículo de mercado masivo de Tesla, con un precio objetivo de 35 000 USD, y en las 24 horas siguientes al lanzamiento 115 000 personas habían hecho reservas. Tesla se fijó el objetivo ambicioso de producir 5000 unidades del Model 3 por semana para finales de 2017 y adoptó un enfoque que Musk describiría más tarde como «automatizarlo todo», apostando a que una automatización extensa permitiría el volumen necesario para atender la acumulación de pedidos previos.

El resultado fue lo que el propio Musk llamó «el infierno de la producción». Tesla incumplió con creces el objetivo de finales de 2017 y produjo 2425 unidades del Model 3 en todo el cuarto trimestre de 2017 (frente a un objetivo de 5000 por semana). El objetivo revisado para finales del primer trimestre de 2018, de 2500 por semana, también se incumplió: Tesla alcanzó 2020 en la última semana del primer trimestre. Tanto el montaje de módulos de batería en la Gigafactory como la línea de montaje final en Fremont tenían diseños de automatización que resultaron poco fiables a volumen de producción. Los analistas de Bernstein sostuvieron públicamente que la sobreautomatización grabó los errores de Tesla en la línea de producción y costó más de lo que aportó. El 13 de abril de 2018, Musk admitió públicamente en Twitter: «Sí, el exceso de automatización en Tesla fue un error. Para ser precisos, mi error. Los humanos están infravalorados.» En una entrevista con la CBS describió el desmantelamiento de una «red enloquecida y compleja de cintas transportadoras» que no funcionaba, y Tesla acabó devolviendo partes de la línea de montaje a operación manual, incluida la conocida línea de montaje provisional en «carpa» de Fremont, que añadió capacidad mediante trabajo manual en lugar de más automatización.

Tres lecciones se trasladan directamente a cualquier proyecto de automatización. Primera, la ambición de automatizar sin validación piloto multiplica el riesgo en lugar de reducirlo: la decisión de Tesla de desplegar automatización nueva a escala de producción antes de validarla a volumen piloto multiplicó la dificultad de cada ciclo posterior de resolución de problemas, cuando un aumento gradual habría destapado los problemas de automatización a menor coste. Segunda, sobreautomatizar pasos de submontaje que requieren adaptabilidad produce peores resultados que las alternativas semiautomatizadas en las que las personas asumen la variación y las máquinas el trabajo repetible: es un principio conocido de la práctica de fabricación japonesa que Tesla, en la práctica, redescubrió bajo la presión de producción. Tercera, los compromisos de cronograma de proyecto que dan por hecho que la tecnología funcionará según lo previsto, sin margen suficiente para destapar problemas de automatización, generan una presión que dificulta la resolución disciplinada de problemas en lugar de facilitarla. Tesla acabó alcanzando el objetivo de 5000 por semana a finales de junio de 2018 y más que duplicó su producción total de 2017, pero el precio de lograrlo mediante una crisis en lugar de un aumento gradual disciplinado fue considerable.

Cómo apoya FlexiProject los proyectos de automatización

FlexiProject apoya el nivel de ejecución de la gestión de proyectos de automatización con visibilidad de cartera, gestión de cronogramas, seguimiento de riesgos, revisiones estructuradas y plantillas estandarizadas. La coordinación multidisciplinar de los proyectos de automatización, en particular el trabajo de armonizar las funciones de mecánica, electricidad, sistemas de control, IT/OT e ingeniería de proceso, sigue siendo responsabilidad de la organización. FlexiProject aporta la infraestructura operativa que hace manejable la ejecución disciplinada de proyectos de automatización a gran escala, no un sustituto de la colaboración de ingeniería de la que depende el éxito de un proyecto de automatización.

Vista de cartera para proyectos de automatización simultáneos

FlexiProject ofrece un panel de cartera que muestra todos los proyectos de automatización activos en una sola vista, clasificados por fase (URS, FDS, ingeniería, FAT, SAT, puesta en marcha) y por cliente o unidad de negocio, con visibilidad de qué proyectos se acercan a revisiones de puerta y cuáles están bloqueados. La vista de cartera saca a la luz patrones que las vistas de un solo proyecto ocultan, como ventanas de puesta en marcha que se agolpan en franjas estrechas del calendario, competencia por recursos en capacidades especializadas y retrasos sistemáticos en la planificación del FAT con determinados integradores. Los comités de dirección que toman decisiones a nivel de cartera trabajan desde la misma vista de cartera, en lugar de conciliar informes de proyecto distintos.

Cronograma con diagrama de Gantt, lista de tareas y kanban

El cronograma en FlexiProject combina una vista de diagrama de Gantt para el seguimiento de hitos y la visualización de dependencias, una vista de lista de tareas para el trabajo de ejecución detallado y una vista kanban para la disciplina de flujo dentro de las fases. Los proyectos de automatización se benefician de la combinación: el diagrama de Gantt gestiona la estructura a nivel de fase con dependencias desde la URS hasta la puesta en marcha e hitos de revisión de puerta, las listas de tareas gestionan el trabajo detallado de ingeniería y pruebas dentro de las fases, y el kanban sigue el flujo de entregables concretos por la revisión y la aprobación. Los iconos de aviso en las tareas del cronograma señalan problemas de presupuesto o de riesgo sin necesidad de informes separados.

Registro de riesgos, vinculado a las fases del proyecto

El registro de riesgos en FlexiProject sigue los riesgos propios de la automatización con responsables, planes de mitigación y ritmo de revisión. Los riesgos específicos de fase (disponibilidad de componentes de largo plazo de entrega durante la ingeniería, preparación del proveedor para el FAT, preparación del sitio para el SAT, disponibilidad de la planta para la puesta en marcha, validación del sistema de seguridad, evaluación de ciberseguridad) se vinculan a los hitos de fase relevantes y se revisan en la puerta correspondiente. La vinculación entre riesgos, tareas y cronograma hace que un riesgo que se materializa repercuta de forma visible en el plazo asociado, en lugar de quedar en un registro aparte que nadie consulta al tomar decisiones de plazo.

Revisiones de proyecto como revisiones de puerta

Las revisiones de proyecto en FlexiProject pueden estructurarse como revisiones de puerta formales de proyectos de automatización, con criterios definidos, presentación estructurada de evidencias y decisiones formales de continuar o no continuar registradas en el acta del proyecto. El ritmo de revisión es planificado (por lo general al final de cada fase del proyecto y en cada transición FAT/SAT/puesta en marcha), y los resultados de las revisiones alimentan las plantillas estandarizadas de proyectos posteriores. Los criterios de puerta configurados en las plantillas se aplican de forma coherente entre proyectos del mismo tipo, de modo que la puerta de aprobación del FAT de un proyecto usa la misma estructura de criterios que la puerta de aprobación del FAT de otro.

Plantillas estandarizadas para proyectos de automatización

FlexiProject ofrece plantillas estandarizadas para la estructura recurrente de los proyectos de automatización, con el modelo de seis fases, la columna vertebral de validación FAT-SAT-puesta en marcha, los entregables estándar por fase y unos criterios de puerta estándar adecuados a la automatización. Las empresas de ingeniería pueden ampliar las plantillas según las particularidades del tipo de proyecto (greenfield, modernización brownfield, ampliación de capacidad, actualización de seguridad) sin renunciar a la estructura de base. La gestión de proyectos de automatización basada en plantillas actúa como el equivalente digital de la práctica de ingeniería estandarizada: evita reinventar los elementos rutinarios del proyecto y libera la atención de ingeniería para las partes de cada proyecto que de verdad difieren.

Lo que FlexiProject no hace

FlexiProject no realiza la ingeniería (ese es el trabajo del integrador del sistema de control), no realiza el FAT ni el SAT (requieren bancos de prueba e instrumentación), no cualifica proveedores (requiere procesos de compras y calidad) y no sustituye la disciplina de hacer cumplir los criterios de puerta (requiere el compromiso de la dirección). Aporta la visibilidad, la estructura y la trazabilidad que hacen manejable la ejecución disciplinada de proyectos de automatización en una cartera, pero la disciplina en sí es organizativa.

Preguntas frecuentes

¿En qué se diferencia la gestión de proyectos de automatización de la gestión de proyectos general?

Los principios generales de gestión de proyectos se aplican a los proyectos de automatización, pero estos tienen rasgos propios que los enfoques generales no cubren por completo: una columna vertebral de validación secuencial y obligatoria (FAT antes que SAT antes que puesta en marcha), una complejidad multidisciplinar inherente que abarca mecánica, electricidad, software de control, IT/OT e ingeniería de proceso, requisitos de seguridad y cumplimiento con peso normativo, y dependencia de varios proveedores externos cuyos retrasos se propagan de forma imprevisible. Los directores de proyecto de automatización suelen tener formación de ingeniería y experiencia sectorial específica, porque el contenido técnico de las decisiones influye en los resultados del proyecto a un nivel que la gestión de proyectos general no puede sustituir.

¿Cuánto dura un proyecto de automatización típico?

Depende del alcance, la complejidad y el sector. Una instalación greenfield sencilla con integración limitada puede completarse en seis a nueve meses. Una modernización brownfield típica con integración en sistemas de planta existentes suele durar de doce a dieciocho meses. Los grandes proyectos de inversión con tecnología novedosa o elementos críticos de seguridad pueden durar de dos a tres años. El mayor factor aislado del cronograma no suele ser la complejidad de ingeniería, sino la complejidad de coordinación: los proyectos con muchos proveedores y disciplinas duran más que los proyectos con menos participantes, aunque el trabajo técnico sea similar.

¿De quién es el proyecto de automatización?

Un director de proyecto de automatización se responsabiliza del cronograma, la coordinación, las revisiones de puerta y la alineación entre disciplinas, pero el trabajo es multidisciplinar por naturaleza y ninguna función lo controla en solitario. Los contratistas mecánicos se responsabilizan de la infraestructura física, los contratistas eléctricos de la alimentación y el cableado, el integrador del sistema de control de la entrega del PLC y el SCADA, los ingenieros de IT/OT de la infraestructura de red, los ingenieros de proceso de la filosofía de control y operaciones de los requisitos que el sistema debe cumplir. El director de proyecto de automatización es el coordinador e integrador entre estas funciones. El apoyo de la alta dirección es imprescindible, porque las decisiones de puerta tienen implicaciones comerciales y de seguridad que exceden la autoridad del director de proyecto.

¿Cuál es la diferencia entre FAT y SAT?

El FAT (prueba de aceptación en fábrica) se realiza en las instalaciones del proveedor o del integrador antes del envío al sitio, con entradas y salidas simuladas, para validar el hardware y el software en un entorno controlado. El SAT (prueba de aceptación en sitio) se realiza tras la instalación en las instalaciones del cliente y verifica que la instalación se ajusta a los planos, que las E/S físicas están correctamente conectadas a instrumentos y actuadores reales y que la integración con los sistemas de planta existentes funciona. El FAT ataja los fallos en el punto más barato del ciclo de vida; el SAT ataja los problemas que solo aparecen en el entorno real de instalación. Ninguno puede sustituir al otro, y por lo general ambos son necesarios.

¿Son obligatorios por ley el FAT y el SAT?

Depende del sector. Los proyectos farmacéuticos y de ciencias de la vida requieren el FAT y el SAT en la práctica conforme al Anexo 15 de las GMP de la UE, que reconoce expresamente su papel en la cualificación. Para las instalaciones de industria general, el marcado CE y las normas ISO pertinentes exigen evidencia de que la instalación cumple las especificaciones de seguridad, rendimiento y técnicas, y el FAT y el SAT son los mecanismos estándar para aportar esa evidencia. Incluso donde no son estrictamente obligatorios por ley, el FAT y el SAT son práctica habitual en la mayoría de los sectores industriales, porque la razón económica de atajar los fallos en el punto más temprano posible está bien documentada.

¿Pueden los proyectos de automatización seguir métodos ágiles?

Los proyectos de automatización tienen dependencias físicas que limitan la aplicabilidad de los métodos puramente ágiles: el hardware necesita plazo de aprovisionamiento, la puesta en marcha requiere ventanas de disponibilidad de la planta, la validación de seguridad sigue secuencias normativas que no se pueden iterar. Elementos del pensamiento ágil encajan bien, en especial el refinamiento iterativo de la URS con las partes interesadas antes del congelado del diseño y la depuración iterativa durante el FAT y la puesta en marcha. Pero la estructura de fases desde la URS hasta la puesta en marcha es una columna vertebral en cascada, porque las restricciones físicas y normativas la imponen, y los intentos de aplicar métodos puramente ágiles a los proyectos de automatización suelen dar peores resultados que el enfoque disciplinado de fases y puertas.

La gestión de proyectos de automatización es la disciplina de entregar proyectos de automatización industrial desde la Especificación de Requisitos de Usuario, pasando por ingeniería, FAT, SAT y puesta en marcha, hasta la producción estable, distinta de la gestión de proyectos de fabricación genérica por su columna vertebral de validación secuencial y obligatoria, su complejidad multidisciplinar inherente, la intensidad de la seguridad y el cumplimiento y la dependencia de la coordinación de varios proveedores. La estructura de seis fases desde la URS hasta la puesta en marcha aporta el marco, y la columna vertebral de validación FAT-SAT-SIT-puesta en marcha aporta la disciplina que la define, con fallos detectados en FAT que cuestan un orden de magnitud menos que en SAT y dos órdenes de magnitud menos que durante la puesta en marcha. La coordinación multidisciplinar entre las funciones de mecánica, electricidad, sistemas de control, IT/OT e ingeniería de proceso absorbe la mayor parte de la atención del director de proyecto, y reducir la fricción en los traspasos es la mayor palanca aislada sobre la duración total del proyecto. Cinco patrones de fallo (URS insuficientemente especificada, FAT recortado, lagunas en la coordinación de varios proveedores sin SIT, retrasos de disciplinas vecinas que se contagian, y seguridad y ciberseguridad aplazadas) se pueden prevenir con contramedidas concretas. Los requisitos de seguridad y cumplimiento, incluidas la IEC 61511, la IEC 62443 y las regulaciones específicas del sector, deben incorporarse al flujo del proyecto desde la URS. La visibilidad a nivel de cartera de los proyectos de automatización simultáneos posibilita las decisiones de recursos, estandarización y capacidad que las empresas de ingeniería toman de forma continua. El caso de Smart Automation muestra que una empresa de ingeniería de tamaño medio puede construir en meses un estándar de proyecto disciplinado en torno a un sistema común, mientras que el caso del Model 3 de Tesla muestra que la ambición de automatizar sin validación piloto ni ejecución disciplinada de fases y puertas genera «el infierno de la producción» a la mayor escala posible. FlexiProject apoya el nivel de ejecución de la gestión de proyectos de automatización con visibilidad de cartera, gestión de cronogramas que combina las vistas de diagrama de Gantt, lista de tareas y kanban, un registro de riesgos vinculado a las fases, revisiones estructuradas como revisiones de puerta y plantillas de proyecto estandarizadas. La coordinación multidisciplinar de ingeniería y el cumplimiento disciplinado de los criterios de puerta siguen siendo responsabilidades organizativas. Cuando la cartera de proyectos de automatización de una empresa de ingeniería ha superado las hojas de cálculo y necesita un sistema que sostenga la disciplina entre varios proyectos simultáneos y equipos multidisciplinares, treinta días de acceso completo sin tarjeta de crédito son una forma práctica de comprobar si encaja.