Saltar al contenido
Volver a experiencia

Ficha de puesto

Industria 4.0 · AMOA · Product Owner

Saint-Gobain Glass France · planta de Chantereine · Thourotte, Oise

Durante veinticinco semanas trabajé en el taller COMPO de la planta de Chantereine, dentro del perímetro de transformación digital e Industria 4.0 y bajo la supervisión del coordinador de proyectos 4.0. Mi misión combinó análisis de procesos industriales, AMOA, Product Ownership, modelado funcional, desarrollo sobre una plataforma Ignition SCADA, estructuración de datos, gestión de usuarios, validación en condiciones reales de planta, documentación técnica, formación y acompañamiento al cambio.

El proyecto partió de una necesidad operacional, no de unas especificaciones cerradas, y el mismo trabajo terminó defendido desde dos perspectivas académicas diferentes: en Arts et Métiers desde el diagnóstico y la transformación del proceso, y en la UNET desde la ingeniería del sistema, su arquitectura y los resultados obtenidos. Esa doble lectura resume bastante bien lo que fue la misión: comprender primero el proceso físico y después construir una representación digital capaz de acompañarlo.

Planta de Chantereine, Thourotte
Saint-Gobain Glass France · planta de Chantereine

feb 2025 — jul 2025

Ignition SCADASQLOT/ITAMOA

  • Digitalización
  • Operaciones
  • Personas
25SemanasFebrero a julio de 2025, a jornada completa en planta
2Memorias defendidasSFE en ENSAM Cluny · TAP en la UNET
8,5 / 9Evaluación del tutorJefe de línea · categoría «excelente»
9 / 9Nota del TAPJurado de la UNET, diciembre de 2025

Mi responsabilidad

Diagnóstico de proceso, requisitos, arquitectura funcional, desarrollo SCADA, modelo de datos, perfiles de usuario, validación en planta, formación y documentación.

Resultado

Sistema desplegado, 26 procedimientos operativos, 2 manuales técnicos y transferencia a los usuarios.

El reto

  • La logística del taller COMPO se sostenía en tres libros de Excel independientes, actualizados a mano una vez al día
  • La información existía pero estaba fragmentada: no había una secuencia digital única del recorrido del material
  • Preparar información para auditorías internas y externas exigía consolidar fuentes y comprobarlas manualmente
  • No recibí un cahier des charges: actores, operaciones, excepciones y reglas de negocio estaban por definir

Cómo lo abordé

  1. Diagnóstico en plantaDediqué las cinco primeras semanas a analizar documentos históricos, observar el taller y entrevistar a operarios, responsables e informática.
  2. Formalización del flujoDefiní qué dato nacía en cada etapa, quién lo generaba, quién debía validarlo y qué evento permitía pasar a la etapa siguiente.
  3. Modelo de datos y perfilesEstructuré la base de datos en ocho dominios y la interfaz en seis perfiles de usuario antes de dar por terminada ninguna ventana.
  4. Desarrollo iterativo con FDDAvancé por funcionalidades validadas con los usuarios en el taller en funcionamiento, no en un entorno aislado.
  5. Documentación y transferenciaPreparé 26 procedimientos ilustrados y dos manuales técnicos, y formé al personal del departamento.

Vista del sistema

Ventana del puesto de guardia en Ignition SCADA: registro de pesaje de camiones
El puesto de guardia, primera etapa del recorrido. Simple o doble pesada, entidad, transportista, naturaleza del material y destino. El peso no se teclea: lo lee el autómata de la báscula.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

Bloques de trabajo

Requisitos desde el taller

Construí la definición funcional a partir del funcionamiento real: cada necesidad expresada se convirtió en una función verificable, con origen, responsable y uso de cada dato.

De flujo físico a estados

Convertí el recorrido del material (llegada, registro, pesaje, control, silo, producción, expedición) en estados con transiciones definidas, en lugar de formularios aislados.

Modelo de datos en ocho dominios

Diseñé la base de datos para dos fines: el operativo, saber qué ocurre en ese momento, y el histórico, reconstruir después el recorrido para trazabilidad y auditoría.

Desarrollo en Ignition SCADA

Desarrollé las ventanas filtradas por seis perfiles, con lógica de alarmas para las excepciones: información incompleta, resultados pendientes, validaciones que dependen de otro perfil.

Coherencia OT/IT

Mantuve alineadas interfaz, lógica, datos y operación física; el peso de la báscula lo lee el autómata a través de un convertidor serie-Ethernet, sin teclearlo.

Product Owner y comités

