9.2.2010   

ES

Diario Oficial de la Unión Europea

C 32/1

ANS

Acuerdo sobre el nivel de servicio

BCE

Banco Central Europeo

COBIT

Objetivos de control para la información y tecnologías afines (Objectives for Information and related Technology)

DG-H

Dirección General de Recursos Humanos, Presupuesto y Organización

DG-SI

Dirección General de Sistemas de Información

EER

Renovación de la ECB-LAN Eurotower (ECBLAN Eurotower Refresh)

GDP

Grupo de dirección del proyecto

ICR

Indicador clave de resultados

MAU

Actualización de la zona de las salas informáticas principales (Main computer rooms Area Upgrade) del edificio Eurotower

MDP

Presentación de datos de mercado (Market Data Provision)

MPIDS

Sistema de ayuda a la decisión para la ejecución de la política monetaria (Monetary Policy Implementation Decision support System)

PCR

Documento de fin de proyecto (Project Closure Report)

PCU Target 2

Plataforma compartida única para Target 2

PMBOK

Conjunto de conocimientos sobre la gestión de proyectos (Project Management Body of Knowledge)

PMI

Instituto de gestión de proyectos (Project Management Institute)

POCP

Procedimientos relativos a la organización y al control de los proyectos (Project Organisation and Control Procedures)

PSD

Documento de presentación del proyecto (Project Submission Document)

PSR

Informe de situación del proyecto (Project Status Report)

SEBC

Sistema Europeo de Bancos Centrales

TCERTO

Extensión de la teleconferencia, de la CoreNet y de la SEBC-Net a Bulgaria y Rumanía

TI

Tecnologías de la información

1.

El Banco Central Europeo (en lo sucesivo, el BCE o «el banco») y los bancos centrales nacionales de los Estados miembros de la UE componen el Sistema Europeo de Bancos Centrales (SEBC). El objetivo principal del SEBC es mantener la estabilidad de precios, aunque también respalda las políticas económicas generales de la Unión para contribuir a la realización de los objetivos comunitarios (1). Con este fin, el BCE ejerce las funciones previstas en sus Estatutos (2) y se encarga de gestionar sus finanzas y actividades.

2.

La fiscalización por el Tribunal de la eficacia operativa del BCE se basa en el artículo 27, apartado 2, del Protocolo sobre los Estatutos del SEBC y del BCE (3). El ámbito controlado fue la gestión por el BCE de los proyectos informáticos en los ejercicios 2007 y 2008. Se tuvieron en cuenta además los cambios introducidos en las prácticas del BCE durante el primer trimestre de 2009.

3.

El presupuesto del BCE se divide en dos partes principales: actividades destinadas al «funcionamiento del banco» (los gastos de operaciones (4) de las unidades de gestión del BCE) y actividades cuyo fin es la «construcción y desarrollo del banco»; estas últimas a su vez se subdividen en dos importantes grupos:

4.

Los gastos del BCE relativos a los proyectos informáticos (5) en 2007 ascendieron a 20 millones de euros aproximadamente, de un total de 31 millones de euros, que destinó al conjunto de las actividades vinculadas a los proyectos.

5.

La fiscalización del Tribunal perseguía principalmente evaluar la gestión por parte del BCE de los proyectos informáticos mediante la formulación de las dos preguntas de auditoría siguientes:

6.

La fiscalización consistió en una evaluación de las normas y procedimientos del BCE aplicables a las diferentes fases de gestión de los proyectos informáticos, así como en un examen de su ejecución.

7.

Con el fin de evaluar si el BCE había establecido un marco de gobernanza apropiado, el Tribunal tuvo en cuenta la totalidad de los principales documentos y procedimientos vinculados a la gestión de los proyectos informáticos. El documento más importante para la gestión de proyectos es el POCP (procedimientos relativos a la organización y al control de los proyectos) (6). A fin de apreciar la adecuación del marco de gobernanza para la informática, también se tomaron en consideración las normas y mejores prácticas internacionalmente reconocidas, como el documento PMBOK (7) (conjunto de conocimientos sobre la gestión del proyecto) del Instituto de gestión de proyectos (PMI) y los objetivos de control para la información y tecnologías afines (COBIT) del IT Governance Institute (Instituto de gobernanza en materia de informática).

