Asignación de expertos en licitaciones: llevar requisitos a las personas adecuadas

Introducción

Un pliego de requisitos para un vehículo ferroviario contiene desde cientos hasta miles de requisitos individuales. Tracción, frenado, protección contra incendios, climatización, información al pasajero, accesibilidad, mantenimiento: cada disciplina tiene sus propias normas, obligaciones de evidencia y lenguaje técnico. Ningún ingeniero puede evaluar todo esto por sí solo. Por ello, el responsable de la oferta distribuye los requisitos entre expertos de diferentes departamentos y disciplinas. Este proceso se denomina enrutamiento de expertos.

Lo que parece sencillo es, en la práctica, uno de los mayores cuellos de botella en la preparación de ofertas. Ya en 2014, un responsable de un fabricante de sistemas de frenado explicó a CONTACT Software, que el número de requisitos que había que comentar se había multiplicado al menos por diez durante los diez años anteriores. El volumen de los documentos de licitación había pasado, en el mismo periodo, de un CD a un DVD. Desde entonces, el volumen ha seguido creciendo, al igual que el número de expertos implicados.

Las cifras son similares en todos los sectores: según el informe Loopio 2025 RFP Response Trends (más de 1.500 empresas de todos los sectores), el 48 % de los equipos de propuestas identifica la colaboración con expertos como su principal reto, por quinto año consecutivo. En el sector ferroviario, donde normalmente trabajan en paralelo entre 10 y 30 equipos de subsistemas, la carga real de coordinación probablemente sea aún mayor.

Por qué el enrutamiento de expertos es decisivo

La calidad de una oferta depende directamente de que cada requisito sea evaluado por el experto adecuado. Un ingeniero de protección contra incendios puede clasificar con competencia un requisito relativo a EN 45545 pero no uno relativo a la compatibilidad con ETCS. A la inversa, un técnico de señalización no puede pronunciarse sobre la resistencia estructural conforme a EN 12663. El grupo de trabajo sobre requisitos de INCOSE define la asignación de requisitos, es decir, la asignación de requisitos a elementos y personas responsables del sistema, como una de las actividades centrales de la gestión de requisitos, al mismo nivel que la trazabilidad y la verificación.

Los errores de enrutamiento tienen consecuencias directas:

• Clasificación incorrecta: una persona no experta clasifica un requisito como "OK" cuando en realidad solo puede cumplirse bajo condiciones (OKB). En el proyecto, esto se convierte en una solicitud de cambio.
• Retrasos: un requisito llega al departamento equivocado, se reenvía y vuelve a quedar en una cola. Se pierden días. Según Loopio, el 33 % de los equipos afirma que respuestas más rápidas de los expertos serían su principal medio para ganar más licitaciones.
• Trabajo duplicado: sin una responsabilidad clara, dos departamentos procesan el mismo requisito de forma independiente, posiblemente con resultados contradictorios.
• Lagunas: un requisito no se asigna a ningún experto y queda sin tratar. En el peor de los casos, falta la respuesta en el pliego de especificaciones.

Fuente: CONTACT Software: Del tren lento a la gestión de requisitos

La estructura LH y EN 15380: cómo se organizan los pliegos de requisitos

En el sector ferroviario, los pliegos de requisitos suelen dividirse en secciones temáticas que cubren distintos subsistemas y especialidades. Una estructura habitual utiliza las denominadas categorías LH (LH1 a LH8), que la guía de gestión de requisitos de VDB describe como ayuda para la estructuración.

En paralelo, la serie de normas EN 15380 define un sistema normalizado de clasificación para vehículos ferroviarios. La parte 2 (grupos de productos) divide un vehículo en grupos de productos definidos; la parte 4 (grupos funcionales) asigna funciones como tracción, frenado o control de puertas; y la parte 5 (estructura de desglose de sistemas) define la división jerárquica en sistemas principales y subsistemas. EN 15380 es relevante para el enrutamiento de expertos porque proporciona una taxonomía estable e independiente del fabricante: si cada requisito se asigna a un subsistema EN 15380, la decisión de enrutamiento puede automatizarse o, al menos, normalizarse.

Volumen típico de requisitos por categoría LH (representación relativa; varía según el proyecto y el cliente).