Asumí el perímetro funcional, decidí qué no desarrollar y preparé los comités de pilotaje separando el detalle técnico del detalle útil para decidir.

01

El encargo

Esquema de flujo de información entre los usuarios propuesto para el diseño en Ignition
El esquema de flujo de información entre usuarios que presenté como propuesta de diseño. De aquí salió la estructura funcional de la aplicación.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

Me incorporé como asistente a la dirección de proyecto, AMOA dentro de la organización de Saint-Gobain, en el equipo encargado de la transformación digital de la planta y reportando al coordinador de proyectos 4.0. La misión consistía en desarrollar una herramienta de gestión para uno de los talleres de fabricación y transformación de vidrio plano, con un alcance que incluía recogida de necesidades, formalización funcional, análisis y modelado, desarrollo de una herramienta de restitución, formación, acompañamiento de los usuarios, recopilación de feedback e iteraciones sucesivas. La formulación inicial podía hacer pensar en un proyecto principalmente informático, pero en la práctica el trabajo comenzó bastante antes del código: no recibí un cahier des charges que describiera de antemano cada actor, cada operación, cada excepción y cada regla de negocio, y una parte central de mi responsabilidad consistió precisamente en construir esa definición a partir del funcionamiento real del taller.

Para hacerlo tuve que observar el proceso directamente en planta, revisar la documentación existente, hablar con operarios, responsables de producción y personal de informática, identificar los puntos donde se generaba información y comprender qué decisiones dependían de ella. Mi trabajo estaba situado entre dos lenguajes: por un lado el de producción, reaprovisionamientos, camiones, pesajes, materias primas, calcín, controles, silos, movimientos, validaciones, producción, expediciones e incidencias; por otro el del sistema, entidades, estados, reglas funcionales, perfiles de usuario, permisos, validaciones, eventos, interfaces, persistencia de datos y trazabilidad. La dificultad no estaba en traducir palabras de un dominio a otro, sino en conseguir que ambos describieran exactamente el mismo proceso: cada necesidad expresada desde el taller tenía que convertirse en una función verificable, cada pantalla responder a una etapa concreta, cada dato tener un origen, un responsable y un uso, y cada transición corresponder a algo que realmente ocurriera en la operación. Ese trabajo de formalización fue la base del proyecto.

02

Un semestre, dos memorias, dos dominios

Puesto de trabajo en planta con el modelo de datos, el código y la ventana de registro
El puesto durante el desarrollo. A la izquierda el modelo de datos, al fondo el código, a la derecha la ventana de registro de materiales en Ignition. Sobre la mesa, los procedimientos en borrador.

El mismo proyecto industrial terminó convertido en dos trabajos académicos diferentes porque cada institución evaluaba una dimensión distinta de la experiencia. Ante Arts et Métiers presenté el SFE, «Optimisation des Processus Logistiques et Industriels par Digitalisation SCADA»: 69 páginas centradas principalmente en el diagnóstico, la transformación del proceso y la transferencia hacia los usuarios, con el contexto industrial, el estado del arte, la metodología, los resultados obtenidos y veintitrés anexos de procedimientos, dirigido por un profesor de la escuela y por mi tutor de empresa. Ante la UNET presenté el TAP, «Optimización de procesos industriales y logísticos mediante transformación digital, automatización inteligente e integración de sistemas SCADA», donde el enfoque se desplazó hacia la ingeniería del sistema, su arquitectura, su funcionamiento y los cambios que podían demostrarse de forma medible.

No fueron dos versiones traducidas de un mismo documento. Tuve que volver a analizar mi propio trabajo desde dos marcos diferentes: en Arts et Métiers debía explicar cómo había diagnosticado un proceso industrial, cómo había estructurado su transformación y cómo había preparado la transferencia de la solución hacia los usuarios; en la UNET tenía que profundizar en cómo estaba construido el sistema, cómo se relacionaban sus componentes y qué permitían demostrar los resultados obtenidos. Trabajar de esta manera me obligó a separar tres niveles que en un proyecto industrial suelen estar permanentemente relacionados: el proceso describe cómo funciona la operación física, el sistema describe cómo esa operación se representa, controla y documenta digitalmente, y el desempeño permite evaluar si la transformación produjo un resultado observable. Aprender a moverme entre esos tres niveles fue una de las partes más útiles de la experiencia, porque es exactamente el cambio de perspectiva que aparece después entre producción, informática, dirección de proyecto y comités de pilotaje.

03

El entorno industrial

