Del pliego de requisitos a la especificación del sistema
Desde el cumplimiento de las TSI y las evidencias CENELEC hasta la coordinación de proveedores: las cinco fases del trabajo con el pliego de requisitos, ReqIF en la práctica, los cuellos de botella habituales y dónde la digitalización marca la mayor diferencia.
Introducción
Quien presenta una oferta en la industria ferroviaria europea debe traducir un pliego de requisitos en una especificación del sistema. Parece un trabajo documental. En la práctica, decenas de expertos coordinan miles de requisitos individuales con cientos de referencias normativas, y muchas empresas todavía lo hacen en Excel y Word.
Según el UNIFE World Rail Market Study 2024, solo el mercado europeo de material rodante tiene un valor de 63.300 millones de euros, con un crecimiento anual del 7,3% en Europa Occidental. Según un estudio del Parlamento Europeo (2023) los cuatro mayores fabricantes europeos concentran más del 70% de cuota de mercado. Para competir en este mercado, las empresas deben poder responder a pliegos de requisitos con rapidez, de forma completa y conforme a las normas. El proceso para lograrlo es el tema de este artículo.
A continuación: por qué la industria ferroviaria es especialmente exigente, las cinco fases del proceso, dónde suele atascarse y qué pueden cambiar las herramientas digitales.
¿Qué es un pliego de requisitos?
Un pliego de requisitos (en inglés: requirements specification o tender specification) describe todos los requisitos que un cliente plantea a un sistema que debe entregarse. En la industria ferroviaria, lo elabora el comprador, es decir, una empresa de transporte o un gestor de infraestructuras, y lo envía a proveedores potenciales.
Según el alcance del proyecto, un pliego de requisitos contiene de cientos a varios miles de requisitos individuales. En la industria ferroviaria, la estructura sigue a menudo las categorías LH (LH1 a LH8), que cubren distintos subsistemas: estructura del vehículo, tecnología de tracción, sistemas de frenado, equipamiento interior, información al pasajero y otros.
Cada requisito contiene normalmente un ID único, el propio texto del requisito, referencias normativas (TSI, DIN EN, ISO) y un nivel de obligatoriedad (debe, debería, puede). La guía VDB de gestión de requisitos recomienda el intercambio electrónico mediante el formato ReqIF (Requirements Interchange Format) para evitar comparaciones manuales entre versiones de documentos.
El calendario tampoco debe subestimarse: según el estudio del Parlamento Europeo, en Alemania suelen transcurrir entre 7 y 8 años desde la convocatoria de competencia hasta la producción en serie, y al menos 6 años desde la firma del contrato. La fase de la especificación del sistema está al comienzo de esta cadena y determina si un proveedor llega siquiera a la lista corta.
Por qué la industria ferroviaria es especialmente exigente
Hay pliegos de requisitos en todos los sectores. Lo que distingue a la industria ferroviaria es la combinación de profundidad regulatoria, diversidad de normas y amplitud de la cadena de suministro.
Complejidad de las TSI
Un vehículo ferroviario debe cumplir simultáneamente varias Especificaciones Técnicas de Interoperabilidad (TSI) de la UE. La ERA define 11 TSI diferentes. Para los vehículos, al menos tres son directamente relevantes: LOC&PAS (locomotoras y material rodante de pasajeros), Noise (emisiones acústicas) y PRM (accesibilidad). Según el tipo de vehículo, se añaden CCS (mando, control y señalización), SRT (seguridad en túneles ferroviarios) y otras.
Cada TSI es un reglamento de la UE y, por tanto, derecho directamente aplicable. Cuando las TSI dejan cuestiones abiertas, también se aplican normas técnicas nacionales (NNTR). En los proyectos transfronterizos, los licitadores deben cumplir al mismo tiempo las TSI y las NNTR de varios países. La conformidad es verificada por un organismo notificado (NoBo) y un organismo designado (DeBo).
CENELEC EN 5012x: RAMS, software, caso de seguridad
Además de las TSI, el mercado exige demostrar la seguridad funcional conforme a las normas CENELEC. Las tres normas centrales son:
- EN 50126 define el ciclo de vida RAMS (Reliability, Availability, Maintainability, Safety) en 12 fases. Los licitadores deben aportar objetivos RAMS, análisis de riesgos (FMEA, FTA) y un caso de seguridad para su sistema.
- EN 50716 ha reunido desde octubre de 2023 las anteriores EN 50128 (tecnología de señalización) y EN 50657 (software de vehículos) en una única norma. Es nueva la regulación explícita para el desarrollo iterativo, los componentes de IA/ML y la ciberseguridad.
- EN 50129 define la estructura del caso de seguridad y las evidencias para la seguridad del hardware. Para la puesta en servicio en la UE, es obligatoria la evaluación por un evaluador de seguridad independiente (ISA).
Todas estas evidencias se incorporan a la especificación del sistema. Un licitador cuya documentación RAMS tenga lagunas será penalizado en la evaluación, con independencia de la calidad técnica de su vehículo.
La cadena de suministro multiplica la complejidad
Ningún OEM fabrica por sí solo un vehículo ferroviario. Según su propia página de proveedores, Alstom trabaja con más de 21.000 proveedores en 83 países. Las compras representan el 60% de los ingresos anuales. Cada uno de estos proveedores recibe un pliego de requisitos parcial para su parte y debe responder con su propia especificación del sistema. Un fabricante de sistemas de frenado recibe los requisitos de freno, un proveedor de HVAC los requisitos de climatización y un fabricante de asientos los de equipamiento interior.
Esto significa que el OEM no solo debe elaborar su propia especificación del sistema, sino también transmitir los requisitos de forma coherente a los proveedores de subsistemas y consolidar sus respuestas. Si el fabricante de frenos clasifica un requisito como OKB y el OEM lo comunica al cliente como OK, surge una incoherencia que se detectará durante la evaluación.
El contrato de 15.000 millones de euros para la S-Bahn de Berlín fue adjudicado a un consorcio de DB, Siemens y Stadler. 1.400 coches nuevos, licitación en curso desde 2020 y adjudicación solo en 2025. Alstom impugnó el procedimiento. Estas estructuras de consorcio muestran cuántas partes pueden participar en el tratamiento de requisitos.
Las 5 fases del proceso
El proceso puede dividirse en cinco fases. En la práctica se solapan y varían según la empresa, pero el patrón básico es similar en la mayoría de los proveedores.
El pliego de requisitos se importa y se descompone en requisitos individuales. Se extraen la estructura, los ID y las referencias normativas. En las revisiones, deben identificarse los cambios respecto de la versión anterior. Lo ideal es que el intercambio se realice en formato ReqIF, que admiten herramientas como IBM DOORS, Siemens Polarion y Eclipse RMF.
Cada requisito se evalúa: OK (cumplible por completo), OKB (cumplible bajo condiciones), NOK (no cumplible), OKM (cumplible con modificación) o R (consulta al comprador). OKB suele ser el caso más difícil, porque la condición debe formularse con precisión, ser medible y aceptable para el cliente.
Los requisitos se asignan a los departamentos especializados responsables: tecnología de tracción, sistemas de frenado, ingeniería eléctrica, RAMS y equipamiento interior. Según el alcance del proyecto, participan entre 10 y 30 equipos de subsistemas. Las asignaciones incorrectas cuestan tiempo y crean lagunas.
Los expertos formulan respuestas conformes a las normas con referencias a las evidencias. Se documentan las condiciones, las propuestas alternativas y las consultas. Cada respuesta debe poder remitir a documentos fuente: informes de ensayo, documentos de homologación, fichas técnicas de fabricante y evidencias RAMS.
Las respuestas individuales se consolidan en la especificación del sistema y se exportan como documento completo y como pliegos de requisitos parciales por subsistema, en el formato exigido por el cliente, con plena trazabilidad desde el requisito hasta la evidencia.
ReqIF en la práctica
El Requirements Interchange Format (ReqIF) es un estándar abierto de OMG (actualmente en la versión 1.2) para el intercambio sin pérdida de datos de requisitos entre distintas herramientas. Fue desarrollado originalmente en 2004 por la Herstellerinitiative Software (HIS) de la industria automovilística alemana, y OMG mantiene ReqIF desde 2011.
En teoría, ReqIF resuelve el problema del intercambio de requisitos entre comprador y licitador. En la práctica hay problemas de interoperabilidad documentados: al importar ReqIF de Polarion en IBM DOORS todos los objetos se marcan como bloqueados. Las versiones antiguas de DOORS implementaban RIF 1.0, mientras Polarion utilizaba RIF 1.1a, lo que provocaba errores de importación silenciosos . Las extensiones específicas de cada proveedor, la ausencia de filtrado de atributos y las incompatibilidades de versión siguen siendo problemas.
La penetración se estimó en un 30% en 2020. En la industria ferroviaria es menor que en la industria automovilística. El artículo de CONTACT Software señaló en 2014 que la mayoría de los fabricantes todavía no podían entregar sus especificaciones en el formato correcto. Esto ha mejorado desde entonces, pero muchos proveedores pequeños siguen intercambiando requisitos mediante Excel.
Desafíos habituales
El tratamiento de un pliego de requisitos se prolonga de semanas a meses en los grandes proyectos ferroviarios. Los problemas que aparecen son conocidos en todos los sectores con licitaciones extensas. En la industria ferroviaria son más pronunciados porque los volúmenes de requisitos, el número de equipos implicados y la profundidad regulatoria son mayores.
El número de requisitos que deben comentarse al tramitar pliegos de requisitos se ha multiplicado al menos por diez en los últimos diez años.
– Responsable de un fabricante de sistemas de frenado, CONTACT Software Blog (2014)Fuente: CONTACT Software, tren lento hacia la gestión de requisitos
El mismo artículo menciona otras causas: las normas nacionales de distintos países entran en conflicto entre sí, los interesados internacionales interpretan las normas de manera distinta y las licitaciones múltiples del mismo comprador dan lugar a especificaciones divergentes entre lotes. Además, los documentos de requisitos pasaron de caber en un CD a necesitar un DVD, solo para contener el alcance de una única licitación.
Las cifras intersectoriales confirman esta situación. El Loopio 2025 RFP Response Trends Report (más de 1.500 equipos de propuestas, todos los sectores) muestra que el 48% de los equipos informa de dificultades para colaborar con expertos, y el 39% tiene problemas para encontrar a tiempo respuestas precisas a preguntas técnicas. No hay una encuesta comparable para la industria ferroviaria, pero dado el mayor número de equipos de subsistemas implicados, la proporción real probablemente sea más alta.
La calidad de la especificación como cuello de botella
El problema suele comenzar con el propio pliego de requisitos. Prover Technology identifica tres problemas principales en las especificaciones durante la fase de licitación: incompletas, incoherentes y defectuosas. Los errores que no se detectan en esta fase se arrastran durante todo el ciclo de vida del proyecto y se encarecen de corregir con cada fase.
Qué debe contener una especificación del sistema
La especificación del sistema (Compliance Document o Technical Offer) es la respuesta oficial al pliego de requisitos. Documenta para cada requisito individual si el proveedor lo cumple y cómo lo hace. Una especificación del sistema profesional contiene:
- Cobertura completa de requisitos: se aborda cada requisito del pliego de requisitos; no se omite ninguno
- Clasificación justificada: OK, OKB, NOK, OKM o R con una explicación concreta (más información en el análisis detallado sobre clasificación)
- Referencias de evidencia: remisión a documentos fuente como informes de ensayo, documentos de homologación, evidencias RAMS o fichas técnicas del fabricante
- Cumplimiento normativo: asignación a normas relevantes (TSI, DIN EN, ISO, CENELEC EN 50126/50716/50129)
- Condiciones y propuestas alternativas: formulación clara para OKB y OKM
- Pliegos de requisitos parciales: desglose por subsistema para el tratamiento interno y la transmisión a proveedores
El estándar EuroSpec de gestión de requisitos define además seis ámbitos fundamentales: características de los requisitos, sintaxis, atributos, trazabilidad, validación/verificación e intercambio de datos. Esta estructura ofrece una buena orientación para asegurar la calidad de las especificaciones del sistema.
La diferencia entre especificaciones del sistema buenas y malas
La calidad de una especificación del sistema determina a menudo la adjudicación o la exclusión. En procedimientos de contratación regulados, como los de la ESA o bajo la legislación de contratación pública, las discrepancias entre las declaraciones de cumplimiento y la oferta real pueden llevar a reducciones considerables de puntuación o a la exclusión. Las prioridades de UNIFE para 2024-2029 recomiendan aplicar el principio MEAT (Most Economically Advantageous Tenders) con costes de ciclo de vida. En la práctica, esto significa que el cliente evalúa basándose en la matriz de cumplimiento, y se penalizan las lagunas o incoherencias.
Cómo la digitalización y la IA cambian el proceso
La digitalización se produce en dos pasos. Primero, el paso de Excel y Word a sistemas basados en bases de datos. Después, sobre esa base, el apoyo de la IA.
Paso 1: Sistemas basados en bases de datos
Las herramientas consolidadas en el sector ferroviario son IBM DOORS (estándar de facto en sectores regulados desde hace décadas), Siemens Polarion (con soporte nativo de ReqIF) y Reqtify de Dassault Systèmes (una capa de trazabilidad con más de 100 interfaces). Muchas empresas ferroviarias ya han dado este paso o están en proceso de hacerlo.
Un ejemplo concreto: Rail Projects Victoria (Melbourne) eligió DOORS Next como solución SaaS para el Metro Tunnel Project, con el fin de gestionar centralmente los requisitos de varios participantes en el proyecto. Deutsche Bahn no introdujo un sistema de gestión de requisitos basado en bases de datos hasta alrededor de 2012/2013, como documenta el artículo de CONTACT Software .
Paso 2: Apoyo de la IA
Según el Loopio 2025 RFP Response Trends Report, el 68% de los equipos de propuestas de todos los sectores ya utiliza IA generativa, el doble que el 34% de 2023. En la industria ferroviaria, este cambio todavía está en gran medida por llegar.
Cuánto puede automatizarse depende de la fase:
Captura de requisitos: análisis automático, estructuración y detección de diferencias entre revisiones. La guía VDB recomienda para ello el formato ReqIF, que permite el marcado automático de cambios.
Clasificación: comparación de requisitos con documentos internos, normas y respuestas de proyectos anteriores. Aquí está el mayor potencial, pero la calidad depende por completo de la base de conocimiento interna, y la decisión final sigue siendo responsabilidad del experto.
Enrutamiento a expertos: asignación automática en función de la temática, la categoría LH y la referencia normativa. Plataformas como Tendric utilizan enrutamiento basado en reglas para reducir las asignaciones incorrectas.
Respuesta: generación de propuestas de respuesta a partir de la base de conocimiento. Según Bidara, la tasa de reutilización de contenido intersectorial es del 66%, un potencial que muchas empresas no aprovechan por carecer de una base de conocimiento consultable.
Exportación: formato automatizado y generación de pliegos de requisitos parciales por subsistema y proveedor.
Desde octubre de 2023, la EN 50716 sustituye a las anteriores EN 50128 y EN 50657. La nueva norma permite por primera vez el desarrollo iterativo (Agile/Scrum), contiene disposiciones para componentes de IA/ML y exige la integración de ciberseguridad conforme a CENELEC TS 50701. Para los gestores de ofertas, esto significa que deben actualizarse las referencias normativas de las antiguas plantillas de especificación del sistema.
Según Verified Market Reports, el mercado de software de gestión de licitaciones crecerá hasta los 3.500 millones de USD en 2033 (CAGR del 9,8%). En el sector ferroviario están extendidas herramientas consolidadas como IBM DOORS y Siemens Polarion, pero siguen siendo escasas las soluciones especializadas para todo el camino del pliego de requisitos a la especificación del sistema, como Tendric.
Conclusión y próximos pasos
Cuanto mayor sea el pliego de requisitos, más compensa un proceso estructurado. Con cientos o miles de requisitos, 11 TSI, evidencias CENELEC y una cadena de suministro con decenas de proveedores de subsistemas, la diferencia entre el trabajo basado en documentos y el respaldado por una base de datos se convierte en el factor decisivo.
El nivel de madurez puede dividirse, a grandes rasgos, en cuatro etapas:
- Excel y Word (basado en documentos, sin trazabilidad)
- Sistema basado en bases de datos (DOORS, Polarion) con gestión central de requisitos
- Plataforma integrada con intercambio ReqIF, enrutamiento a expertos y exportación de pliegos de requisitos parciales
- Clasificación y generación de respuestas asistidas por IA sobre una base de conocimiento interna
Quien hoy sigue en la etapa 1 no debería intentar saltar directamente a la etapa 4. El primer paso más evidente es un sistema central en el que requisitos, clasificaciones, referencias de fuentes y respuestas estén vinculados y sean trazables. Herramientas como Tendric proporcionan exactamente esta estructura. Sin esos datos estructurados, el apoyo de la IA no tiene base.
- Específico de la industria ferroviaria: varias TSI, evidencias CENELEC EN 5012x y normas nacionales (NNTR) por proyecto
- El proceso abarca 5 fases, desde la captura hasta la exportación, que a menudo se ejecutan en paralelo en la práctica
- OEM como Alstom coordinan a más de 21.000 proveedores, cada uno de los cuales debe responder a su propio pliego de requisitos parcial
- ReqIF resuelve el intercambio en teoría, pero presenta problemas documentados de interoperabilidad entre herramientas
- Desde octubre de 2023, EN 50716 sustituye a EN 50128/50657 e incorpora disposiciones sobre IA/ML y ciberseguridad
- Progresión de madurez: Excel → base de datos → plataforma integrada → apoyo de IA
Das tendric-Team entwickelt KI-gestützte Werkzeuge für die Ausschreibungsbearbeitung in der Industrie. Wir schreiben über Best Practices, Branchentrends und die Zukunft des Angebotsmanagements.