Buenas prácticas en las adquisiciones de Defensa

Manfredo Monforte Moreno

GD(r) Dr. Ingeniero de Armamento. MBA. MTIC. Artillero

De la Academia de las Ciencias y las Artes Militares

Los programas de adquisición en el sector de la defensa y la seguridad suelen dar lugar a procesos complejos, poliédricos, que deberían abordarse mediante buenas prácticas basadas en las metodologías de gestión de proyectos e ingeniería de sistemas. El hecho de que los programas de adquisición tropiecen dificultades no es algo excepcional, pues se trata de proyectos muy complicados que dan lugar a sistemas complejos con diversas configuraciones. A ello hay que añadir la necesidad de gestionar el ciclo de vida que, a menudo, se extiende durante varias décadas y supone la aplicación de mantenimientos correctivos, preventivos y predictivos, así como una o más actualizaciones (overhaul). Ejemplos como el obús autopropulsado M109, el vehículo BMR, el M113, el helicóptero CH47 Chinook, el F18 o algunos buques de la Armada dan fe de la larga vida operativa que suelen tener los sistemas militares.

Las dificultades que aparecen en los procesos de adquisición son muy habituales. Los problemas en cuanto a retrasos, sobrecostes y renuncias a ciertos requisitos a la hora de incorporar los sistemas se suceden. Como en el caso del 8x8 Dragón o el nuevo submarino, la Administración se ve obligada a negociar concesiones, admitir desviaciones y, en pocas ocasiones, a la aplicación de dolorosas cláusulas de penalización recogidas en los contratos. Las causas son muy variadas; trataré de exponer algunas y sus posibles soluciones.

Cualquier adquisición en defensa nace de una declaración de una necesidad operativa y la escritura de un documento de especificaciones de empleo. Aquí se origina el primer problema: en algunos casos se redactan requisitos que no cuentan con trazabilidad respecto a la cuestión que tratan de resolver (el porqué y el para qué del requisito) y, lo que es peor, se corrompe el proceso desde el inicio fijando una solución técnica (el cómo satisfacerla). Los estados mayores encargados de la redacción de estos documentos, críticos para el éxito final de la obtención, deben conocer el estado del arte industrial, las posibilidades nacionales, el coste de ciertas especificaciones y del ciclo de vida, así como la influencia del entorno operativo en que se desea desplegar el sistema. En algunos casos se observa una tendencia a sobreespecificar y en otros, a solicitar prestaciones excesivas, restricciones innecesarias o requisitos incompatibles entre sí. Sería conveniente que antes de dar por aprobado el documento de especificaciones operativas se pase un primer filtro del órgano técnico que debe traducir dichas necesidades a un pliego de especificaciones técnicas (PPT) —quien debería contar con la industria para no errar en su trabajo—, así como con el departamento que debe escribir el pliego de cláusulas administrativas (PCA) y que fija los elementos que se incorporarán al contrato, los criterios de evaluación de las ofertas, los plazos, las penalizaciones, los precios y otros detalles habituales. Tanto las especificaciones operativas como los requisitos técnicos están expuestos a cambios durante la fase de desarrollo, fabricación y pruebas del sistema.

Cuando se cuenta con un documento estable de requisitos operativos hay que traducirlos a un PPT. En este segundo documento se recogen los detalles técnicos que debe satisfacer el proveedor del sistema. De hecho, sus requisitos deben ser:

-          Necesarios. En ocasiones se requieren elementos que pueden adquirirse fuera del contrato y que no condicionan la calidad del sistema. Tal es el caso de incluir el suministro de redes miméticas multiespectrales en la compra de un vehículo y que pueden adquirirse por separado y, casi siempre, con ventajas en precio.

-          Independientes. Pueden imponerse requisitos de cualquier nivel, pero nunca de diseño. Se debe fijar qué debe hacer el sistema, pero no cómo. Este axioma se incumple cuando se exige la incorporación de ciertos elementos, como una determinada estación de armas, una caja de cambios o un subsistema de protección NBQ.

-          Alcanzables. Cuando los ingenieros que deben diseñar el sistema participan en las reuniones de captura de requisitos, pueden conocer con precisión lo que puede hacerse y lo que no.   

-          Sin ambigüedad. Es decir, claros y completos, de manera que su interpretación sea única y no admita otras. Para ello, la calidad de la redacción es básica; se debe ser muy cuidadoso con los signos de puntuación y las conjunciones copulativas. Por ejemplo, si se fija el peso de un vehículo de combate en 15 toneladas, ¿está incluido el peso de la tripulación?

-          Consistentes. No pueden contradecirse normas técnicas ni ir más allá de ellas.

-          Completos. Cada requisito es una petición al diseñador, que debe comprender lo que se demanda y el nivel al que se refiere.

-          Formar un conjunto completo. Deben evitarse repeticiones, zonas de sombra o ignoradas.

-          Medibles: susceptibles de ser verificados objetivamente y validados sin ambigüedad. Es demasiado habitual leer: “el acceso debe ser cómodo y no contar con interferencias” o “el asiento debe ser cómodo”. En ocasiones, las pruebas de cumplimiento requieren equipos muy sofisticados —y caros— como pueden ser las cámaras climáticas o las pruebas de protección balística.

-          Sólidos. No fraccionables.

-          Consensuados. Entre órgano de contratación, oficinas de programa y ciclo de vida y suministrador, de manera que todas las partes interpreten lo mismo. En este caso, es fundamental emplear tiempo y esfuerzo durante la fase de captura de requisitos.