Chantereine, en Thourotte, es una de las tres plantas industriales de Saint-Gobain Glass en Francia. Mi proyecto se desarrolló principalmente en COMPO, el taller encargado de recibir, controlar y dosificar las materias primas y el calcín utilizados posteriormente en la fabricación de vidrio flotado, y comprender ese lugar dentro del proceso fue necesario antes de diseñar cualquier herramienta.

COMPO se encuentra aguas arriba del horno y su función no consiste únicamente en almacenar materiales: forma parte de la preparación de la composición que alimenta el proceso de fusión y, por tanto, participa en una cadena industrial continua en la que la regularidad del suministro, la calidad de las materias primas, la identificación de los materiales y la trazabilidad tienen consecuencias operativas directas.

La composición como entrada de proceso

En la fabricación de vidrio float, el proceso comienza con la preparación del batch, es decir, la mezcla dosificada de materias primas que posteriormente será fundida. De forma general, este tipo de composición puede incluir arena silícea, carbonato de sodio, caliza, dolomita, otros correctores minerales y calcín, según la formulación requerida por el producto. Desde un punto de vista de proceso, no basta con conocer el volumen total disponible de cada materia prima: la dosificación debe mantenerse dentro de la formulación establecida y la mezcla debe llegar al proceso de fusión con un nivel suficiente de homogeneidad. Las diferencias de granulometría, densidad y comportamiento de los materiales durante transporte, pesaje y mezcla obligan a controlar la preparación con una lógica distinta de la de un almacén convencional. La composición es una entrada de proceso.

El calcín tiene además una función particular. Al tratarse de vidrio que ya fue fundido anteriormente, su reincorporación permite sustituir una parte de las materias primas vírgenes y reducir la energía necesaria para volver a obtener una masa vítrea, lo que hace que su gestión tenga al mismo tiempo una dimensión de calidad, trazabilidad, producción y eficiencia de recursos.

Una cadena continua

Después de la preparación, la composición alimenta el horno de fusión. En un proceso float, el vidrio se lleva a temperaturas del orden de 1.500 °C antes de continuar hacia el baño de estaño, donde la masa fundida se extiende formando un ribbon continuo, y posteriormente atraviesa el recocido controlado y las etapas de inspección, corte, almacenamiento y expedición. La característica fundamental para mi proyecto era la continuidad de esa cadena: una línea float no funciona con una lógica convencional de arranque al inicio del turno y parada al final de la jornada, sino que está concebida para trabajar de forma continua durante campañas industriales prolongadas.

Eso modifica la forma de diseñar las herramientas que se conectan a su operación. Cuando llegué a COMPO no estaba digitalizando una actividad administrativa aislada, sino trabajando sobre la gestión de información de un taller situado al inicio de una cadena productiva continua. El perímetro general del puesto cubría los diferentes talleres de la fábrica y mi responsabilidad principal se concentró en COMPO. Llegué el 3 de febrero de 2025 y terminé la misión el 31 de julio.

04

Mi responsabilidad como Product Owner

Además de las responsabilidades de AMOA, asumí el papel de Product Owner de la solución. La oferta establecía explícitamente esa responsabilidad junto con el desarrollo, la planificación y la puesta en marcha de un reporting regular.

Para mí, Product Ownership significó asumir responsabilidad sobre el perímetro funcional: tenía que determinar qué debía resolver la herramienta, estructurar sus funcionalidades, establecer prioridades, coordinar necesidades procedentes de diferentes interlocutores y mantener una visión suficientemente global para evitar que la aplicación se convirtiera en una acumulación de pantallas independientes.

Decidir qué no desarrollar

A medida que un usuario empieza a ver una solución funcionando aparecen nuevas ideas, necesidades y solicitudes. Algunas responden a problemas reales, otras son variantes de algo que ya existe; algunas afectan solamente a un perfil y otras modifican el flujo completo.

Antes de incorporar una función tenía que entender qué problema operacional resolvía, qué usuario la necesitaba, qué información utilizaba y qué consecuencias tenía dentro de las etapas posteriores.

Interlocutores y niveles de comunicación

Mis clientes eran internos: los responsables de los talleres de la fábrica. En el trabajo cotidiano colaboraba principalmente con expertos técnicos, operarios, responsables de producción y el departamento de informática, y determinados temas requerían además intercambios con expertos centrales del grupo y con desarrolladores offshore.

Ese entorno me obligó a adaptar constantemente el nivel de comunicación. Un operario podía necesitar discutir la secuencia exacta de acciones dentro de una operación; con informática era necesario hablar de comportamiento funcional, acceso a datos o gestión de usuarios; con un responsable de proyecto la conversación se desplazaba hacia planificación, dependencias, riesgos, estado de avance y decisiones pendientes. El sistema era el mismo. La información necesaria para trabajar sobre él no lo era.