8.

Con objeto de valorar si las normas y procedimientos se aplicaban según lo previsto a nivel del proyecto, se procedió al control detallado de seis proyectos informáticos. La fiscalización de los proyectos seleccionados se basó en entrevistas a los jefes de proyecto, los equipos del proyecto y los usuarios finales, así como en un examen de la documentación pertinente de los proyectos.

9.

Como base para la muestra se tomó la línea presupuestaria del BCE relativa a los «proyectos más importantes del BCE», que en el ejercicio 2007 abarcaba 16 grandes proyectos, 14 de los cuales pertenecían al terreno de la informática. La selección se basó en los criterios siguientes: i) tipo de proyecto, ii) presupuesto, y iii) fase de realización. En el anexo figura una breve descripción de cada proyecto, así como información sobre su duración y los costes correspondientes.

10.

Para la fiscalización del marco de gobernanza relativo a los proyectos informáticos, el Tribunal examinó si el BCE:

11.

La elaboración de una estrategia informática plurianual conforme a los fines y objetivos organizativos generales resulta indispensable para una utilización eficaz de los recursos. Esta estrategia debería formularse de modo que proporcione orientaciones para la planificación y realización de actividades informáticas durante varios años, permitiendo fijar los gastos informáticos en un nivel apropiado y concentrarlos en los ámbitos que más lo precisen. Asimismo, tendría que basarse en una evaluación global de las necesidades informáticas que permita tomar decisiones fundadas en cuanto a la priorización de los ámbitos de intervención.

12.

El Tribunal constató que el BCE no disponía de una estrategia informática plurianual que defina y presente sus fines estratégicos y los objetivos a medio plazo en materia de informática. Además, tampoco había llevado a cabo una evaluación global y formal de las necesidades para la priorización de los ámbitos de intervención con una perspectiva a medio plazo. Sin embargo, tanto la carta del presidente como las «orientaciones estratégicas y operativas» de las unidades de gestión sirven como base para determinar nuevos proyectos informáticos, que a continuación se clasifican por orden de prioridad en la actualización anual de la cartera de proyectos (véanse los apartados 19 a 21).

13.

En 2008, la Dirección General de Sistemas de Información (DG-SI) y la Dirección General de Recursos Humanos, Presupuesto y Organización (DG-H) iniciaron, en estrecha colaboración con las otras unidades de gestión del BCE, un examen estratégico de las actividades informáticas del banco. Este examen todavía no había finalizado cuando se llevó a cabo la fiscalización del Tribunal (primer trimestre de 2009). La primera fase del examen, que finalizó en diciembre de 2008, tenía como fin analizar en detalle los fines y objetivos de las unidades de gestión y llegar a conocer sus necesidades estratégicas de gestión en términos de nuevos sistemas, proyectos y servicios informáticos durante los cinco años siguientes (2009-2013), lo que debería conducir a la formulación de una estrategia informática para todas las funciones de la DG-SI (incluidos los proyectos informáticos).

14.

Todo ciclo de planificación anual de los proyectos informáticos requiere la formulación de objetivos anuales, la definición de las acciones que deben ejecutarse para alcanzarlos y el establecimiento de indicadores claves de resultados (ICR) para medir los resultados.

15.

En 2007, la DG-SI elaboró un documento relativo a las orientaciones estratégicas y operativas para 2007 que exponía varios objetivos generales, algunos de los cuales vinculados a la gestión de proyectos informáticos (8). Sin embargo, estos no se plasmaron en objetivos y acciones específicos, como tampoco se definieron los resultados previstos.

16.

