Mi Primer Año en Portugal: Cómo Construí un Sistema de Producción Industrial Desde Cero
En 2023 llegué a Viseu, Portugal, para trabajar en SYSteel Group. En 12 meses: aprendí el proceso industrial, construí SYSControl (monitoreo de producción en tiempo real), y entendí lo que significa la transformación digital cuando tienes que convencer a un operario de que use tu app.
Nota del autor (mayo 2026): Escribí esto en diciembre de 2023, al cumplir un año en Viseu. Es el resumen de un año de aprendizaje en contexto industrial real. La lección más importante que aprendí no fue técnica.
Mi Primer Año en Portugal: Cómo Construí un Sistema de Producción Industrial Desde Cero
Semana 1: la realidad de la planta
Llegué a la planta de SYSteel Group en Viseu con el mismo instinto con el que cualquier desarrollador llega a un proyecto nuevo: querer entender el sistema, mapear los componentes, identificar los puntos de mejora.
Pero antes de entender el sistema, tuve que entender la planta.
Lo que vi en la primera semana fue una ingeniería de precisión extraordinaria en el corte de acero: máquinas de plasma que cortan a milímetros de tolerancia, plegadoras que dan forma a estructuras metálicas con exactitud milimétrica, procesos de granallado y tratamiento superficial que requieren un control técnico real.
Y junto a esa precisión técnica: órdenes de producción en papel. Notas manuscritas que viajaban de la oficina al taller. Excel con estados de pedidos actualizados a mano. Operarios que tenían que caminar a la oficina para preguntar cuál era la siguiente prioridad.
La distancia entre la precisión del metal y la gestión de la información era el problema que vine a resolver.
Escuchar antes de construir
El error más costoso en transformación digital es construir antes de escuchar. Lo he visto en proyectos ajenos y lo viví en carne propia en mis primeros intentos con TALS — cuando construía features que nadie en la comunidad sorda había pedido.
En SYSteel, decidí hacer lo contrario.
Me puse el casco y los zapatos de seguridad. Me quedé en el taller. Pregunté a los operarios de las máquinas de plasma la misma pregunta con distintas formulaciones: "¿Qué es lo que más te quita tiempo en el día?", "¿En qué momento del trabajo te sientes más bloqueado?", "¿Qué información necesitas que ahora mismo no tienes fácil?"
La respuesta fue consistente en todos: "No sé qué pieza sigue ni dónde está el resto del pedido."
No me decían que el sistema era lento, ni que la interfaz era complicada. Me decían que la información que necesitaban para hacer bien su trabajo simplemente no llegaba a donde ellos estaban. El problema no era técnico — era de flujo de información.
Esa comprensión redefinió completamente el diseño de SYSControl: no como una herramienta de control gerencial, sino como un asistente para el hombre que está frente a la máquina. La diferencia es sutil pero fundamental para la adopción.
Las decisiones técnicas y por qué se tomaron así
Node.js fue la elección para el backend. Familiar para mí, suficientemente performante para las necesidades del proyecto, y con un ecosistema maduro de librerías para el tipo de operaciones que necesitábamos.
La decisión crítica fue Socket.io para las actualizaciones en tiempo real. En una planta industrial, un retraso de cinco segundos en la pantalla del operario no es una inconveniencia — es una operación de máquina que se ejecuta sobre información desactualizada. Si la oficina cambia la prioridad de un pedido, la pantalla del taller tiene que reflejarlo en el instante, no en el próximo refresh.
Diseñé SYSControl como un sistema nervioso digital para la fábrica: cada cambio de estado en la oficina se propaga instantáneamente a todos los puntos de la planta que necesitan saberlo.
SQLite para la base de datos en la primera versión, deliberadamente. PostgreSQL habría sido más escalable, pero la prioridad era velocidad de despliegue y simplicidad de mantenimiento en un entorno donde no había un DBA. Construir la versión más simple que resuelve el problema es siempre mejor que construir la versión más elegante que llega tarde.
El primer prototipo y la primera reacción real
Instalé la primera tablet junto a una máquina de plasma. Era una interface limpia: el nombre de la pieza actual, el estado del pedido completo, el botón para marcar la pieza como terminada.
El primer comentario del operario fue inmediato y completamente inesperado: "Los botones son muy pequeños para mis dedos con guantes."
Llevaba semanas diseñando la interfaz pensando en usabilidad estándar de software empresarial. No había pensado en que los usuarios la utilizarían con guantes de trabajo de cuero grueso, en un ambiente con polvo metálico, con los dedos menos sensibles por el frío del invierno portugués.
Fue la lección de UX industrial más directa que podría haber recibido.
Rediseñé toda la interfaz con una premisa nueva: cada elemento táctil debe ser operable con guantes, los contrastes deben ser visibles bajo la iluminación mixta (luz de naves + focos de máquinas), y no puede haber texto pequeño ni elementos que requieran precisión en el toque.
Los problemas técnicos que no están en Stack Overflow
El ambiente de SYSteel tiene características que ningún tutorial de desarrollo web contempla.
La red WiFi industrial. Las interferencias electromagnéticas de las máquinas de corte plasma y las estructuras metálicas de la nave degradan la señal WiFi de manera impredecible. Implementé lógica de reconexión automática y almacenamiento local (offline-first) para que si la tablet pierde conexión, continúa funcionando con los datos locales y sincroniza cuando la red vuelve. El operario nunca ve una pantalla en blanco.
Hardware legado. Algunos equipos de oficina corrían versiones antiguas de Windows sin actualizar. El sistema tuvo que ser compatible desde el inicio con navegadores desactualizados, sin asumir ES6 ni APIs modernas en todos los clientes.
El primer crash en producción. Llegó a los tres meses, un lunes por la mañana. Un edge case en la lógica de sincronización que no había aparecido en pruebas. Lo resolví en quince minutos, antes de que el turno de la tarde empezara, sin que afectara operaciones críticas. La gestión de ese incidente — diagnóstico rápido, fix sin pánico, comunicación transparente con el equipo de dirección — fue tan importante como el código en sí.
La adopción: el problema más difícil
La resistencia inicial de los operarios no fue indiferencia — fue desconfianza activa.
"Vienes a vigilarnos." "Esto es para que el jefe sepa exactamente cuánto tardamos en cada pieza." "Ahora van a saber si nos tomamos cinco minutos de descanso."
Esas preocupaciones eran legítimas. La tecnología de monitoreo en industria tiene una historia larga de ser usada como instrumento de control laboral, no como herramienta de ayuda. Si no abordas eso de frente, la adopción no llega.
Cambié el enfoque completamente. En lugar de presentar SYSControl como un sistema de gestión de producción, lo presenté como: "Vengo a evitar que camines diez veces al día a la oficina a preguntar qué hacer."
Ese framing funcionó porque era verdad. La incomodidad más grande que los operarios expresaban no era el trabajo en sí — era la interrupción constante de tener que buscar información que debería estar disponible donde estaban.
Cuando vieron que la app les ahorraba pasos físicos y les daba autonomía para saber exactamente qué tocaba hacer sin preguntar, la actitud cambió. Los operarios que más resistían se convirtieron en los más activos en señalar bugs y sugerir mejoras. La transformación digital no se impone — se vende como una mejora de vida cotidiana.
Los números al año 1
Al cerrar el primer año de SYSControl en producción, los resultados eran concretos:
- 90% de reducción del papel en el área de corte: las órdenes de producción se gestionan completamente en el sistema
- Comunicación oficina-taller en tiempo real: lo que antes tardaba horas (una persona caminando o llamando) pasó a ser instantáneo
- Reducción estimada del 15% en tiempos muertos de máquinas, por tener la información de la pieza siguiente lista antes de terminar la actual
- Cero interrupciones por falta de información en el turno de tarde, que antes dependía de notas del turno de mañana
Pero el número que más me importaba no era ninguno de esos.
Era ver a un operario veterano — alguien que llevaba 20 años en la planta y nunca había tocado una tablet — deslizar el dedo para marcar una pieza como terminada y sonreír porque "ahora todo es más claro". Ese operario se convirtió en el mayor defensor de SYSControl dentro del taller.
Eso es mi verdadero KPI.
Lo que aprendí que no está en ningún curso de desarrollo web
Los cursos de desarrollo web enseñan JavaScript, frameworks, patrones de arquitectura, buenas prácticas de código. Lo que no enseñan:
El proceso antes del código. El 50% del tiempo de un proyecto de transformación digital exitosa se pasa entendiendo el proceso que vas a digitalizar. Si no entiendes el proceso humano y físico, el código solo digitalizará el caos.
La política interna de una empresa industrial. Quién tiene realmente la autoridad sobre qué, qué tensiones existen entre departamentos, por qué ciertas decisiones se toman de cierta manera aunque parezcan irracionales desde afuera. Entender eso antes de proponer cambios evita implementaciones técnicamente perfectas que mueren por resistencia organizacional.
Cómo vender un cambio a quien preferiría que todo siguiera igual. La habilidad más subestimada en transformación digital no es técnica — es la persuasión empática. Entender el miedo genuino que hay detrás de la resistencia y responder a ese miedo específico, no al miedo genérico "al cambio".
Soy un desarrollador que escribe JavaScript. Pero antes de escribir la primera línea de código, soy un ingeniero de campo que se pone el casco y aprende el proceso que va a digitalizar.
Ese orden importa.