Heredar trabajo existente

Un becario anterior había dejado un diseño preliminar de la ventana de pesaje. Antes de modificarlo tuve que reconstruir su lógica, comprender qué necesidad intentaba resolver, identificar qué elementos podían conservarse y determinar qué partes ya no correspondían a los requisitos que estaba recopilando.

Fue una situación especialmente formativa porque se parecía mucho más a un proyecto industrial real que a un desarrollo académico desde cero. En un entorno profesional los sistemas tienen historia: existen decisiones anteriores, restricciones, elementos heredados y funcionalidades que nadie quiere romper. Antes de cambiar una parte del sistema hay que entender por qué está allí.

05

Del diagnóstico al desarrollo

Uno de los libros de Excel que sostenían la logística del taller antes del proyecto
Uno de los tres libros de Excel que sostenían la logística del taller. Actualizado a mano una vez al día; cada color es una convención que solo conocía quien lo mantenía.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

Las cinco primeras semanas fueron principalmente de diagnóstico. Analicé documentos históricos, observé directamente las operaciones en el taller y realicé entrevistas semiestructuradas con operarios, responsables y miembros del departamento de informática. Mi objetivo era reconstruir el proceso real: no me interesaba únicamente saber cómo debía funcionar según un procedimiento, sino ver cómo se ejecutaba, qué excepciones aparecían, qué información consultaban los usuarios y qué decisiones tomaban cuando la situación no seguía el recorrido nominal. Lo que encontré fue una gestión logística apoyada en tres libros de Excel independientes, actualizados manualmente una vez al día.

El problema no era Excel como tecnología. El problema era la fragmentación de la información: cada archivo contenía una parte del estado del proceso, y para obtener una visión transversal era necesario consolidar diferentes fuentes y comprobar manualmente que estuvieran actualizadas. Esto afectaba especialmente a la trazabilidad, porque la información existía pero no estaba estructurada alrededor de una secuencia digital única que permitiera representar de forma coherente el recorrido completo del material, y complicaba la preparación de información para auditorías internas y externas. A partir de ese diagnóstico empecé a formalizar el flujo: qué dato nacía en cada etapa, quién lo generaba, quién podía modificarlo, quién debía validarlo, qué información tenía que mantenerse después, qué evento permitía pasar a la etapa siguiente, qué ocurría cuando faltaba información, qué perfil podía continuar el flujo y qué necesitaba ver cada usuario para trabajar sin introducir pasos que no aportaran nada a su operación. Ese análisis terminó convirtiéndose en la base funcional de la aplicación.

De un flujo físico a un modelo digital

Diagrama del proceso manual inicial del departamento COMPO
El proceso manual tal como lo reconstruí durante el diagnóstico, de la visualización de stock a la salida de fábrica. Este diagrama fue el punto de partida del modelo funcional.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

Una de las partes más importantes fue convertir el recorrido físico del material en estados comprensibles para un sistema. En el taller, un material llega, se registra, se pesa, se controla, se almacena, cambia de ubicación y posteriormente continúa hacia otra etapa; para digitalizarlo no era suficiente crear un formulario para cada operación, porque la aplicación tenía que saber en qué estado se encontraba el proceso, qué información ya había sido registrada, qué acciones seguían autorizadas y qué perfil podía realizarlas.

Cada transición tenía que tener una lógica. Una pantalla de registro no podía considerarse terminada solamente porque almacenara datos: había que definir qué ocurría después de guardarlos, qué nuevo estado se generaba, qué usuario debía ver la operación, qué campos podían seguir modificándose, qué acciones quedaban bloqueadas, qué relación existía con la siguiente etapa y qué información debía conservarse como evidencia del recorrido realizado. Esa lógica permitió que el sistema se acercara al proceso físico en lugar de convertirse en una colección de formularios digitales.

La dimensión AMOA

La función de AMOA fue especialmente importante porque mi posición estaba situada entre la necesidad industrial y la solución informática. No era únicamente usuario del sistema y tampoco únicamente desarrollador: tenía que comprender una necesidad métier, formalizarla, comprobar su coherencia, traducirla a requisitos funcionales y posteriormente verificar que la solución respondiera realmente a esa necesidad.