En 2008, la DG-SI elaboró dos documentos de planificación: las «orientaciones estratégicas y operativas para 2008», de carácter genérico, y un «programa de trabajo relativo a 2008». Estas orientaciones estratégicas y operativas se recogen en un documento que incluye una sección donde se sintetizan los principales retos de la DG-SI para 2008, así como una visión general de los objetivos e indicadores claves de resultados con respecto a ese mismo año. Algunos de estos objetivos se referían a la gestión de los proyectos informáticos (9) y su logro debía medirse mediante indicadores claves de resultados específicos y cuantificables para los que se fijaron metas que alcanzar en el segundo y cuarto trimestres de 2008.

17.

El programa de trabajo de 2008 era más detallado y definía las acciones que debían llevarse a cabo para lograr cada uno de estos objetivos. Esta evolución positiva refuerza el proceso de planificación y representa una mejora de la situación con respecto a 2007. Se observó, no obstante, que el programa de trabajo de 2008 contenía un número de objetivos considerablemente más importante que el que figuraba en el documento relativo a las orientaciones estratégicas y operativas para 2008. El programa de trabajo no se estableció con miras a desarrollar los objetivos fijados en estas últimas, ni con el fin de precisar los medios que permitirían alcanzarlos, como tampoco para introducir nuevos objetivos.

18.

Por último, ninguno de los documentos de planificación de 2008 es lo suficientemente detallado para que resulte eficaz. Además, no se indican los recursos financieros necesarios para poder alcanzar cada objetivo y ejecutar las acciones seleccionadas.

19.

Los recursos disponibles no eran suficientes para financiar la totalidad de posibles proyectos cada año, lo que hacía necesario establecer un proceso de selección de los proyectos de mayor prioridad que permita garantizar la mejor utilización de estos recursos.

20.

El proceso de priorización y selección de proyectos de 2007 se basaba en un plan de cartera de proyectos a medio plazo trienal. Cada año el BCE revalúa, en función de sus objetivos generales, el conjunto de los proyectos (en curso, registrados en el sistema de proyectos aunque todavía no iniciados y recientemente registrados). Este plan a medio plazo se actualiza dos veces al año con el fin de tener en cuenta los nuevos proyectos registrados y otros cambios. La evaluación de los proyectos se basa en la presentación de expedientes que justifican su viabilidad (project business cases) y en la estimación de los recursos necesarios para su realización. La falta de criterios de priorización claros menoscaba la objetividad en la selección de proyectos, aumentando el riesgo de que los recursos disponibles no se utilicen de forma óptima.

21.

En 2008 se introdujo un método de priorización de los proyectos más eficaz que se basaba en el «concepto de los tres pilares» (10) y consistía en evaluaciones específicas por dominio (11), que a continuación eran consolidadas en el BCE. El sistema de gestión de los proyectos informáticos establecido en 2008 proporcionaba información suficiente para la toma de decisiones.

22.

El BCE instauró procedimientos relativos a la organización y al control de los proyectos mediante el documento POCP, que deben ser respetados para la gestión de todos los proyectos, incluidos los informáticos (12). El POCP aporta una definición precisa de qué constituye un proyecto y delimita claramente su ámbito de aplicación, a la vez que determina la estructura organizativa que debe adoptarse para los proyectos, en particular las funciones y responsabilidades de las distintas entidades participantes.

23.

El ciclo de vida de un proyecto, tal y como se define en el POCP, permite disponer de una estructura de control eficaz de los proyectos, mediante la división de este ciclo en fases lógicas y el establecimiento de etapas precisas para la toma de decisiones (véase el gráfico 1 ). Al compararlo con el documento PMBOK, se constató que el POCP era en gran medida conforme a estas mejores prácticas. Sin embargo, dos ámbitos podrían ser objeto de mejora: el análisis de las partes interesadas y la evaluación a posteriori del impacto de los proyectos. Las insuficiencias existentes y su incidencia se exponen en los apartados siguientes.

24.

El documento POCP no exige un análisis formal y documentado de las partes interesadas, lo cual significa que el equipo del proyecto no está obligado a indicar formalmente las partes interesadas ni a determinar sus necesidades específicas en el marco del proyecto (13). La falta de indicación formal de todas las partes interesadas y de sus necesidades podría repercutir negativamente en el éxito de un proyecto. Cabe sin embargo observar que, en el caso de los proyectos examinados, se tuvieron en cuenta las necesidades de los usuarios (véanse los apartados 33 y 36).