La estructura LH es la base natural para el enrutamiento de expertos: los requisitos LH3 pasan al equipo de tracción, los LH6 a interiorismo y los LH7 al departamento de TI. Sin embargo, la asignación rara vez es tan inequívoca como sugiere la estructura.

El flujo de trabajo de enrutamiento en la práctica

Independientemente de que una empresa trabaje con Excel, un sistema ALM o una plataforma especializada, el proceso de enrutamiento sigue un patrón similar:

RACI y matrices de competencias: sistematizar el enrutamiento

En los pliegos de requisitos grandes no basta con asignar los requisitos de forma ad hoc. Las empresas que han sistematizado el proceso trabajan con dos instrumentos:

Matriz RACI para el enrutamiento: para cada categoría LH, o cada subsistema EN 15380, se define quién es Responsible, Accountable, Consulted e Informed. Por ejemplo, el ingeniero de tracción es Responsible de los requisitos LH3 y Consulted en los requisitos LH4 con una interfaz de tracción. La matriz RACI evita que los requisitos transversales se pierdan en la asignación, porque el papel de consulta (Consulted) se documenta explícitamente.

Matriz de competencias por proyecto: una tabla de asignación que documenta, para cada experto disponible, qué normas, subsistemas y tecnologías puede cubrir. Si un pliego contiene por primera vez requisitos sobre propulsión de hidrógeno, la matriz muestra inmediatamente si el conocimiento existe dentro de la empresa o debe obtenerse externamente. La mayoría de las empresas construyen su matriz de competencias a partir de proyectos anteriores y la actualizan para cada proyecto.

Dónde surgen las pérdidas por fricción

Sobre el papel, este flujo de trabajo parece lineal. La realidad es distinta.

1. El problema de la distribución

En un pliego con 1.500 requisitos, la asignación inicial por sí sola puede requerir varios días de trabajo si se realiza manualmente. El responsable de la oferta debe leer, entender y asignar cada requisito al experto correcto. Con los requisitos transversales, la decisión no es trivial, especialmente si el responsable no conoce todas las disciplinas con el mismo nivel de detalle. En el sector tecnológico, según Loopio incluso el 57 % de los equipos informa de dificultades con la coordinación de expertos, el valor más alto de todos los sectores.

2. Disponibilidad de los expertos

Los expertos del sector ferroviario no son personal dedicado exclusivamente a las ofertas. Trabajan en paralelo en proyectos en curso, tareas de desarrollo y otras licitaciones. Si un experto en protección contra incendios está ocupado durante dos semanas en un proyecto de homologación, sus requisitos quedan parados, con independencia del sistema de enrutamiento que utilice la empresa. Según su propia página de proveedores Alstom coordina unos 19.000 proveedores en 77 países. Cada uno de ellos tiene sus propios cuellos de botella de capacidad, que afectan a los plazos de respuesta del fabricante.

3. Falta de transparencia sobre el estado de procesamiento

En los flujos de trabajo basados en documentos, como Excel o Word por correo electrónico, el responsable de la oferta no tiene una visión en tiempo real de qué requisitos ya se han procesado, cuáles siguen abiertos y dónde aparecen cuellos de botella. Las consultas de estado por correo o en reuniones consumen tiempo y a menudo ofrecen resultados imprecisos. Según Loopio, el 39 % de los equipos tiene dificultades para encontrar respuestas actuales y precisas a preguntas técnicas. En el sector ferroviario, donde los requisitos suelen hacer referencia a fuentes normativas que cambian entre revisiones, este problema es especialmente acusado.

4. Problemas de coherencia

Cuando 20 expertos procesan requisitos de forma independiente, pueden surgir contradicciones: el departamento A clasifica una interfaz como "OK", mientras que el departamento B clasifica el requisito correspondiente como "OKB". Estas incoherencias suelen detectarse tarde, durante la fase de consolidación, cuando queda poco tiempo para corregirlas. La norma EuroSpec para la gestión de requisitos aborda este problema mediante sus seis ámbitos centrales (características de los requisitos, sintaxis, atributos, trazabilidad, validación/verificación e intercambio de datos), pero cumplir estas normas exige que todos los expertos implicados trabajen en el mismo sistema.

Modelos organizativos para el enrutamiento

La forma en que las empresas organizan el enrutamiento de expertos depende de su tamaño, su estructura organizativa y el nivel de apoyo de sus herramientas. En la práctica predominan tres modelos:

La mayoría de las empresas utiliza un modelo híbrido: el responsable de la oferta realiza la preasignación gruesa a nivel de subsistema, basándose en las categorías LH o en la asignación EN 15380, y los responsables de subsistemas distribuyen en detalle dentro de su área. El responsable de la oferta identifica y asigna varias veces los requisitos transversales. En grandes licitaciones de consorcios, como el contrato de 15.000 millones de euros para el S-Bahn de Berlín (DB, Siemens, Stadler), los requisitos también se reparten entre los socios del consorcio, lo que añade otro nivel de enrutamiento.

Trazabilidad: lo que exigen EN 50126 e ISO 22163

El enrutamiento de expertos también es un requisito regulatorio. La CENELEC EN 50126 define el ciclo de vida RAMS (fiabilidad, disponibilidad, mantenibilidad y seguridad) y exige una trazabilidad completa en el marco del modelo V. Cada requisito debe poder asignarse a una actividad de verificación, una persona responsable y una evidencia. La especificación y asignación de requisitos del sistema constituye una fase propia del ciclo de vida del modelo V, con funciones definidas para cada fase. Quién evaluó cada requisito forma parte de la evidencia de seguridad, no es un extra opcional.

La ISO 22163:2023 (IRIS Rev. 04) exige, en sus secciones sobre diseño y desarrollo, trazabilidad desde los requisitos del cliente hasta la evidencia de diseño. IRIS va más allá de ISO 9001 y añade requisitos ferroviarios para la gestión de proyectos, la First Article Inspection (FAI), las evidencias RAMS y los costes del ciclo de vida. La norma se aplica a toda la cadena de suministro: desde la empresa de desarrollo, pasando por el fabricante y los proveedores, hasta la empresa de mantenimiento. En el contexto de una oferta, esto significa que la asignación de requisitos a expertos y sus evaluaciones debe documentarse de forma comprensible, no solo para el equipo propio sino también para auditores externos y el organismo de certificación IRIS.

Herramientas para el enrutamiento de expertos

Las herramientas van desde hojas de cálculo de Excel hasta sistemas ALM. Lo que utiliza una empresa determina cómo funcionan en el día a día el enrutamiento, el seguimiento de estado y la trazabilidad.

Excel con columnas de asignación

El enfoque más sencillo: cada fila de requisitos recibe una columna "Responsable", en la que se introduce el nombre del experto. Las vistas filtradas por experto permiten una distribución básica del trabajo. Sus desventajas son la ausencia de notificaciones, de seguimiento de estado y de procesamiento en paralelo, con la conocida pregunta de "¿quién tiene la versión actual?". El artículo de CONTACT Software describía en 2014 que incluso Deutsche Bahn había introducido "recientemente" un sistema de gestión de requisitos basado en bases de datos.

IBM DOORS / DOORS Next

El sistema líder de gestión de requisitos en los sectores ferroviario y aeroespacial. DOORS ofrece asignaciones basadas en reglas, trazabilidad y análisis de impacto de cambios. Un ejemplo concreto: Rail Projects Victoria (Melbourne) eligió DOORS Next como solución SaaS para el Metro Tunnel Project de AUD 11.000 millones. El sistema creó un entorno central y colaborativo en el que los requisitos podían gestionarse en tiempo real entre múltiples partes interesadas internas y externas. Para el enrutamiento fue especialmente relevante que la integración de registros de peligros y registros de interfaces garantizara la correcta asignación de controles y requisitos a las partes adecuadas. RPV aplica ahora los conocimientos adquiridos también a otros proyectos, como Regional Rail Revival y Melbourne Airport Rail.

Siemens Polarion

Polarion es la alternativa de Siemens con el mismo alcance funcional. Hitachi Rail ha integrado Polarion en sus flujos de trabajo de proyecto para sustituir Excel y Word como soportes de requisitos. Desde 2025, Polarion ofrece también funciones asistidas por IA para la extracción automática de requisitos de documentos de licitación. La IA analiza los objetos de requisitos por dominio y asigna los departamentos responsables según los dominios detectados; Siemens cifra la reducción del esfuerzo manual en hasta un 70 %.

Plataformas especializadas