Esto también significaba cuestionar algunas solicitudes. Un usuario puede pedir una función concreta porque conoce el problema desde su experiencia diaria, pero la solución propuesta no siempre es la única ni necesariamente la mejor, y antes de desarrollar tenía que separar la necesidad de la solución imaginada: qué problema intentamos resolver, quién lo encuentra, cuándo aparece, qué información falta, qué decisión no puede tomarse y qué operación debería simplificarse. Responder a esas preguntas evitaba añadir funcionalidades sin comprender antes su función dentro del proceso.

Desarrollo iterativo con FDD

El desarrollo se organizó durante las 25 semanas con una metodología ágil FDD, Feature Driven Development, avanzando por funcionalidades que podían revisarse y validarse progresivamente con los usuarios. Esto era especialmente importante porque una especificación escrita no reproduce completamente la realidad de una planta: una pantalla puede parecer perfectamente lógica durante una reunión y mostrar problemas inmediatamente cuando un operador intenta utilizarla durante una operación real. Por eso la validación no se limitó a un entorno aislado y la herramienta se contrastó con el taller funcionando.

Cada iteración permitía comparar el comportamiento previsto con el uso real. En algunos casos el cambio era técnico; en otros, el problema era de secuencia, terminología, visibilidad o ergonomía: un campo colocado en un orden poco natural, una información demasiado alejada de la acción principal, un estado que no cambia cuando el usuario espera, una función que obliga a repetir información o una etiqueta que utiliza lenguaje de sistema en lugar del término empleado por el taller. En un entorno industrial, estos detalles determinan si una herramienta acompaña el proceso o lo entorpece.

World Class Manufacturing como marco

El proyecto también debía integrarse en la manera en que Saint-Gobain estructura su mejora continua. La planta trabaja con World Class Manufacturing, con sus métodos de análisis, reducción de pérdidas, estandarización y seguimiento del desempeño.

Para mí, esto implicaba una restricción de diseño importante: la herramienta no podía crear una lógica de gestión paralela a la utilizada por la planta, sino integrarse en una organización que ya disponía de reglas, responsabilidades, indicadores, procedimientos y mecanismos de decisión. Una solución puede ser técnicamente correcta y aun así resultar inadecuada si obliga a las personas a trabajar fuera del sistema de gestión existente, y por eso intenté que la digitalización apoyara el proceso industrial en lugar de competir con él.

06

La solución implementada

Ventana del puesto de guardia en Ignition SCADA: registro de pesaje de camiones
El puesto de guardia, primera etapa del recorrido. Simple o doble pesada, entidad, transportista, naturaleza del material y destino. El peso no se teclea: lo lee el autómata de la báscula.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

La solución digitalizó el recorrido del material sobre una plataforma Ignition SCADA, con un alcance que cubría orden de reaprovisionamiento, entrada del camión, pesaje, análisis de calidad del calcín, almacenamiento en silo, envío a producción y expedición.

La plataforma SCADA era adecuada para este contexto porque permitía reunir en un mismo entorno visualización, lógica de aplicación, interacción con datos, autenticación y control de acceso. Mi objetivo no era construir una aplicación administrativa independiente de la planta: la herramienta tenía que formar parte del entorno operativo del taller.

Una interfaz distinta según el usuario

Los seis perfiles de usuario del sistema y su jerarquía
Los seis perfiles. Cada uno recibe únicamente las ventanas y las acciones que corresponden a su responsabilidad dentro del proceso.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

Las ventanas se filtraron según el rol del usuario, y esto respondía a una necesidad funcional clara: un operario no necesita las mismas acciones que un responsable, un perfil encargado de una etapa concreta no tiene por qué recibir controles correspondientes a otra responsabilidad, y determinadas acciones no deben estar disponibles para todos los usuarios.

La gestión de perfiles permitía adaptar la interfaz al trabajo que cada persona debía realizar, lo que reducía información irrelevante y ayudaba a mantener una separación clara entre consulta, operación, validación y administración. En total, el sistema contemplaba seis perfiles. No diseñé por tanto una única pantalla genérica para todo el taller: la aplicación debía presentar a cada usuario la parte del proceso sobre la que realmente tenía responsabilidad.

Estructurar la información

Los dominios funcionales propuestos para la base de datos
La propuesta inicial de dominios: usuarios, materiales, transportistas, cálculos, datos de PLC y departamentos.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.
Diseño final de la base de datos del departamento COMPO
El diseño final, ya con las relaciones entre entidades resueltas y documentado tabla por tabla.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