25.

Si un proyecto lleva cierto tiempo operativo, no se prevé una evaluación a posteriori de sus resultados e impacto. Sin embargo, este tipo de evaluación proporcionaría, en particular, una apreciación formal sobre el logro de las ventajas cualitativas y cuantitativas previstas que se exponen en el documento de aprobación del proyecto y, de este modo, facilitaría la planificación de futuros proyectos (véase el apartado 53). El nuevo modelo, que exige que los usuarios finales comuniquen anualmente sus reacciones sobre los proyectos informáticos con el fin de analizar su nivel de satisfacción acerca de la calidad de los servicios prestados, ha constituido una evolución positiva en este ámbito.

26.

Con el fin de garantizar la ejecución eficiente y eficaz de los proyectos es necesario establecer un marco de gestión que defina claramente la relación de jerarquía y las responsabilidades de los órganos y funciones participantes en el proceso.

27.

El documento POCP aborda la estructura organizativa que debe adoptarse para la gestión de los proyectos del BCE, en particular las competencias y responsabilidades, así como la composición de las entidades participantes competentes (véase el gráfico 2 ).

28.

El documento POCP fija claramente la relación de jerarquía entre los órganos y funciones participantes en el proceso de gestión de los proyectos. El comité de dirección del proyecto constituye el principal órgano decisorio interno del BCE para la priorización, planificación, aprobación y seguimiento de los proyectos. La estructura creada por el POCP abarca todas las funciones necesarias y prevé procedimientos decisorios claros, con competencias y responsabilidades predefinidas.

29.

A raíz del control de la aplicación del marco de gobernanza para los proyectos informáticos, el Tribunal examinó si el BCE:

30.

La planificación de un proyecto es adecuada cuando se abordan los siguientes elementos: i) los objetivos y alcance generales del proyecto, ii) la solución propuesta, iii) las etapas esenciales y los resultados del proyecto, iv) los recursos humanos y financieros, y v) el equipo del proyecto.

31.

El documento de presentación del proyecto (PSD) constituye el principal documento de planificación (véase el gráfico 1 ) y sirve como base para decidir la puesta en práctica de la solución seleccionada. En el caso de los seis proyectos examinados, los documentos abarcaban un amplio contenido y abordaban las principales cuestiones que deben tenerse presentes al aprobarse un proyecto.

32.

Todos los proyectos se autorizaron con arreglo a los procedimientos previstos en el documento POCP. Antes de cada una de las tres fases de un proyecto (14), el comité de dirección correspondiente toma la decisión formal de proseguir con este. Tres proyectos (15) se consideraron indispensables para garantizar la conformidad con las normas SEBC y con otras normas vigentes, mientras que los demás (16) se seleccionaron sobre la base de un método de priorización. Todos los proyectos respetaban las orientaciones estratégicas y operativas de la DG-SI o las estrategias generales de las unidades de gestión.

33.

En tres de los proyectos (17) examinados, las necesidades de los usuarios se evaluaron y documentaron en la fase de planificación. Dado que en los otros tres se trataba únicamente de una ampliación de una red establecida (TCERTO) o de una actualización de una infraestructura existente (EER y MAU), los usuarios no participaron en la fase de planificación. En el proyecto MPIDS, sus especificaciones se elaboraron siguiendo un enfoque de pruebas iterativas, que al no haberse aplicado de forma óptima provocó retrasos; además, las versiones experimentales no eran tan elaboradas como se esperaba.

34.

Los riesgos de que no se alcancen los objetivos de un proyecto deberían determinarse con un nivel de precisión suficiente, y tendrían que estructurarse y evaluarse en profundidad durante la fase de planificación desde el punto de vista de su probable materialización e impacto potencial en el logro de los objetivos del proyecto.

35.