Además de los grandes sistemas ALM, surgen cada vez más plataformas especializadas centradas en el proceso de ofertas. Tendric utiliza, por ejemplo, enrutamiento basado en reglas con una barrera de entrada menor que DOORS o Polarion, pero soporte específico para el enrutamiento, la clasificación y la exportación de pliegos de especificaciones. Los datos intersectoriales muestran que los equipos con una biblioteca de contenidos estructurada alcanzan una tasa de reutilización del 66 % y tienen casi el doble de probabilidades de lograr altas tasas de éxito. Las plataformas especializadas actúan donde Excel deja de escalar, pero un sistema ALM completo sería sobredimensionado.

¿Puede la IA automatizar el enrutamiento?

La asignación automática de requisitos a expertos es un caso de uso evidente para sistemas basados en IA. La idea básica es que, si un sistema aprende de miles de requisitos asignados históricamente qué formulaciones y temas pertenecen a cada departamento técnico, puede proponer una asignación inicial para nuevos pliegos.

Esto funciona bien para requisitos claramente asignables: un requisito que contiene "EN 45545" o "clase de protección contra incendios" se asigna de forma fiable al equipo de incendios. Los sistemas modernos como Polarion con capa de IA van más allá: comprenden la semántica de los requisitos, no solo la coincidencia de palabras clave, comparan requisitos nuevos con los existentes y detectan automáticamente cambios entre revisiones. Sin embargo, con requisitos transversales o formulaciones nuevas, por ejemplo propulsión de hidrógeno o FRMCS como sucesor de GSM-R, la tasa de acierto disminuye considerablemente.

Según Loopio el 68 % de los equipos de propuestas de todos los sectores ya utiliza IA generativa, el doble del 34 % de 2023. El 70 % de quienes usan IA lo hace al menos semanalmente. En el sector ferroviario, este cambio todavía está empezando, pero las primeras soluciones integradas, Polarion AI, DRIM y Tendric, muestran la dirección.

Caso de estudio: Melbourne Metro Tunnel Project

El Melbourne Metro Tunnel Project es uno de los mayores proyectos de infraestructura de Australia: un nuevo corredor ferroviario subterráneo para más de 500.000 pasajeros adicionales por semana, con un volumen de AUD 11.000 millones. Rail Projects Victoria (RPV) debía coordinar miles de requisitos repartidos entre múltiples paquetes de trabajo y cientos de ingenieros de distintas organizaciones.

RPV eligió IBM Engineering Requirements Management DOORS Next como solución SaaS. El resultado fue un entorno central de colaboración respaldado por seguridad, una "única fuente de verdad", en el que los requisitos podían gestionarse en tiempo real y compartirse selectivamente con cada organización, de acuerdo con sus áreas funcionales en el proyecto. La integración de registros de peligros y registros de interfaces garantizó que los requisitos se asignaran correctamente a las partes adecuadas.

A partir de esta experiencia, RPV desarrolla ahora un marco normalizado de gestión de requisitos que se prevé trasladar a otros proyectos, como Regional Rail Revival y Melbourne Airport Rail.

Conclusión

El enrutamiento de expertos es el cuello de botella invisible de la preparación de ofertas en el sector ferroviario. El desafío no reside solo en la tecnología, sino en la combinación de volumen, desde cientos hasta miles de requisitos; complejidad, decenas de disciplinas técnicas y normas desde TSI y CENELEC hasta ISO 22163; y presión de tiempo, con plazos de entrega de pocas semanas.

Un buen sistema de enrutamiento, ya sea basado en tablas o apoyado por herramientas, debe cumplir cuatro funciones: distribución inicial rápida basada en una taxonomía estable, categorías LH y EN 15380; seguimiento de estado transparente en tiempo real; documentación comprensible para la trazabilidad EN 50126; y equilibrio de la carga de trabajo entre todos los expertos implicados.

IBM DOORS y Siemens Polarion cubren el ámbito empresarial; las plataformas especializadas como Tendric cubren a las empresas medianas, y las soluciones asistidas por IA la asignación inicial. Sin embargo, más importante que elegir la herramienta es la disciplina que la acompaña: matrices RACI, asignaciones de competencias y seguimiento consecuente. El mayor riesgo no es una herramienta incorrecta, sino requisitos que no se asignan a ningún experto o cuyo estado de procesamiento nadie conoce.