Detrás de las ventanas había un problema más importante: cómo representar los datos del proceso. El sistema estaba organizado alrededor de ocho dominios de base de datos, y esa decisión era necesaria porque digitalizar un proceso no consiste en trasladar columnas de Excel a una tabla más grande. Había que conservar relaciones entre las entidades que participaban en el flujo: una operación podía depender de un material, un vehículo, una medición, una validación, un silo, un estado o una etapa previa, y cada elemento tenía que poder relacionarse con el resto sin perder su identidad ni su historial.

La base de datos tenía que servir simultáneamente para dos objetivos. El primero era operativo: saber qué estaba ocurriendo en ese momento. El segundo era histórico: poder reconstruir después qué había ocurrido. Esta segunda dimensión era especialmente importante para trazabilidad y auditoría, porque una aplicación que muestra correctamente el presente pero no permite reconstruir el pasado tiene un valor limitado en un proceso industrial.

De archivos a estados

Uno de los cambios conceptuales más importantes fue pasar de una organización centrada en archivos a una organización centrada en el proceso. En los tres libros de Excel, cada documento contenía una parte de la información; en la solución digital, las distintas operaciones podían pertenecer al mismo recorrido lógico: la llegada del camión, el registro, el pesaje, el control, la validación, el almacenamiento, el envío a producción y la expedición. Cada etapa dejaba de ser un documento aislado para convertirse en un estado dentro de una secuencia.

Para mí, esa diferencia resume bien la distancia entre informatizar y digitalizar. Informatizar puede significar reproducir en una pantalla exactamente lo que antes se escribía en una hoja; digitalizar exige preguntarse cómo circula la información, qué evento modifica el estado del proceso y qué necesita conocer cada actor para continuar.

Alarmas y excepciones

El sistema incluía también lógica de alarmas, lo que obligaba a considerar algo que muchas veces aparece tarde durante el desarrollo: el flujo nominal representa solamente una parte del proceso real. La secuencia ideal puede parecer sencilla, el material llega, se registra, se pesa, se controla, se almacena y continúa hacia producción o expedición, pero la operación real incluye excepciones: información incompleta, resultados pendientes, validaciones que dependen de otro perfil, operaciones que no pueden continuar, datos que necesitan corrección o situaciones que deben quedar visibles antes de que otro usuario tome una decisión.

Diseñar estas desviaciones era tan importante como diseñar el recorrido normal. Cuando todo ocurre correctamente, casi cualquier interfaz parece suficiente; la calidad de una herramienta industrial se vuelve mucho más visible cuando algo no ocurre como estaba previsto.

Arquitectura OT/IT

Configuración del puerto serie del convertidor serie-Ethernet
La configuración del convertidor serie-Ethernet que saca la señal de la báscula de la red de campo. Es el punto exacto donde el mundo OT se convierte en un dato que IT puede leer.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

El proyecto también me permitió trabajar sobre la relación entre el entorno operacional y el entorno informático. La aplicación se situaba en una cadena OT/IT en la que la operación física, la interfaz SCADA, la lógica de aplicación y la persistencia de información tenían que mantenerse coherentes, lo que exige pensar el sistema por capas: la interfaz representa una operación, la lógica decide qué acciones están permitidas, los datos conservan el estado y el historial, y el usuario interpreta esa información y actúa sobre el proceso.

Si una de esas capas no corresponde a las demás, aparecen inconsistencias. Una pantalla puede mostrar un estado que la base de datos no refleja correctamente; una regla puede permitir una acción que el procedimiento no autoriza; un perfil puede recibir una función que no corresponde a su responsabilidad; una operación puede ejecutarse correctamente pero no dejar la trazabilidad necesaria. Por eso el trabajo no podía reducirse al diseño visual de ventanas: la coherencia tenía que mantenerse desde la operación hasta la información almacenada.

Documentación y transferencia

Carta de aprobación del manual de distribución de base de datos
Una de las dos cartas de aprobación. El manual fue revisado y validado formalmente por el jefe de línea y por el responsable WCM 4.0 antes de convertirse en referencia técnica oficial del departamento.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.
Portada del manual de sistemas y procedimientos e índice de procedimientos
El manual de sistemas y procedimientos, y su índice. Veintiséis procedimientos ilustrados, uno por operación.Imagen tratada por confidencialidad del proyecto: los datos operativos han sido difuminados o retirados de forma deliberada.

La entrega no terminó con la última funcionalidad. Preparé 26 procedimientos ilustrados, formé al personal del departamento y elaboré dos manuales técnicos que fueron revisados, aprobados y firmados por el jefe de línea y por el referente WCM/4.0 de la planta. Considero esta parte tan importante como el desarrollo, porque una aplicación industrial no puede depender permanentemente de la persona que la construyó: al terminar mi misión, los usuarios tenían que poder ejecutar sus operaciones sin necesitarme, el equipo técnico disponer de información suficiente para comprender la herramienta y la organización conservar procedimientos formales que explicaran cómo utilizarla.