Se reserva una sección específica al análisis de riesgos en los modelos para cada uno de los tres documentos de planificación (18), sección que se completó en todos los documentos de presentación de proyectos. Sin embargo, no existía un enfoque común para la determinación de los riesgos a los que se exponían los proyectos, ni para la evaluación de su probable materialización e impacto. La evaluación se basaba en la propia experiencia de cada jefe de proyecto. En el marco del proyecto MDP la evaluación inicial del riesgo solo tuvo en cuenta los riesgos vinculados a los contratistas externos. Durante la ejecución del proyecto se materializaron además los riesgos internos, como las limitaciones financieras. Dado que estos factores no fueron considerados como riesgos, no se previó ninguna medida correctora en la fase de planificación. En el caso del proyecto MPIDS también habrían podido preverse otros riesgos, como los derivados de la complejidad de los procesos de gestión dentro del alcance del proyecto, pero estos no se indicaron en el documento de presentación del proyecto.

36.

En tres de los proyectos (19) examinados, los recursos y capacidades asignados a su ejecución eran suficientes. Los tres restantes, en cambio, se vieron confrontados a un problema de falta de suficientes recursos especializados en el momento requerido. En el caso del proyecto MDP, los usuarios no siempre se encontraban disponibles a raíz de que también debía concluirse un proyecto similar durante el mismo período. Ello condujo a retrasos en la ejecución del proyecto. En el proyecto MPIDS, el equipo no contó con un analista comercial y no siempre era posible recurrir al personal de la DG-SI en caso de necesidad. La contratación pública de un promotor externo originó un retraso de tres meses. Una vez contratado, el promotor fue sustituido con frecuencia, lo que acarreó problemas de ejecución del proyecto. Así, debido a su complejidad, este se ejecutó en varias fases (20). La transferencia de conocimientos entre la segunda y la tercera fase no tuvo lugar según lo previsto, ya que la mayor parte de los principales miembros del equipo del proyecto anterior, incluido el jefe de proyecto, no participaron en la tercera fase.

37.

En todos los proyectos seleccionados, los usuarios fueron regularmente informados durante su ejecución. Además, en la mayor parte de ellos, los usuarios estuvieron representados en el grupo de dirección o en las reuniones del equipo del proyecto, y también tuvieron acceso a los informes mensuales de situación.

38.

En el proyecto MDP se hizo una excepción a las normas de adjudicación de contratos públicos del BCE ateniéndose a que esta adjudicación no podía disociarse de la anterior elección de un proveedor de datos. Sin embargo, el desarrollo y apoyo de programas informáticos no constituían la actividad principal de este proveedor, problema que encareció, superando las previsiones, los aspectos de elaboración de la versión de mantenimiento.

39.

La comprobación de un resultado informático nuevo o modificado forma parte de los procedimientos del BCE, y debe llevarse a cabo antes de que cada resultado pase a ser operativo. Los seis proyectos se comprobaron antes de su lanzamiento. El equipo del proyecto se encargó de la concepción de las pruebas, en la que no siempre participaron los usuarios finales y, por consiguiente, las mejoras necesarias no se señalaron a tiempo.

40.

Los jefes de proyecto deben disponer de información suficiente y fiable que permita garantizar un seguimiento eficaz de los proyectos durante su ejecución, así como la detección y resolución de los problemas a su debido tiempo.

41.

El BCE utiliza distintos instrumentos para el seguimiento de sus proyectos informáticos. El tiempo dedicado a un proyecto, junto con los datos financieros y la información relativa a las principales realizaciones y avances, se exponen en los informes mensuales de situación del proyecto. Así, durante la ejecución de los seis proyectos examinados se presentaron regularmente este tipo de informes, que contenían información suficiente. Se observó sin embargo que, en el caso del proyecto PCU Target 2, ciertos informes no pudieron ser elaborados por falta de efectivos.

42.

Pese a ello, solo se contabiliza el tiempo dedicado a los proyectos por el personal de la DG-SI. El tiempo empleado por los agentes de las unidades de gestión y por el personal de los bancos centrales nacionales solo es objeto de estimación. Además, no suelen contabilizarse las horas extraordinarias, o solo de forma no sistemática. Por consiguiente, el seguimiento no puede basarse en información completa y exacta con respecto al tiempo empleado.

