Del Excel al ERP propio: cómo transformamos la gestión de un taller de ensamblaje de componentes ferroviarios

El problema: un negocio industrial gestionado con Excel

Un taller de ensamblaje de componentes para el sector ferroviario nos llegó con un problema que al principio suena simple: "el Excel ya no nos da más de sí".

Al profundizar, el panorama era más complejo. El taller gestionaba simultáneamente decenas de órdenes de trabajo, cada una con sus propias piezas, especificaciones técnicas, plazos y estado de producción. Todo eso vivía en un Excel compartido que nadie se atrevía a modificar sin hacer una copia primero por miedo a romper algo.

Los problemas concretos que documentamos en la primera reunión:

• Sin visibilidad en tiempo real del estado de cada orden de trabajo. Había que preguntar al operario o mirar el Excel.
• El stock de componentes se desactualizaba constantemente. Se paraban líneas de producción por falta de piezas que "según el Excel" estaban disponibles.
• Los informes de estado para el cliente (la empresa ferroviaria) se hacían manualmente, copiando datos del Excel a Word. Tardaban entre 2 y 3 horas cada uno.
• No había trazabilidad. Si había un defecto en un componente, era imposible saber en qué orden de trabajo había entrado y qué operario lo había procesado.

Por qué descartamos los ERPs del mercado

Lo primero que hicimos fue analizar si había algún ERP del mercado que encajara. Evaluamos SAP Business One, Odoo, Sage y un ERP específico para manufactura. Todos fallaban en el mismo punto:

El proceso de este taller es muy específico del sector ferroviario. Las especificaciones técnicas de cada componente, los requisitos de trazabilidad de la industria ferroviaria y la forma en que se organizan las órdenes de trabajo no encajan en ninguna plantilla genérica sin una personalización que habría costado más que construirlo desde cero.

Además, Odoo (la opción de código abierto que suele parecer más flexible) requería una curva de aprendizaje enorme para el equipo y actualizaciones constantes que nadie iba a gestionar. Lo descartamos.

La decisión fue construir un ERP propio, ligero, con exactamente las funcionalidades que necesitaban y sin todo lo que no usarían nunca. Lo describimos en detalle en nuestro artículo software a medida vs ERP genérico: cómo decidir.

La solución: arquitectura y decisiones técnicas

Por qué FastAPI y no Django

Elegimos FastAPI sobre Django por una razón concreta: el cliente necesitaba endpoints ligeros y rápidos para que los operarios en planta pudieran actualizar el estado de las órdenes desde tablets en tiempo real. Django habría funcionado, pero FastAPI nos dio mejor rendimiento con menos configuración para esta arquitectura específica.

Por qué React para el frontend

El panel de control tiene dos perfiles de usuario muy distintos: el jefe de planta (que necesita ver dashboards de estado) y los operarios (que necesitan una interfaz simple para actualizar avances). React nos permitió construir vistas completamente distintas para cada rol sin duplicar la lógica de negocio.

PostgreSQL para la trazabilidad

La trazabilidad era un requisito no negociable del sector ferroviario. Cada operación sobre cada componente queda registrada con timestamp, usuario y estado anterior. PostgreSQL con su soporte nativo para JSON y su fiabilidad en transacciones era la elección obvia.

El proceso de desarrollo: 8 semanas

• Semanas 1-2 — Análisis y diseño: Pasamos tiempo en el taller observando el flujo real de trabajo. No en reuniones, en el suelo de producción. Mapeamos cada proceso, cada excepción, cada caso raro que el Excel gestionaba con color de celda o con una nota al margen.
• Semana 3 — Arquitectura y base de datos: Diseñamos el modelo de datos. Esta semana es la más crítica — un error en el modelo de datos en semanas posteriores cuesta el doble de corregir.
• Semanas 4-6 — Desarrollo del núcleo: Órdenes de trabajo, gestión de stock, sistema de roles y permisos. Sin UI todavía — primero la lógica.
• Semana 7 — Frontend y panel de control: La interfaz para jefe de planta y operarios. Diseño funcional, no bonito — en un taller, la usabilidad con guantes importa más que la estética.
• Semana 8 — Pruebas en paralelo y formación: El sistema funcionó en paralelo con el Excel durante una semana. Los operarios usaron ambos. Identificamos 4 casos que no habíamos contemplado y los resolvimos antes del apagado definitivo del Excel.

Resultados a los 6 meses

Seis meses después del lanzamiento, el equipo ha olvidado que el Excel existió. Resultados concretos:

• El tiempo de gestión de cada orden de trabajo se redujo un 80%. Lo que antes llevaba 20 minutos entre buscar en el Excel, actualizar y comunicar, ahora son 2-3 minutos en el sistema.
• Cero paradas de línea por error de stock en 6 meses. Antes había entre 1 y 2 al mes.
• Los informes de estado para el cliente ferroviario se generan automáticamente en menos de 10 segundos. Antes tardaban 2-3 horas.
• Trazabilidad completa: cualquier componente puede seguirse desde su entrada en el almacén hasta su salida como parte de un conjunto ensamblado.

Lo que aprendimos

La lección más importante de este proyecto: el análisis inicial vale más que las semanas de desarrollo. Las 2 primeras semanas en el taller, entendiendo los procesos reales, nos ahorraron probablemente 4 semanas de retrabajos.

También aprendimos que la formación no es un afterthought. Los operarios que más resistencia mostraron al principio fueron los que más rápido adoptaron el sistema cuando vieron que les simplificaba el trabajo. La clave fue involucrarles en las pruebas desde el principio, no imponerles el sistema terminado.