Por eso la documentación no fue un entregable añadido al final. Formó parte de la solución. El código define el comportamiento del sistema, el procedimiento describe cómo debe utilizarlo el usuario, el manual permite comprender su estructura y la formación transfiere el conocimiento necesario para que el sistema continúe funcionando. Necesitaba las cuatro cosas.

07

Seguimiento y comités de pilotaje

Parte de mi responsabilidad era preparar y participar en reuniones de seguimiento y comités de pilotaje, y este trabajo modificó bastante mi forma de presentar decisiones técnicas. Durante el desarrollo puedo dedicar tiempo a estudiar una estructura de datos, una lógica de estados, un comportamiento de interfaz o una dependencia; en un comité la conversación cambia y se concentra en dónde estamos, qué está terminado, qué falta, qué impide avanzar, qué decisión necesitamos, qué riesgo existe, qué impacto tendría modificar el alcance y cuándo puede validarse una funcionalidad.

Eso me obligó a distinguir el detalle técnico del detalle útil para decidir. No significa eliminar la ingeniería de la conversación, sino saber qué parte de la ingeniería necesita cada interlocutor: si tenía que presentar una decisión de arquitectura, debía poder explicar qué problema resolvía, qué dependencia introducía, qué ocurría si fallaba y qué consecuencias tendría cambiarla.

Documentar el razonamiento

Aprendí también a documentar mejor el razonamiento detrás de una decisión. En un proyecto industrial participan personas diferentes en momentos diferentes, y una decisión que hoy parece evidente puede necesitar ser explicada meses después a alguien que no estuvo presente cuando se tomó. Ser capaz de reconstruir el porqué es parte de la mantenibilidad del sistema.

Los comités también me enseñaron a cambiar de escala. Puedo entrar en el detalle de una regla funcional y, unos minutos después, volver a una visión de conjunto para explicar cómo esa regla afecta la planificación o la operación. Esa capacidad de pasar de arquitectura a proceso y de proceso a decisión se convirtió posteriormente en una parte importante de mi manera de trabajar.

08

Cómo me evaluaron

Certificación Ignition SCADA nivel Gold de Inductive Automation
La certificación Gold de Inductive Automation, obtenida el 14 de febrero de 2025: once días después de empezar la misión. Certificarme sobre la plataforma antes de construir nada sobre ella formaba parte del encargo.

El jefe de línea que fue mi tutor externo evaluó mi desempeño con un 8,5 sobre 9, dentro de la categoría «excelente», con 9 sobre 9 en adaptación a las normas de la empresa y 9 sobre 9 en aptitud técnica. Posteriormente, el jurado de la UNET evaluó el TAP con 9 sobre 9 en diciembre de 2025.

La puntuación más baja correspondió a comunicación oral y escrita. Es una evaluación que entiendo dentro del contexto en el que comenzó la experiencia.

Construir el idioma mientras se construye el sistema

Cuando llegué a Francia todavía estaba desarrollando mi nivel profesional de francés y una parte importante de esta misión ocurrió al mismo tiempo que construía ese idioma en un entorno industrial. No se trataba solamente de mantener conversaciones cotidianas: tenía que entrevistar usuarios, comprender vocabulario técnico, participar en reuniones, interpretar procedimientos, preparar documentación, explicar funcionalidades, formar personal, presentar avances y finalmente defender el proyecto. En los agradecimientos del SFE mencioné precisamente al personal de COMPO y del departamento de informática por su paciencia con mi nivel de francés y por haber facilitado mi integración dentro del equipo.

Por eso considero esta parte de la evaluación especialmente útil: permite medir también la distancia entre el momento en que llegué y el nivel de autonomía que pude alcanzar durante la misión. Llegué trabajando principalmente desde el español y hoy trabajo a diario en francés y me manejo en cinco idiomas dentro de Saint-Gobain. Más que una anécdota lingüística, para mí representa la capacidad de incorporarme a un entorno técnico nuevo, aprender su lenguaje y terminar trabajando dentro de él con autonomía.

09

Lo que cambió mi forma de trabajar

Esta experiencia cambió principalmente mi forma de entender la digitalización industrial. Antes podía observar una herramienta sobre todo desde su arquitectura y sus funcionalidades; después de trabajar en Chantereine empecé a verla como un sistema socio técnico, en el que proceso, personas, datos, interfaces, reglas, responsabilidades, documentación y organización forman parte de la misma solución.