43.

Al término de un proyecto debería llevarse a cabo una evaluación formal del logro de sus objetivos y de los recursos utilizados. El documento POCP prevé la elaboración de un documento de fin de proyecto (PCR) una vez que haya sido posible obtener el conjunto de resultados de la fase de ejecución y que el producto final del proyecto haya sido aceptado por la unidad o unidades de gestión correspondientes, por el responsable del sistema y por la división de operaciones de la DG-SI. El PCR constituye por tanto el documento mediante el cual se aprueba el cierre formal de un proyecto.

44.

Este documento, destinado a ser muy completo, aborda los aspectos esenciales que deben tenerse en cuenta en el momento del cierre de un proyecto y se compone principalmente de las secciones siguientes:

45.

A 15 de abril de 2009 se había emitido y aprobado un documento de fin de proyecto en cinco de los seis proyectos examinados (véase el anexo ). Con arreglo al documento POCP, generalmente un proyecto deberá finalizarse en un plazo de tres meses a partir la aceptación de sus resultados finales. En el caso del proyecto PCU Target 2, las operaciones se iniciaron en mayo de 2008 y el proyecto llegó a su término el 15 de abril de 2009, debido a que la DG-SI y el responsable del sistema no conseguían convenir en el contenido del acuerdo sobre el nivel de servicio (ANS). En su reunión de octubre de 2007, el grupo de dirección había indicado que este acuerdo debía adoptarse antes de la puesta en marcha del proyecto PCU Target 2 y que era conveniente comenzar lo antes posible, ya que la presentación clara de las expectativas y de los servicios, así como la comunicación entre la división de las operaciones y los distintos usuarios son elementos esenciales. Del mismo modo, en el caso del proyecto MPIDS no se procedió al cierre de este proyecto al retrasarse considerablemente la firma del acuerdo sobre el nivel de servicio.

46.

Al cierre del proyecto habría que llevar a cabo una evaluación de sus resultados efectivos con respecto al alcance y objetivos aprobados. Esta evaluación debe abarcar las etapas esenciales y los principales resultados del proyecto, y proporcionar también una justificación de cualquier disparidad significativa.

47.

El Tribunal examinó las evaluaciones efectuadas para cada uno de los cuatro proyectos que habían sido objeto de un documento de fin de proyecto adoptado a finales de marzo de 2009 a más tardar. Estas evaluaciones permitían comparar el plan inicial del documento de presentación del proyecto con las realizaciones. Así, abordaban las etapas esenciales y los resultados previstos, y proporcionaban explicaciones en caso de disparidad significativa. Sin embargo, se observó que dos de los proyectos (21) sufrieron retrasos con respecto al plan inicial (véase el anexo ). Los dos principales motivos que se adujeron consistían en:

48.

En el caso del proyecto MAU, aunque las infraestructuras técnicas se encontraban aparentemente disponibles y en funcionamiento mucho antes de la fecha indicada en el documento de fin de proyecto, la aceptación y traspaso formales se retrasaron seis meses.

49.

En el documento de fin de proyecto es preciso efectuar una comparación entre los recursos humanos y financieros previstos y los efectivamente utilizados. El documento de fin de proyecto de los cuatro proyectos mencionados incluía este tipo de comparación, así como una explicación de las disparidades más significativas.

50.

Los recursos humanos y financieros efectivamente utilizados para cada uno de los cuatro proyectos eran inferiores a los presupuestados. Los gastos reales oscilaban entre un 3 % y un 23 % por debajo del presupuesto (véase el anexo ). Se alegaron varias razones, específicas a los proyectos, que justificaban esta infrautilización.

51.