-          Trazables. La razón que los motiva debe poder identificarse.

-          Actualizados. Deben considerar los cambios en el diseño, la fabricación y la operación.

-          Contextuales. Debe estar enmarcados en un escenario y unas condiciones determinadas de aplicación.

Un problema recurrente en el PPT es la inclusión de requisitos “deseables”, valorables o no, con precios limitados o no, que deben contemplarse en la oferta o no, y que carecen de sentido casi siempre. Por ejemplo: “la capacidad de vadeo del vehículo será de 60 cm, deseable 90 cm”. Para satisfacer el requisito se puede poner un esnórquel de admisión o no, alternador elevado o estanco, sistema de parada automática del electroventilador, etc. La solución que se adopte tendrá una clara repercusión en el precio final y coloca al potencial suministrador en una encrucijada de difícil solución. Si en el PPT hay muchos “deseables” valorables técnicamente pero no en el límite de precio del sistema, el diseñador tendrá que “ahorrar” en otros subsistemas, conjuntos o subconjuntos y las ofertas no serán comparables entre sí.  

Los retos de la gestión de requisitos se centran en mantenerlos constantemente bajo control, estables y con una línea base consensuada entre las partes interesadas. A menudo este proceso debe atender a elementos que quedan para decisión posterior al contrato, los conflictos que no se pueden resolver sobre la marcha o sucesos de los que hay que informar cuando se producen. La finalidad es prevenir y gestionar oportunamente las desviaciones que supongan riesgo para los objetivos del sistema y del proyecto.

Lograr una buena gestión de requisitos precisa de un esfuerzo para capturarlos o, lo que es lo mismo, un trabajo serio de aclaración y traducción, algo que puede beneficiarse de la presencia de los usuarios finales del sistema. El riesgo para la industria de sentarse con las oficinas de programa una vez firmado el contrato es que en ocasiones no se acierta a definir con precisión qué es lo que se necesita o se trata de introducir a coste cero nuevos requisitos complementarios por errores en el PPT.

La oferta inicial de los diversos candidatos a un contrato tiene una finalidad única: conseguir el encargo. Es, junto al PPT, PCA e invitación para licitar, el primer documento del proyecto y su contenido, incluidas las mejoras, es exigible en todos los casos. La necesidad de conseguir el contrato conlleva a menudo la aceptación a ciegas de condiciones respecto a los objetivos de plazo, coste y prestaciones que después se muestran inalcanzables (lo que suele conocerse como “prometer hasta vender”).

Es necesario citar aquí las complejas relaciones empresariales que se dan en algunos procesos de obtención. Basta citar el caso del BMS Lince (Indra + Amper Sistemas —hoy Thales España—) o el 8x8 Dragón (Tess Defense —propiedad mayoritaria de Indra—: EM&E Group + INDRA + SAPA + SBS). En ambos casos los retrasos e incumplimientos de sus suministros no se deben tanto a la ingeniería de los participantes, sino a las relaciones entre ellos, dando lugar a procesos jurídicos complejos con base en las distintas sensibilidades respecto a los incumplimientos (léase grado de madurez, interfaces e interoperabilidad de cada aportación). Por ejemplo, si un vehículo de combate de ingenieros debe presentar una protección antimina nivel 3 a y b según Stanag 4569 y 3 balístico, pero la estación de armas y los sistemas hidráulicos de la grúa disponen tan solo del nivel 1, el sistema en su conjunto podrá alcanzar el nivel 3 a y b pero se quedará en el 1 balístico en cuanto a su probabilidad de supervivencia en condiciones de empleo real.

La oferta debe demostrar que se han reconocido las necesidades a cubrir, es decir, que la solución propuesta proporciona lo que pide la Administración, pero no olvida lo que se cree que necesita y no ha pedido o lo que sería conveniente ofrecer adicionalmente. Las alternativas tecnológicas deben estar detalladas; todo el esfuerzo que se dedique a mejorar la calidad de la oferta servirá para predisponer positivamente al receptor. La experiencia aconseja contar con ese bien escaso que es el tiempo. Casi todas las ofertas terminan por encuadernarse (electrónicamente ahora) con prisas, lo que penaliza el resultado final: sin tiempo es difícil demostrar que se está en perfecta sintonía con lo recogido en PPT y PCA. Deberían incorporarse elementos que aporten confianza y enriquezcan el documento, como fotografías, planos, muestras y referencias de sistemas similares. Cuando la adquisición requiere la entrega de una muestra, esta debe obedecer exactamente al texto descriptivo de la oferta. La muestra entregada debe poder pasar con éxito las pruebas que demostrarán el cumplimiento de lo ofertado. A menudo, las fichas de verificación contienen valoraciones subjetivas no medibles: “el vehículo pierde velocidad subiendo pendientes prolongadas por encima del 6%”, frase que no permite valorar la observación del evaluador.

La industria de defensa española debe ser consciente de los compromisos que asume al firmar un contrato de suministro. Retrasos inadmisibles como los que se dieron en su día en sistemas como BMS Lince, S80, 8x8 Dragón o Castor deben hacer reflexionar a los protagonistas industriales y a la Administración. Todos deben poner de su parte, desde la declaración de la necesidad operativa a la puesta en servicio, para que no se entreguen sistemas fuera del plazo previsto, con un coste mayor (a veces compensado con la entrega de menos unidades) o que incumplen gran parte de los requisitos técnicos previstos.  La figura del contratista principal integrador como máximo y único responsable del contrato debería recuperarse.

Imágenes: Google images y propias.