Si uno de esos elementos se diseña ignorando a los demás, aparecen problemas. Una aplicación puede tener una interfaz correcta y un modelo de datos deficiente; puede tener una arquitectura sólida y no corresponder al flujo real; puede registrar toda la información necesaria y exigir demasiado esfuerzo al usuario; puede funcionar técnicamente y no disponer de documentación suficiente para sobrevivir al cambio de equipo; puede incluso automatizar correctamente un proceso que primero necesitaba ser cuestionado. Por eso ahora intento comenzar los proyectos entendiendo primero el sistema completo.

La adopción no se diseña desde una presentación

También cambió mi forma de interpretar la resistencia al cambio. No parto de la idea de que un usuario rechaza una herramienta porque no quiere cambiar: puede rechazarla porque añade pasos, porque obliga a introducir dos veces un dato, porque utiliza una terminología que nadie emplea en el taller, porque una excepción frecuente no fue contemplada, porque la información aparece demasiado tarde, porque no confía todavía en el estado que muestra la pantalla, o porque otra herramienta implantada anteriormente prometió simplificar su trabajo y terminó complicándolo.

Por eso considero la observación directa y la validación con usuarios parte de la ingeniería. La confianza en una herramienta industrial se construye cuando su comportamiento coincide repetidamente con la realidad que el usuario conoce. No se obtiene porque una presentación explique bien el proyecto: se obtiene cuando la herramienta responde correctamente durante el trabajo real.

Documentar también es ingeniería

Otra conclusión importante fue dejar de considerar la documentación como una actividad posterior al desarrollo. Un procedimiento aprobado establece cómo debe ejecutarse una operación, un manual técnico conserva conocimiento sobre el sistema y una formación permite transferirlo. El código por sí solo no garantiza ninguna de esas cosas.

Si una herramienta desaparece con la persona que la desarrolló, el problema no está únicamente en la documentación: también existe un problema de diseño organizacional. Por eso intento que los proyectos que construyo puedan ser entendidos, utilizados y mantenidos por personas que no participaron en su creación.

Proceso e ingeniería

La doble defensa académica terminó reforzando esta manera de pensar. En Arts et Métiers tuve que explicar cómo diagnosticaba y transformaba un proceso; en la UNET tuve que explicar cómo estaba construido el sistema y qué permitían demostrar sus resultados. Ambas perspectivas eran necesarias.

Hoy intento mantener esa separación en mis proyectos: primero comprender qué ocurre físicamente, después modelar el proceso, a continuación transformar ese modelo en datos, estados, reglas, permisos e interfaces, volver al terreno y comprobar si la representación digital sigue correspondiendo a la realidad, documentar las decisiones y finalmente ser capaz de explicar el mismo sistema con el nivel de detalle adecuado para un operario, un responsable industrial, un equipo informático, un comité de pilotaje o un jurado técnico. Eso es lo que terminó siendo mi trabajo en Chantereine: no únicamente desarrollar una aplicación SCADA, sino entender un proceso industrial, formalizarlo, convertirlo en un sistema digital y preparar ese sistema para seguir funcionando después de mi salida.

Resultados e impacto

Resultado

Sistema desplegado en el taller

El recorrido del material, del reaprovisionamiento a la expedición, quedó en una sola secuencia digital sobre Ignition en lugar de tres libros de Excel.

26 procedimientos y 2 manuales

Los manuales fueron revisados, aprobados y firmados por el jefe de línea y el referente WCM/4.0; los usuarios ejecutaban sus operaciones sin necesitarme.

Evaluación 8,5 / 9 y TAP 9 / 9

El jefe de línea calificó el desempeño como «excelente», con 9 / 9 en aptitud técnica; el jurado de la UNET evaluó el TAP con 9 / 9 en diciembre de 2025.

Dos memorias defendidas

El SFE ante Arts et Métiers, 69 páginas y veintitrés anexos de procedimientos, y el TAP ante la UNET, centrado en la ingeniería del sistema.

Stack

Ignition SCADASQLOT/ITWCMDigitalización de procesos

Competencias del puesto

Herramientas

IgnitionSiemensOPC UAModbusMySQLSQLPythonPower BI

Dominio

SCADAProgramación de HMIProgramación de autómatasAutomatización industrialIIoTMESInstrumentación y electricidad

Marcos y métodos

WCMLean manufacturingISO 9001Industria 4.0Fabricación inteligenteDigitalización industrialIngeniería industrialOptimización de procesosProduct Owner