La cuestión de la infrautilización presupuestaria en los proyectos también fue planteada por el comité presupuestario del BCE en su informe de evaluación acerca del informe de final de ejercicio del BCE sobre el seguimiento presupuestario relativo a 2008, en el que se exponía que el comité constató una infrautilización de 18 millones de euros (28,8 %). El comité consideraba que ello se debía principalmente a los retrasos en algunos proyectos, y que era posible mejorar su planificación y ejecución. El Tribunal observó que se produjeron demoras en la ejecución de los proyectos (véase el anexo ), que efectivamente repercuten en la ejecución presupuestaria. Teniendo en cuenta, no obstante, que los recursos previstos en el plan inicial superaban las necesidades, cabe inferir que los presupuestos iniciales no se establecen con la debida precisión. A raíz de ello se comprometen recursos presupuestarios que dejan de estar disponibles para proyectos más avanzados.

52.

Al cierre del proyecto se lleva a cabo una evaluación de las ventajas cualitativas y cuantitativas que se espera obtener durante la explotación del producto final. Resulta necesario explicar las disparidades con respecto a la información facilitada en el documento de presentación del proyecto y que, por tanto, se empleó durante el procedimiento de priorización y selección de los proyectos.

53.

Para los cuatro proyectos, el documento de fin de proyecto indicaba que las ventajas mencionadas en el documento de presentación del proyecto seguían siendo válidas o se habían obtenido. Sin embargo, varias de estas ventajas sólo pueden evaluarse correctamente tras un período de funcionamiento (véase el apartado 25).

54.

En el caso del MDP, el proyecto no se limitó a confirmar la evaluación inicial que figuraba en su documento de presentación, sino que además se procedió a otra evaluación con una metodología diferente. Las ventajas del producto final fueron evaluadas con relación a las cuatro dimensiones establecidas en un cuadro de mando integral (balanced scorecard), que abarcaba indicadores positivos y negativos. Por tanto, su fin consistía en llevar a cabo una evaluación equitativa de los efectos del proyecto, lo cual constituía una iniciativa positiva que podía considerarse una buena práctica para futuros proyectos. En el recuadro 1 se presentan extractos de esta evaluación:

—

Finanzas: (positiva) el proyecto se ha ejecutado dentro de los límites del presupuesto; (negativa) los honorarios de los asesores en concepto del desarrollo de la solución se estiman superiores a los precios de mercado.

—

Innovación: (positiva) el proyecto ha contribuido al desarrollo de un sistema de seguimiento que respalda el acuerdo sobre el nivel de servicio; (negativa) el proyecto ha dado lugar a la introducción de una nueva base de datos propia a la organización, cuya utilización resultaba bastante compleja y no era tan flexible como las que ya estaban en servicio.

—

Organización: (positiva) el proyecto ha contribuido al establecimiento de políticas sobre el uso de datos de mercado.

—

Usuarios: (positiva) el proyecto ha permitido la integración de datos Bloomberg; (negativa) se ha considerado que las posibilidades de utilización de la solución no estaban a la altura de las expectativas.

55.

Según el documento POCP, debe presentarse en anexo al documento de fin de proyecto un informe sobre la experiencia adquirida. Su fin consiste en garantizar que la experiencia en la ejecución de un proyecto específico se encuentre a disposición de la organización en su conjunto para poder mejorar la gestión de futuros proyectos.

56.

En los cuatro documentos de fin de proyecto se adjuntó un informe sobre la experiencia adquirida, cuyo nivel de contenido no era uniforme. En el caso del proyecto EER, la mención de los aspectos abordados como experiencias adquiridas parecía destinada a mostrar una gestión eficaz, más que a indicar cómo mejorar la gestión en el futuro. Con respecto al proyecto MAU, una excesiva precisión restó claridad al contenido de la experiencia adquirida para futuros proyectos.

57.

Tanto en el caso de los proyectos MDP como TCERTO, se pusieron de manifiesto aspectos que indudablemente serán relevantes para los procedimientos de gestión de proyectos del BCE. El recuadro 2 presenta extractos de los aspectos mencionados en el informe del proyecto MDP:

—

Hacer hincapié en la importancia de la fase de elaboración, en particular en la determinación de las necesidades de los usuarios. Se sugiere que de ahora en adelante se otorgue mayor responsabilidad al usuario final en la decisión acerca de qué solución elegir.

—

Subrayar la importancia de la participación y obligación de rendir cuentas del usuario: sin una responsabilidad claramente definida, el usuario puede no ser plenamente consciente de la importancia de su participación en la concepción y verificación de la solución.

—

Poner de relieve la importancia de la verificación de los resultados en cada fase.

—

Planificar los recursos en función de la priorización de los proyectos: el proyecto adoleció de una falta de recursos durante cada fase de prueba, debido a una disparidad con otro resultado en la misma unidad de gestión.

—

Considerar el portal de un proyecto como una herramienta eficaz de intercambio de conocimientos: resultó de gran utilidad el punto de acceso central, y de fácil utilización, a toda la información del proyecto.

58.

Por último, aunque otros jefes de proyecto puedan tener conocimiento de las experiencias adquiridas consultando los documentos de fin de proyecto, las cuestiones que se consideraban de interés para el conjunto de la organización, y que eran susceptibles de reforzar el intercambio de experiencias entre jefes de proyecto, no se pusieron de manifiesto ni se divulgaron activamente.

59.

El BCE ha establecido un marco de gobernanza para la gestión de sus proyectos informáticos; sin embargo, este todavía es susceptible de mejora.

60.

El BCE no ha puesto en práctica una estrategia informática plurianual que defina formalmente sus fines estratégicos y sus objetivos a medio plazo, si bien en 2008 inició un examen estratégico de sus actividades informáticas, que debería desembocar en la formulación de una estrategia informática.

61.

A diferencia de los proyectos informáticos del BCE, en cuyo caso sí se estimaron los recursos financieros, los documentos de planificación anual de la Dirección General de Sistemas de Información no proporcionaban precisión alguna con respecto a los recursos financieros necesarios para alcanzar sus objetivos y ejecutar las acciones seleccionadas.

62.

En 2008, el BCE mejoró su proceso de selección de proyectos al facilitar información suficiente sobre las decisiones que deben adoptarse.

63.

Los procedimientos de gestión de proyectos informáticos del BCE resultan en gran medida conformes a las mejores prácticas, pero se constataron insuficiencias en los ámbitos de análisis de las partes interesadas y de evaluación a posteriori del impacto de los proyectos.

1.

El BCE debería establecer formalmente una estrategia informática plurianual susceptible de constituir una herramienta eficaz para la gestión de sus actividades informáticas.

2.

El BCE debería seguir desarrollando su planificación anual en materia de informática mediante la elaboración de un documento exhaustivo en el que se fijen los objetivos y se definan los indicadores de resultados destinados a medir su consecución. Los objetivos tendrían que desglosarse en acciones específicas, indicando los recursos financieros necesarios para su logro.

3.

El BCE debería incluir, en sus procedimientos de gestión de proyecto, el análisis de las partes interesadas y la evaluación a posteriori del impacto de los proyectos.

64.

Globalmente, el BCE aplicó según lo previsto el marco de gobernanza establecido para la gestión de los proyectos informáticos. Todos los proyectos fiscalizados fueron debidamente autorizados, en la fase de planificación, mediante la aprobación de su documento de presentación. Sin embargo, se constataron insuficiencias en la evaluación de los riesgos relativos a los proyectos a raíz de una falta de precisión y de la inexistencia de un enfoque común. Además, los presupuestos fijados en los planes iniciales no eran tan detallados como cabía esperar.

65.

El Tribunal constató que, durante su ejecución, tres proyectos se habían visto afectados por una falta de recursos especializados que ocasionó retrasos.

66.

En términos generales, el BCE implantó herramientas y sistemas de información de gestión apropiados para el seguimiento de sus proyectos informáticos. No obstante, la utilización de los recursos humanos destinados a los proyectos informáticos solo es objeto de un seguimiento parcial.

67.

En la fase de finalización se efectúa una evaluación formal en el documento de fin de proyecto que comprende los principales aspectos que deben abordarse en esta fase. Sin embargo, de los seis proyectos, solo uno fue finalizado en el plazo previsto en el documento de presentación del proyecto.

68.

El Tribunal realiza las recomendaciones siguientes:

Recomendaciones (segunda pregunta de auditoría)