# Dziennik Urzędowy C 32/2010

| | ISSN 1725-5228
  doi:10.3000/17255228.C_2010.032.pol |
| --- | --- |
| Dziennik Urzędowy
  Unii Europejskiej | C 32 |
| | |
| Wydanie polskie | Informacje i zawiadomienia | Tom 539 lutego 2010 |

ISSN 1725-5228

doi:10.3000/17255228.C_2010.032.pol

Dziennik Urzędowy

Unii Europejskiej

C 32

Wydanie polskie

Informacje i zawiadomienia

Tom 539 lutego 2010

---

| Powiadomienie nr | Spis treśći | Strona |
| --- | --- | --- |
| | IV   Informacje |
| | INFORMACJE INSTYTUCJI, ORGANÓW I JEDNOSTEK ORGANIZACYJNYCH UNII EUROPEJSKIEJ |
| | Trybunał Obrachunkowy |
| 2010/C 032/01 | Sprawozdanie z kontroli skuteczności zarządzania Europejskim Bankiem Centralnym w roku budżetowym 2007 wraz z odpowiedziami Europejskiego Banku Centralnego | 1 |

Powiadomienie nr

Spis treśći

Strona

IV   Informacje

INFORMACJE INSTYTUCJI, ORGANÓW I JEDNOSTEK ORGANIZACYJNYCH UNII EUROPEJSKIEJ

Trybunał Obrachunkowy

2010/C 032/01

Sprawozdanie z kontroli skuteczności zarządzania Europejskim Bankiem Centralnym w roku budżetowym 2007 wraz z odpowiedziami Europejskiego Banku Centralnego

1

| PL | |
| --- | --- |

PL

---

IV Informacje

INFORMACJE INSTYTUCJI, ORGANÓW I JEDNOSTEK ORGANIZACYJNYCH UNII EUROPEJSKIEJ

Trybunał Obrachunkowy

| 9.2.2010 | PL | Dziennik Urzędowy Unii Europejskiej | C 32/1 |
| --- | --- | --- | --- |

9.2.2010

PL

Dziennik Urzędowy Unii Europejskiej

C 32/1

---

Sprawozdanie z kontroli skuteczności zarządzania Europejskim Bankiem Centralnym w roku budżetowym 2007 wraz z odpowiedziami Europejskiego Banku Centralnego

2010/C 32/01

SPIS TREŚCI

Lista skrótów i glosariusz

Wprowadzenie

Zakres kontroli i podejście kontrolne

Uwagi

Czy EBC posiadał stosowny system zarządzania realizowanymi przez siebie projektami IT?

Czy EBC posiadał wieloletnią strategię IT powiązaną z ogólnymi celami organizacyjnymi?

Czy EBC planował swoje działania związane z projektami IT w cyklu rocznym?

Czy w procesie wyboru projektów IT do realizacji stosowano rzetelne kryteria?

Czy ustanowiono stosowne procedury zarządzania projektami IT?

Czy ustalony system zarządzania projektami IT był stosowany zgodnie z założeniami?

Czy poszczególne projekty były stosownie planowane?

Czy projekty były odpowiednio realizowane?

Czy projekty były odpowiednio monitorowane?

Czy na zakończenie projektów dokonywano ich formalnej oceny?

Wnioski i zalecenia

Czy EBC posiadał stosowny system zarządzania realizowanymi przez siebie projektami IT?

Czy ustalony system zarządzania projektami IT był stosowany zgodnie z założeniami?

Załącznik – Zestawienie projektów zbadanych przez Europejski Trybunał Obrachunkowy

LISTA SKRÓTÓW I GLOSARIUSZ

| COBIT | Control Objectives for Information and related Technology (Cele kontroli w zakresie technologii informacyjnych i powiązanych) |
| --- | --- |
| DG-H | Dyrekcja Generalna Kadr, Budżetu i Organizacji |
| DG-IS | Dyrekcja Generalna Systemów Informatycznych |
| EBC | Europejski Bank Centralny |
| EER | Projekt ECBLAN Eurotower Refresh |
| ESBC | Europejski System Banków Centralnych |
| IT | Technologia informacyjna |
| KPI | Kluczowy wskaźnik wykonania (z ang. Key Performance Indicator) |
| MAU | Projekt Main computer rooms Area Upgrade at the Eurotower building |
| MDP | Projekt Market Data Provision |
| MPIDS | Projekt Monetary Policy Implementation Decision support System |
| PCR | Sprawozdanie z zamknięcia projektu |
| PMBOK | Project Management Body of Knowledge (Korpus wiedzy w zakresie zarządzania projektami) |
| PMI | Project Management Institute (Instytut Zarządzania Projektami) |
| POCP | Project Organisation and Control Procedures (Procedury organizacji i kontroli projektu) |
| PSD | Dokument przedłożenia projektu |
| PSG | Grupa sterująca projektu |
| PSR | Sprawozdanie z postępów w realizacji projektu |
| SLA | Umowa o gwarantowanym poziomie usług (z ang. Service Level Agreement) |
| Target 2 SSP | Projekt Target 2 Single Shared Platform |
| TCERTO | Projekt Teleconference, CoreNet, ESCB-Net enlargement to Bulgaria and Romania |

COBIT

Control Objectives for Information and related Technology (Cele kontroli w zakresie technologii informacyjnych i powiązanych)

DG-H

Dyrekcja Generalna Kadr, Budżetu i Organizacji

DG-IS

Dyrekcja Generalna Systemów Informatycznych

EBC

Europejski Bank Centralny

EER

Projekt ECBLAN Eurotower Refresh

ESBC

Europejski System Banków Centralnych

IT

Technologia informacyjna

KPI

Kluczowy wskaźnik wykonania (z ang. Key Performance Indicator)

MAU

Projekt Main computer rooms Area Upgrade at the Eurotower building

MDP

Projekt Market Data Provision

MPIDS

Projekt Monetary Policy Implementation Decision support System

PCR

Sprawozdanie z zamknięcia projektu

PMBOK

Project Management Body of Knowledge (Korpus wiedzy w zakresie zarządzania projektami)

PMI

Project Management Institute (Instytut Zarządzania Projektami)

POCP

Project Organisation and Control Procedures (Procedury organizacji i kontroli projektu)

PSD

Dokument przedłożenia projektu

PSG

Grupa sterująca projektu

PSR

Sprawozdanie z postępów w realizacji projektu

SLA

Umowa o gwarantowanym poziomie usług (z ang. Service Level Agreement)

Target 2 SSP

Projekt Target 2 Single Shared Platform

TCERTO

Projekt Teleconference, CoreNet, ESCB-Net enlargement to Bulgaria and Romania

WPROWADZENIE

| 1. | Europejski Bank Centralny (EBC – „bank”) wraz z krajowymi bankami centralnymi wszystkich państw członkowskich UE tworzą Europejski System Banków Centralnych (ESBC). Głównym celem ESBC jest utrzymanie stabilności cen. ESBC wspiera także ogólne polityki gospodarcze w Unii, mając na względzie przyczynianie się do osiągnięcia celów Unii (1). W związku z tym EBC wykonuje zadania określone w statucie (2) i odpowiada za zarządzanie swoją działalnością i finansami. |
| --- | --- |

1.

Europejski Bank Centralny (EBC – „bank”) wraz z krajowymi bankami centralnymi wszystkich państw członkowskich UE tworzą Europejski System Banków Centralnych (ESBC). Głównym celem ESBC jest utrzymanie stabilności cen. ESBC wspiera także ogólne polityki gospodarcze w Unii, mając na względzie przyczynianie się do osiągnięcia celów Unii (1). W związku z tym EBC wykonuje zadania określone w statucie (2) i odpowiada za zarządzanie swoją działalnością i finansami.

| 2. | Podstawę przeprowadzania przez Trybunał kontroli skuteczności zarządzania EBC stanowi art. 27 ust. 2 Protokołu w sprawie Statutu ESBC i EBC (3). Przedmiotem kontroli było zarządzanie przez EBC projektami IT w latach budżetowych 2007 i 2008. Uwzględniono także zmiany w praktykach EBC wprowadzone w pierwszym kwartale 2009 r. |
| --- | --- |

2.

Podstawę przeprowadzania przez Trybunał kontroli skuteczności zarządzania EBC stanowi art. 27 ust. 2 Protokołu w sprawie Statutu ESBC i EBC (3). Przedmiotem kontroli było zarządzanie przez EBC projektami IT w latach budżetowych 2007 i 2008. Uwzględniono także zmiany w praktykach EBC wprowadzone w pierwszym kwartale 2009 r.

| 3. | Budżet EBC podzielony jest na dwie główne części: działania dotyczące „działalności bieżącej” (wydatki operacyjne w ramach obszarów działalności dyrekcji EBC (4) oraz działania dotyczące „działalności rozwojowej”. Ta druga część składa się z dwóch podstawowych grup działalności:






  i) | działalności projektowej, obejmującej duże projekty EBC i ESBC, inne projekty, małe działania rozwojowe i scentralizowane inwestycje IT; oraz |
| --- | --- | --- |

3.

Budżet EBC podzielony jest na dwie główne części: działania dotyczące „działalności bieżącej” (wydatki operacyjne w ramach obszarów działalności dyrekcji EBC (4) oraz działania dotyczące „działalności rozwojowej”. Ta druga część składa się z dwóch podstawowych grup działalności:

i)

działalności projektowej, obejmującej duże projekty EBC i ESBC, inne projekty, małe działania rozwojowe i scentralizowane inwestycje IT; oraz

| ii) | działalności związanej z banknotami, obejmującej przede wszystkim badania i rozwój w tym zakresie. |
| --- | --- |

ii)

działalności związanej z banknotami, obejmującej przede wszystkim badania i rozwój w tym zakresie.

| 4. | Wydatki EBC na projekty IT (5) w 2007 r. wyniosły w przybliżeniu 20 mln euro z ogólnej kwoty 31 mln euro wydanej przez EBC na wszystkie działania projektowe. |
| --- | --- |

4.

Wydatki EBC na projekty IT (5) w 2007 r. wyniosły w przybliżeniu 20 mln euro z ogólnej kwoty 31 mln euro wydanej przez EBC na wszystkie działania projektowe.

ZAKRES KONTROLI I PODEJŚCIE KONTROLNE

| 5. | Głównym celem przeprowadzonej przez Trybunał kontroli była ocena zarządzania przez EBC projektami IT, na podstawie odpowiedzi na dwa następujące pytania:






  — | Czy EBC posiadał stosowny system zarządzania realizowanymi przez siebie projektami IT? |
| --- | --- | --- |

5.

Głównym celem przeprowadzonej przez Trybunał kontroli była ocena zarządzania przez EBC projektami IT, na podstawie odpowiedzi na dwa następujące pytania:

—

Czy EBC posiadał stosowny system zarządzania realizowanymi przez siebie projektami IT?

| — | Czy ustanowiony system zarządzania projektami IT był stosowany zgodnie z założeniami? |
| --- | --- |

—

Czy ustanowiony system zarządzania projektami IT był stosowany zgodnie z założeniami?

| 6. | Kontrola objęła ocenę przepisów i procedur EBC mających zastosowanie do poszczególnych etapów zarządzania projektami IT, jak również badanie ich stosowania. |
| --- | --- |

6.

Kontrola objęła ocenę przepisów i procedur EBC mających zastosowanie do poszczególnych etapów zarządzania projektami IT, jak również badanie ich stosowania.

| 7. | Przeprowadzona przez Trybunał ocena dotycząca ustanowienia przez EBC stosownego systemu zarządzania obejmowała badanie wszystkich głównych dokumentów i procedur związanych z zarządzaniem projektami IT. Podstawowym dokumentem stosowanym przy zarządzaniu projektami są „Procedury organizacji i kontroli projektu” (Project Organisation and Control Procedures) (POCP) (6). Przy ocenie stosowności systemu zarządzania projektami IT uwzględniono również uznane międzynarodowe standardy i najlepsze praktyki, takie jak Project Management Body of Knowledge (PMBOK (7) wydane przez Project Management Institute (PMI) oraz Control Objectives for Information and Related Technology (COBIT) wydane przez IT Governance Institute. |
| --- | --- |

7.

Przeprowadzona przez Trybunał ocena dotycząca ustanowienia przez EBC stosownego systemu zarządzania obejmowała badanie wszystkich głównych dokumentów i procedur związanych z zarządzaniem projektami IT. Podstawowym dokumentem stosowanym przy zarządzaniu projektami są „Procedury organizacji i kontroli projektu” (Project Organisation and Control Procedures) (POCP) (6). Przy ocenie stosowności systemu zarządzania projektami IT uwzględniono również uznane międzynarodowe standardy i najlepsze praktyki, takie jak Project Management Body of Knowledge (PMBOK (7) wydane przez Project Management Institute (PMI) oraz Control Objectives for Information and Related Technology (COBIT) wydane przez IT Governance Institute.

| 8. | Aby ocenić, czy przepisy i procedury były stosowane na poziomie projektu zgodnie z założeniami, przeprowadzono szczegółową kontrolę sześciu projektów IT. Kontrola wybranych projektów oparta była na wywiadach z kierownikami projektów, zespołami projektowymi oraz użytkownikami końcowymi, a także na badaniu stosownej dokumentacji projektowej. |
| --- | --- |

8.

Aby ocenić, czy przepisy i procedury były stosowane na poziomie projektu zgodnie z założeniami, przeprowadzono szczegółową kontrolę sześciu projektów IT. Kontrola wybranych projektów oparta była na wywiadach z kierownikami projektów, zespołami projektowymi oraz użytkownikami końcowymi, a także na badaniu stosownej dokumentacji projektowej.

| 9. | Podstawą dla próby była linia budżetu EBC dotycząca dużych projektów EBC. W roku budżetowym 2007 obejmowała ona 16 dużych projektów, z których 14 związanych było z IT. Wyboru dokonano na podstawie następujących kryteriów: (i) rodzaj projektu; (ii) jego budżet; i (iii) stan jego realizacji. Skrócony opis każdego projektu wraz z informacjami na temat jego trwania i kosztów przedstawiono w
  załączniku
  . |
| --- | --- |

9.

Podstawą dla próby była linia budżetu EBC dotycząca dużych projektów EBC. W roku budżetowym 2007 obejmowała ona 16 dużych projektów, z których 14 związanych było z IT. Wyboru dokonano na podstawie następujących kryteriów: (i) rodzaj projektu; (ii) jego budżet; i (iii) stan jego realizacji. Skrócony opis każdego projektu wraz z informacjami na temat jego trwania i kosztów przedstawiono w
  załączniku
  .

UWAGI

Czy EBC posiadał stosowny system zarządzania realizowanymi przez siebie projektami IT?

| 10. | W ramach kontroli systemu zarządzania projektami IT Trybunał zbadał, czy EBC:






  — | posiadał wieloletnią strategię IT powiązaną z ogólnymi celami organizacyjnymi; |
| --- | --- | --- |

10.

W ramach kontroli systemu zarządzania projektami IT Trybunał zbadał, czy EBC:

—

posiadał wieloletnią strategię IT powiązaną z ogólnymi celami organizacyjnymi;

| — | skutecznie planował swoje działania związane z projektami IT w cyklu rocznym; |
| --- | --- |

—

skutecznie planował swoje działania związane z projektami IT w cyklu rocznym;

| — | stosował rzetelne kryteria wyboru do realizacji projektów IT; oraz |
| --- | --- |

—

stosował rzetelne kryteria wyboru do realizacji projektów IT; oraz

| — | ustanowił stosowne procedury zarządzania projektami IT. |
| --- | --- |

—

ustanowił stosowne procedury zarządzania projektami IT.

Czy EBC posiadał wieloletnią strategię IT powiązaną z ogólnymi celami organizacyjnymi?

| 11. | Aby skutecznie wykorzystać zasoby, należy określić wieloletnią strategię IT powiązaną z ogólnymi celami organizacyjnymi. Strategia ta powinna być sformułowana w taki sposób, by stanowić podstawę planowania i podejmowania działań w zakresie IT w okresie kilku lat i umożliwiać określenie wydatków na odpowiednim poziomie oraz skoncentrowanie ich tam, gdzie są najbardziej potrzebne. Powinna ona bazować na globalnej ocenie potrzeb w zakresie IT i prowadzić do podejmowania świadomych decyzji dotyczących ustalania priorytetowych obszarów interwencji. |
| --- | --- |

11.

Aby skutecznie wykorzystać zasoby, należy określić wieloletnią strategię IT powiązaną z ogólnymi celami organizacyjnymi. Strategia ta powinna być sformułowana w taki sposób, by stanowić podstawę planowania i podejmowania działań w zakresie IT w okresie kilku lat i umożliwiać określenie wydatków na odpowiednim poziomie oraz skoncentrowanie ich tam, gdzie są najbardziej potrzebne. Powinna ona bazować na globalnej ocenie potrzeb w zakresie IT i prowadzić do podejmowania świadomych decyzji dotyczących ustalania priorytetowych obszarów interwencji.

| 12. | Trybunał stwierdził, że EBC nie posiadał wieloletniej strategii IT określającej i przedstawiającej cele strategiczne oraz cele średniookresowe w zakresie IT. Nie została także przeprowadzona globalna ocena potrzeb mająca na celu ustalenie priorytetowych obszarów interwencji w perspektywie średniookresowej. Niezależnie od powyższego podstawę do identyfikacji nowych projektów IT stanowią pismo prezesa oraz strategiczne/operacyjne wytyczne dyrekcji. Następnie, podczas dokonywanej co roku aktualizacji portfela projektów, ustalany jest priorytet poszczególnych projektów (zob. pkt 19–21). |
| --- | --- |

12.

Trybunał stwierdził, że EBC nie posiadał wieloletniej strategii IT określającej i przedstawiającej cele strategiczne oraz cele średniookresowe w zakresie IT. Nie została także przeprowadzona globalna ocena potrzeb mająca na celu ustalenie priorytetowych obszarów interwencji w perspektywie średniookresowej. Niezależnie od powyższego podstawę do identyfikacji nowych projektów IT stanowią pismo prezesa oraz strategiczne/operacyjne wytyczne dyrekcji. Następnie, podczas dokonywanej co roku aktualizacji portfela projektów, ustalany jest priorytet poszczególnych projektów (zob. pkt 19–21).

| 13. | W 2008 r. Dyrekcja Generalna Systemów Informatycznych (DG-IS) oraz Dyrekcja Generalna Kadr, Budżetu i Organizacji (DG-H) rozpoczęły strategiczny przegląd działań EBC w zakresie IT, w ścisłej współpracy z innymi dyrekcjami EBC. W momencie kontroli Trybunału (pierwszy kwartał 2009 r.) przegląd ten nie był jeszcze ukończony. Pierwsza faza przeglądu zakłada szczegółowe zbadanie celów dyrekcji i określenie ich wymogów pod względem nowych systemów IT, projektów i usług w najbliższych pięciu latach (2009–2013). Ma ona zakończyć się opracowaniem strategii IT dla wszystkich funkcji DG-IS (w tym projektów IT). |
| --- | --- |

13.

W 2008 r. Dyrekcja Generalna Systemów Informatycznych (DG-IS) oraz Dyrekcja Generalna Kadr, Budżetu i Organizacji (DG-H) rozpoczęły strategiczny przegląd działań EBC w zakresie IT, w ścisłej współpracy z innymi dyrekcjami EBC. W momencie kontroli Trybunału (pierwszy kwartał 2009 r.) przegląd ten nie był jeszcze ukończony. Pierwsza faza przeglądu zakłada szczegółowe zbadanie celów dyrekcji i określenie ich wymogów pod względem nowych systemów IT, projektów i usług w najbliższych pięciu latach (2009–2013). Ma ona zakończyć się opracowaniem strategii IT dla wszystkich funkcji DG-IS (w tym projektów IT).

Czy EBC planował swoje działania związane z projektami IT w cyklu rocznym?

| 14. | Roczny cykl planowania projektów IT wymaga ustalenia rocznych celów, określenia działań, które należy wdrożyć, aby osiągnąć te cele, oraz wyznaczenia kluczowych wskaźników wykonania umożliwiających pomiar wyników. |
| --- | --- |

14.

Roczny cykl planowania projektów IT wymaga ustalenia rocznych celów, określenia działań, które należy wdrożyć, aby osiągnąć te cele, oraz wyznaczenia kluczowych wskaźników wykonania umożliwiających pomiar wyników.

| 15. | W 2007 r. DG-IS sporządziła dokument zawierający strategiczne/operacyjne wytyczne na 2007 r., w którym wymieniono szereg szeroko zakrojonych celów; niektóre z tych celów dotyczyły zarządzania projektami IT (8). Jednakże nie przekształcono ich w szczegółowe cele i działania ani nie określono oczekiwanych rezultatów. |
| --- | --- |

15.

W 2007 r. DG-IS sporządziła dokument zawierający strategiczne/operacyjne wytyczne na 2007 r., w którym wymieniono szereg szeroko zakrojonych celów; niektóre z tych celów dotyczyły zarządzania projektami IT (8). Jednakże nie przekształcono ich w szczegółowe cele i działania ani nie określono oczekiwanych rezultatów.

| 16. | W 2008 r. DG-IS przygotowała dwa dokumenty programowe: ogólne strategiczne/operacyjne wytyczne na 2008 r. oraz program prac na 2008 r. Strategiczne/operacyjne wytyczne na 2008 r. zawierały część podsumowującą główne wyzwania stojące przed DG-IS w tym roku oraz przegląd celów i kluczowych wskaźników wykonania na 2008 r. Niektóre z tych celów związane były z zarządzaniem projektami IT (9). Osiągnięcie tych celów miało być mierzone za pomocą konkretnych kwantyfikowalnych kluczowych wskaźników wykonania, dla których ustalono cele w odniesieniu do drugiego i czwartego kwartału 2008 r. |
| --- | --- |

16.

W 2008 r. DG-IS przygotowała dwa dokumenty programowe: ogólne strategiczne/operacyjne wytyczne na 2008 r. oraz program prac na 2008 r. Strategiczne/operacyjne wytyczne na 2008 r. zawierały część podsumowującą główne wyzwania stojące przed DG-IS w tym roku oraz przegląd celów i kluczowych wskaźników wykonania na 2008 r. Niektóre z tych celów związane były z zarządzaniem projektami IT (9). Osiągnięcie tych celów miało być mierzone za pomocą konkretnych kwantyfikowalnych kluczowych wskaźników wykonania, dla których ustalono cele w odniesieniu do drugiego i czwartego kwartału 2008 r.

| 17. | Program prac na 2008 r. zawierał więcej szczegółów dzięki określeniu w nim oczekiwanych działań, które należało przeprowadzić, aby osiągnąć każdy z tych celów. Stanowi to poprawę w stosunku do sytuacji z 2007 r. i jest pozytywną zmianą podwyższającą jakość procesu planowania. Odnotowano jednak, że program prac na 2008 r. zawierał znacznie więcej celów niż wyżej wspomniane strategiczne/operacyjne wytyczne na 2008 r. Program prac nie został przygotowany w celu rozwinięcia i uszczegółowienia sposobów osiągnięcia celów wybranych w ramach strategicznych/operacyjnych wytycznych oraz nie po to, by wprowadzać nowe cele. |
| --- | --- |

17.

Program prac na 2008 r. zawierał więcej szczegółów dzięki określeniu w nim oczekiwanych działań, które należało przeprowadzić, aby osiągnąć każdy z tych celów. Stanowi to poprawę w stosunku do sytuacji z 2007 r. i jest pozytywną zmianą podwyższającą jakość procesu planowania. Odnotowano jednak, że program prac na 2008 r. zawierał znacznie więcej celów niż wyżej wspomniane strategiczne/operacyjne wytyczne na 2008 r. Program prac nie został przygotowany w celu rozwinięcia i uszczegółowienia sposobów osiągnięcia celów wybranych w ramach strategicznych/operacyjnych wytycznych oraz nie po to, by wprowadzać nowe cele.

| 18. | Ponadto żaden z dokumentów programowych na 2008 r. nie jest dostatecznie szczegółowy, aby mógł być wykorzystywany jako skuteczny dokument programowy. Co więcej, nie wskazano w nich zasobów finansowych koniecznych do osiągnięcia poszczególnych celów oraz do realizacji poszczególnych wybranych działań. |
| --- | --- |

18.

Ponadto żaden z dokumentów programowych na 2008 r. nie jest dostatecznie szczegółowy, aby mógł być wykorzystywany jako skuteczny dokument programowy. Co więcej, nie wskazano w nich zasobów finansowych koniecznych do osiągnięcia poszczególnych celów oraz do realizacji poszczególnych wybranych działań.

Czy w procesie wyboru projektów IT do realizacji stosowano rzetelne kryteria?

| 19. | Zasoby pozwalające na sfinansowanie wszystkich możliwych projektów każdego roku nie są dostępne. Niezbędna jest zatem procedura dokonywania wyboru projektów o najwyższym priorytecie, co umożliwi najlepsze wykorzystanie dostępnych zasobów. |
| --- | --- |

19.

Zasoby pozwalające na sfinansowanie wszystkich możliwych projektów każdego roku nie są dostępne. Niezbędna jest zatem procedura dokonywania wyboru projektów o najwyższym priorytecie, co umożliwi najlepsze wykorzystanie dostępnych zasobów.

| 20. | W 2007 r. proces ustalania priorytetu i wyboru projektów został oparty na trzyletnim średniookresowym planie portfela projektów. Każdego roku EBC dokonuje ponownej oceny wszystkich projektów (realizowanych, zarejestrowanych w systemie realizowanych projektów, lecz jeszcze nierozpoczętych oraz nowo zarejestrowanych) pod kątem ogólnych celów EBC. Ten średniookresowy plan jest aktualizowany dwa razy do roku celem uwzględnienia nowo zarejestrowanych projektów i innych zmian. Ocena projektów opiera się na przedstawionych analizach biznesowych oraz na przewidywanym wykorzystaniu zasobów przy realizacji projektów. Nie istniały jasne kryteria ustalania priorytetu. Spowodowało to mniej obiektywny wybór projektów i zwiększyło ryzyko niewykorzystania w sposób optymalny dostępnych zasobów. |
| --- | --- |

20.

W 2007 r. proces ustalania priorytetu i wyboru projektów został oparty na trzyletnim średniookresowym planie portfela projektów. Każdego roku EBC dokonuje ponownej oceny wszystkich projektów (realizowanych, zarejestrowanych w systemie realizowanych projektów, lecz jeszcze nierozpoczętych oraz nowo zarejestrowanych) pod kątem ogólnych celów EBC. Ten średniookresowy plan jest aktualizowany dwa razy do roku celem uwzględnienia nowo zarejestrowanych projektów i innych zmian. Ocena projektów opiera się na przedstawionych analizach biznesowych oraz na przewidywanym wykorzystaniu zasobów przy realizacji projektów. Nie istniały jasne kryteria ustalania priorytetu. Spowodowało to mniej obiektywny wybór projektów i zwiększyło ryzyko niewykorzystania w sposób optymalny dostępnych zasobów.

| 21. | W 2008 r. wprowadzono ulepszoną metodykę ustalania priorytetu. Została ona oparta na zasadzie trzech filarów (10). Metodyka polegała na dokonaniu szczegółowej oceny w obrębie danej dziedziny (11), po czym następowała konsolidacja tych ocen na poziomie EBC. Ustanowiony w 2008 r. system zarządzania projektami IT dostarczał dostatecznych informacji do podejmowania decyzji. Jednakże zastosowane kryteria oceny nie zostały ujawnione dyrekcjom, co spowodowało brak przejrzystości procedury pod tym względem. |
| --- | --- |

21.

W 2008 r. wprowadzono ulepszoną metodykę ustalania priorytetu. Została ona oparta na zasadzie trzech filarów (10). Metodyka polegała na dokonaniu szczegółowej oceny w obrębie danej dziedziny (11), po czym następowała konsolidacja tych ocen na poziomie EBC. Ustanowiony w 2008 r. system zarządzania projektami IT dostarczał dostatecznych informacji do podejmowania decyzji. Jednakże zastosowane kryteria oceny nie zostały ujawnione dyrekcjom, co spowodowało brak przejrzystości procedury pod tym względem.

Czy ustanowiono stosowne procedury zarządzania projektami IT?

Procedury zarządzania projektami IT

| 22. | EBC ustanowił procedury organizacji i kontroli projektów (POCP), zgodnie z którymi należy zarządzać wszystkimi projektami, łącznie z projektami IT (12). POCP zawiera szczegółową definicję projektu oraz jasne określenie zakresu jego stosowania. Określa również strukturę organizacyjną wymaganą dla projektów, łącznie z zadaniami i zakresem obowiązków odpowiednich zaangażowanych jednostek. |
| --- | --- |

22.

EBC ustanowił procedury organizacji i kontroli projektów (POCP), zgodnie z którymi należy zarządzać wszystkimi projektami, łącznie z projektami IT (12). POCP zawiera szczegółową definicję projektu oraz jasne określenie zakresu jego stosowania. Określa również strukturę organizacyjną wymaganą dla projektów, łącznie z zadaniami i zakresem obowiązków odpowiednich zaangażowanych jednostek.

| 23. | Zgodnie z definicją zawartą w POCP w ramach cyklu projektowego ustalona zostaje struktura niezbędna do skutecznej kontroli nad projektami. W ramach tej struktury cykl projektowy podzielony jest na logiczne fazy, a etapy, na których podejmowane są decyzje, są precyzyjnie określone (zob.
  schemat 1
  ). Porównanie POCP z PMBOK wykazało, że POCP jest w dużej mierze zgodne z tą najlepszą praktyką. Dwa obszary, w których możliwa jest poprawa POCP, obejmują: analizę zainteresowanych podmiotów i ocenę ex post oddziaływania projektu. Obecne uchybienia i ich oddziaływanie przedstawiono szczegółowo w kolejnych punktach. |
| --- | --- |

23.

Zgodnie z definicją zawartą w POCP w ramach cyklu projektowego ustalona zostaje struktura niezbędna do skutecznej kontroli nad projektami. W ramach tej struktury cykl projektowy podzielony jest na logiczne fazy, a etapy, na których podejmowane są decyzje, są precyzyjnie określone (zob.
  schemat 1
  ). Porównanie POCP z PMBOK wykazało, że POCP jest w dużej mierze zgodne z tą najlepszą praktyką. Dwa obszary, w których możliwa jest poprawa POCP, obejmują: analizę zainteresowanych podmiotów i ocenę ex post oddziaływania projektu. Obecne uchybienia i ich oddziaływanie przedstawiono szczegółowo w kolejnych punktach.

Schemat 1 –   Fazy cyklu projektowego

Image

Źródło: Europejski Bank Centralny.

| 24. | POCP nie pozwala na formalne przygotowanie i udokumentowanie analizy zainteresowanych podmiotów. Oznacza to, że zespół projektowy nie jest zobowiązany do formalnego zidentyfikowania zainteresowanych podmiotów i określenia ich specyficznych wymagań projektowych (13). Brak formalnej identyfikacji wszystkich zainteresowanych podmiotów oraz ich potrzeb mógł mieć negatywny wpływ na powodzenie projektów. Należy zauważyć, że w przypadku konkretnych zbadanych projektów potrzeby użytkowników zostały uwzględnione (zob. pkt 33 i 36). |
| --- | --- |

24.

POCP nie pozwala na formalne przygotowanie i udokumentowanie analizy zainteresowanych podmiotów. Oznacza to, że zespół projektowy nie jest zobowiązany do formalnego zidentyfikowania zainteresowanych podmiotów i określenia ich specyficznych wymagań projektowych (13). Brak formalnej identyfikacji wszystkich zainteresowanych podmiotów oraz ich potrzeb mógł mieć negatywny wpływ na powodzenie projektów. Należy zauważyć, że w przypadku konkretnych zbadanych projektów potrzeby użytkowników zostały uwzględnione (zob. pkt 33 i 36).

| 25. | Nie przewiduje się oceny ex post rezultatów projektu i jego oddziaływania, jeżeli projekt ten jest w toku realizacji od pewnego czasu. Ocena taka dostarczyłaby, między innymi, formalnego osądu w zakresie osiągnięcia oczekiwanych jakościowych i ilościowych korzyści określonych w dokumentach zatwierdzających dany projekt, i w ten sposób ułatwiłaby planowanie kolejnych projektów (zob. pkt 53). Niedawną pozytywną zmianą w tym zakresie było powstanie nowego formularza wymagającego od klientów corocznych informacji zwrotnych na temat projektów IT, który pozwala zbadać poziom zadowolenia końcowych użytkowników z dostarczonych usług. |
| --- | --- |

25.

Nie przewiduje się oceny ex post rezultatów projektu i jego oddziaływania, jeżeli projekt ten jest w toku realizacji od pewnego czasu. Ocena taka dostarczyłaby, między innymi, formalnego osądu w zakresie osiągnięcia oczekiwanych jakościowych i ilościowych korzyści określonych w dokumentach zatwierdzających dany projekt, i w ten sposób ułatwiłaby planowanie kolejnych projektów (zob. pkt 53). Niedawną pozytywną zmianą w tym zakresie było powstanie nowego formularza wymagającego od klientów corocznych informacji zwrotnych na temat projektów IT, który pozwala zbadać poziom zadowolenia końcowych użytkowników z dostarczonych usług.

Podział obowiązków i struktura decyzyjna

| 26. | W celu zapewnienia wydajnej i skutecznej realizacji projektów niezbędne jest ustanowienie zasad zarządzania nimi, które wyznaczają jasne stosunki podległości oraz podział obowiązków jednostek i funkcji zaangażowanych w proces. |
| --- | --- |

26.

W celu zapewnienia wydajnej i skutecznej realizacji projektów niezbędne jest ustanowienie zasad zarządzania nimi, które wyznaczają jasne stosunki podległości oraz podział obowiązków jednostek i funkcji zaangażowanych w proces.

| 27. | W dokumencie POCP określono strukturę organizacyjną, którą należy ustanowić na potrzeby zarządzania projektami EBC, łącznie z zadaniami i obowiązkami oraz składem odpowiednich zaangażowanych jednostek (zob.
  schemat 2
  ). |
| --- | --- |

27.

W dokumencie POCP określono strukturę organizacyjną, którą należy ustanowić na potrzeby zarządzania projektami EBC, łącznie z zadaniami i obowiązkami oraz składem odpowiednich zaangażowanych jednostek (zob.
  schemat 2
  ).

Schemat 2 –   Zarys systemu zarządzania projektami EBC

Image

Źródło: Europejski Bank Centralny.

| 28. | W POCP określono jasny stosunek podległości pomiędzy jednostkami i funkcjami objętymi procesem. Komitet Sterujący jest głównym wewnętrznym organem decyzyjnym EBC w zakresie ustalania priorytetu, planowania, zatwierdzania i monitorowania projektów. Struktura utworzona na podstawie POCP obejmuje wszystkie niezbędne funkcje i zapewnia jasne procedury decyzyjne, łącznie z wcześniej zdefiniowanymi zadaniami i obowiązkami. |
| --- | --- |

28.

W POCP określono jasny stosunek podległości pomiędzy jednostkami i funkcjami objętymi procesem. Komitet Sterujący jest głównym wewnętrznym organem decyzyjnym EBC w zakresie ustalania priorytetu, planowania, zatwierdzania i monitorowania projektów. Struktura utworzona na podstawie POCP obejmuje wszystkie niezbędne funkcje i zapewnia jasne procedury decyzyjne, łącznie z wcześniej zdefiniowanymi zadaniami i obowiązkami.

Czy ustalony system zarządzania projektami IT był stosowany zgodnie z założeniami?

| 29. | W ramach kontroli stosowania systemu zarządzania projektami IT Trybunał zbadał, czy EBC:






  — | stosownie planował poszczególne projekty, oceniając ich cele i proponowane rozwiązania oraz uwzględniając potrzebne zasoby, |
| --- | --- | --- |

29.

W ramach kontroli stosowania systemu zarządzania projektami IT Trybunał zbadał, czy EBC:

—

stosownie planował poszczególne projekty, oceniając ich cele i proponowane rozwiązania oraz uwzględniając potrzebne zasoby,

| — | odpowiednio realizował poszczególne projekty, zapewniając terminowe udostępnianie zasobów oraz dostateczne testowanie każdego produktu projektu, |
| --- | --- |

—

odpowiednio realizował poszczególne projekty, zapewniając terminowe udostępnianie zasobów oraz dostateczne testowanie każdego produktu projektu,

| — | monitorował realizację projektów dzięki ustanowieniu systemów generujących częste sprawozdania podsumowujące wszystkie stosowne dane dotyczące projektów w celu podejmowania świadomych decyzji, oraz |
| --- | --- |

—

monitorował realizację projektów dzięki ustanowieniu systemów generujących częste sprawozdania podsumowujące wszystkie stosowne dane dotyczące projektów w celu podejmowania świadomych decyzji, oraz

| — | dokonywał formalnej oceny produktów projektów i wykorzystanych zasobów po zakończeniu projektów. |
| --- | --- |

—

dokonywał formalnej oceny produktów projektów i wykorzystanych zasobów po zakończeniu projektów.

Czy poszczególne projekty były stosownie planowane?

Dokument przedłożenia projektu (PSD)

| 30. | Planowanie projektu jest odpowiednie, kiedy uwzględnione są następujące elementy: i) ogólne cele i zakres projektu; ii) proponowane rozwiązanie; iii) kluczowe etapy realizacji i produkty projektu; iv) zasoby finansowe i ludzkie; oraz v) zespół projektowy. |
| --- | --- |

30.

Planowanie projektu jest odpowiednie, kiedy uwzględnione są następujące elementy: i) ogólne cele i zakres projektu; ii) proponowane rozwiązanie; iii) kluczowe etapy realizacji i produkty projektu; iv) zasoby finansowe i ludzkie; oraz v) zespół projektowy.

| 31. | Głównym dokumentem dotyczącym planowania jest dokument przedłożenia projektu (PSD) (zob. 
  schemat 1
  ). Dokument ten służy jako podstawa przy podejmowaniu decyzji o realizacji wybranego w projekcie rozwiązania. W przypadku wszystkich sześciu zbadanych projektów zawartość tego dokumentu była kompleksowa i odnosiła się do wszystkich kwestii, które należy uwzględnić przy zatwierdzaniu projektu. |
| --- | --- |

31.

Głównym dokumentem dotyczącym planowania jest dokument przedłożenia projektu (PSD) (zob. 
  schemat 1
  ). Dokument ten służy jako podstawa przy podejmowaniu decyzji o realizacji wybranego w projekcie rozwiązania. W przypadku wszystkich sześciu zbadanych projektów zawartość tego dokumentu była kompleksowa i odnosiła się do wszystkich kwestii, które należy uwzględnić przy zatwierdzaniu projektu.

Zatwierdzanie i wybór projektów

| 32. | Wszystkie projekty zostały zatwierdzone zgodnie z procedurami przewidzianymi w POCP. Przed każdą z trzech faz projektu (14) Komitet Sterujący wydawał formalną decyzję o podjęciu dalszych działań. Trzy projekty (15) zostały uznane za konieczne do zrealizowania w celu spełniania standardów ESCB lub innych wymaganych standardów. Pozostałe projekty (16) zostały wybrane za pomocą metodyki ustalania priorytetu projektów. Wszystkie projekty były spójne albo ze strategicznymi/operacyjnymi wytycznymi DG-IS, albo z ogólnymi strategiami odnośnej dyrekcji. |
| --- | --- |

32.

Wszystkie projekty zostały zatwierdzone zgodnie z procedurami przewidzianymi w POCP. Przed każdą z trzech faz projektu (14) Komitet Sterujący wydawał formalną decyzję o podjęciu dalszych działań. Trzy projekty (15) zostały uznane za konieczne do zrealizowania w celu spełniania standardów ESCB lub innych wymaganych standardów. Pozostałe projekty (16) zostały wybrane za pomocą metodyki ustalania priorytetu projektów. Wszystkie projekty były spójne albo ze strategicznymi/operacyjnymi wytycznymi DG-IS, albo z ogólnymi strategiami odnośnej dyrekcji.

Potrzeby użytkowników i specyfikacje projektów

| 33. | W przypadku trzech zbadanych projektów (17) potrzeby użytkowników zostały ocenione i udokumentowane w fazie planowania. Jako że pozostałe trzy projekty dotyczyły jedynie rozszerzenia istniejącej sieci (TCERTO) lub modernizacji istniejącej infrastruktury (EER i MAU) użytkownicy nie byli zaangażowani w fazie planowania. W przypadku MPIDS specyfikacje projektu opracowano przy wykorzystaniu podejścia polegającego na wielokrotnym testowaniu. Podejścia tego nie stosowano w najlepszy możliwy sposób. Spowodowało to opóźnienia, a wersje testowe nie były wystarczająco przygotowane w stosunku do oczekiwań. |
| --- | --- |

33.

W przypadku trzech zbadanych projektów (17) potrzeby użytkowników zostały ocenione i udokumentowane w fazie planowania. Jako że pozostałe trzy projekty dotyczyły jedynie rozszerzenia istniejącej sieci (TCERTO) lub modernizacji istniejącej infrastruktury (EER i MAU) użytkownicy nie byli zaangażowani w fazie planowania. W przypadku MPIDS specyfikacje projektu opracowano przy wykorzystaniu podejścia polegającego na wielokrotnym testowaniu. Podejścia tego nie stosowano w najlepszy możliwy sposób. Spowodowało to opóźnienia, a wersje testowe nie były wystarczająco przygotowane w stosunku do oczekiwań.

Ocena ryzyka

| 34. | Zagrożenia dla osiągnięcia celów projektu powinny być zidentyfikowane wystarczająco szczegółowo, a także powinny zostać ustrukturyzowane i dokładnie ocenione w fazie planowania pod względem prawdopodobieństwa ich wystąpienia oraz potencjalnego wpływu na osiągnięcie celów projektu. |
| --- | --- |

34.

Zagrożenia dla osiągnięcia celów projektu powinny być zidentyfikowane wystarczająco szczegółowo, a także powinny zostać ustrukturyzowane i dokładnie ocenione w fazie planowania pod względem prawdopodobieństwa ich wystąpienia oraz potencjalnego wpływu na osiągnięcie celów projektu.

| 35. | We wzorach wszystkich trzech dokumentów dotyczących planowania (18) znajduje się część poświęcona analizie ryzyka. Część ta została wypełniona we wszystkich dokumentach przedłożenia projektu. Jednakże nie stosowano wspólnego podejścia do identyfikacji zagrożeń w ramach projektów oraz do oceny prawdopodobieństwa wystąpienia tych zagrożeń oraz ich wpływu. Ocena ta opierała się na doświadczeniu kierownika danego projektu. W przypadku MDP ocena ryzyka uwzględniała wyłącznie zagrożenia związane z zewnętrznymi wykonawcami. W trakcie realizacji projektu pojawiły się także wewnętrzne zagrożenia związane z ograniczonymi zasobami. Jako że kwestie te nie były uwzględniane jako zagrożenia, na etapie planowania nie przewidziano działań naprawczych. W przypadku MPIDS można było przewidzieć również inne zagrożenia, których jednak nie ujęto w dokumencie przedłożenia projektu, jak np. złożoność obszarów działalności dyrekcji, w ramach których projekt był realizowany. |
| --- | --- |

35.

We wzorach wszystkich trzech dokumentów dotyczących planowania (18) znajduje się część poświęcona analizie ryzyka. Część ta została wypełniona we wszystkich dokumentach przedłożenia projektu. Jednakże nie stosowano wspólnego podejścia do identyfikacji zagrożeń w ramach projektów oraz do oceny prawdopodobieństwa wystąpienia tych zagrożeń oraz ich wpływu. Ocena ta opierała się na doświadczeniu kierownika danego projektu. W przypadku MDP ocena ryzyka uwzględniała wyłącznie zagrożenia związane z zewnętrznymi wykonawcami. W trakcie realizacji projektu pojawiły się także wewnętrzne zagrożenia związane z ograniczonymi zasobami. Jako że kwestie te nie były uwzględniane jako zagrożenia, na etapie planowania nie przewidziano działań naprawczych. W przypadku MPIDS można było przewidzieć również inne zagrożenia, których jednak nie ujęto w dokumencie przedłożenia projektu, jak np. złożoność obszarów działalności dyrekcji, w ramach których projekt był realizowany.

Czy projekty były odpowiednio realizowane?

Zarządzanie zasobami i uczestnictwo użytkowników

| 36. | W przypadku trzech zbadanych projektów (19) zasoby i umiejętności przeznaczone na realizację projektu były wystarczające. Pozostałe trzy projekty borykały się z problemem wyspecjalizowanych zasobów, które nie zostały na czas udostępnione w wystarczającym stopniu. W przypadku MDP użytkownicy nie zawsze byli dostępni, ponieważ w tym samym czasie musiał być sfinalizowany podobny projekt. Spowodowało to opóźnienia w realizacji projektu. W przypadku MPIDS nie przypisano do zespołu żadnego analityka biznesowego, a pracownicy DG-IS nie zawsze byli dyspozycyjni w momencie, kiedy byli potrzebni. Zakontraktowanie zewnętrznego dewelopera spowodowało trzymiesięczne opóźnienie. Po podpisaniu umowy deweloper często się zmieniał, co powodowało problemy w realizacji projektu. Ze względu na swoją złożoność projekt był realizowany w kilku etapach (20). Transfer wiedzy z drugiego do trzeciego etapu nie został przeprowadzony zgodnie z planem, ponieważ większość głównych członków zespołu projektowego, w tym kierownik projektu, nie kontynuowało pracy w etapie 3. |
| --- | --- |

36.

W przypadku trzech zbadanych projektów (19) zasoby i umiejętności przeznaczone na realizację projektu były wystarczające. Pozostałe trzy projekty borykały się z problemem wyspecjalizowanych zasobów, które nie zostały na czas udostępnione w wystarczającym stopniu. W przypadku MDP użytkownicy nie zawsze byli dostępni, ponieważ w tym samym czasie musiał być sfinalizowany podobny projekt. Spowodowało to opóźnienia w realizacji projektu. W przypadku MPIDS nie przypisano do zespołu żadnego analityka biznesowego, a pracownicy DG-IS nie zawsze byli dyspozycyjni w momencie, kiedy byli potrzebni. Zakontraktowanie zewnętrznego dewelopera spowodowało trzymiesięczne opóźnienie. Po podpisaniu umowy deweloper często się zmieniał, co powodowało problemy w realizacji projektu. Ze względu na swoją złożoność projekt był realizowany w kilku etapach (20). Transfer wiedzy z drugiego do trzeciego etapu nie został przeprowadzony zgodnie z planem, ponieważ większość głównych członków zespołu projektowego, w tym kierownik projektu, nie kontynuowało pracy w etapie 3.

| 37. | We wszystkich wybranych projektach użytkownicy byli regularnie informowani w trakcie realizacji projektu. W przypadku większości projektów użytkownicy byli reprezentowani w grupie sterującej i/lub podczas spotkań zespołu projektowego, a także byli informowani za pomocą miesięcznych sprawozdań z postępów w realizacji projektu. |
| --- | --- |

37.

We wszystkich wybranych projektach użytkownicy byli regularnie informowani w trakcie realizacji projektu. W przypadku większości projektów użytkownicy byli reprezentowani w grupie sterującej i/lub podczas spotkań zespołu projektowego, a także byli informowani za pomocą miesięcznych sprawozdań z postępów w realizacji projektu.

Zewnętrzni wykonawcy

| 38. | W projekcie MDP zastosowano wyjątek od zasad EBC dotyczących zamówień i uzasadniono go niemożnością oddzielenia tego zamówienia od poprzedniego wyboru dostawcy. Dostawca okazał się niezdolny do dostarczenia oczekiwanego rozwiązania, gdyż opracowywanie oprogramowania i wsparcie w tym zakresie nie należało do jego podstawowej działalności. Problemy z tym związane spowodowały, że przygotowanie uruchomienia serwisu było droższe niż przewidywano. |
| --- | --- |

38.

W projekcie MDP zastosowano wyjątek od zasad EBC dotyczących zamówień i uzasadniono go niemożnością oddzielenia tego zamówienia od poprzedniego wyboru dostawcy. Dostawca okazał się niezdolny do dostarczenia oczekiwanego rozwiązania, gdyż opracowywanie oprogramowania i wsparcie w tym zakresie nie należało do jego podstawowej działalności. Problemy z tym związane spowodowały, że przygotowanie uruchomienia serwisu było droższe niż przewidywano.

Testowanie i zatwierdzanie produktów projektu w trakcie jego realizacji

| 39. | Testowanie nowych lub zmienionych produktów IT stanowi część procedur EBC, które należy przeprowadzić przed uruchomieniem każdego produktu. Testy przeprowadzono przed uruchomieniem rozwiązań we wszystkich sześciu projektach. Testy te zostały opracowane przez zespół projektowy. Jednakże w ich opracowanie nie zawsze angażowano użytkowników końcowych, co spowodowało, że nie zidentyfikowano koniecznych usprawnień w odpowiednim czasie. |
| --- | --- |

39.

Testowanie nowych lub zmienionych produktów IT stanowi część procedur EBC, które należy przeprowadzić przed uruchomieniem każdego produktu. Testy przeprowadzono przed uruchomieniem rozwiązań we wszystkich sześciu projektach. Testy te zostały opracowane przez zespół projektowy. Jednakże w ich opracowanie nie zawsze angażowano użytkowników końcowych, co spowodowało, że nie zidentyfikowano koniecznych usprawnień w odpowiednim czasie.

Czy projekty były odpowiednio monitorowane?

Systemy informacji zarządczej i sprawozdania z monitoringu

| 40. | Kierownicy projektów powinni dysponować dostatecznymi i wiarygodnymi informacjami, aby skutecznie monitorować projekty w trakcie ich realizacji oraz móc wykryć problemy w odpowiednim czasie i je rozwiązać. |
| --- | --- |

40.

Kierownicy projektów powinni dysponować dostatecznymi i wiarygodnymi informacjami, aby skutecznie monitorować projekty w trakcie ich realizacji oraz móc wykryć problemy w odpowiednim czasie i je rozwiązać.

| 41. | Do monitorowania projektów IT EBC stosuje kilka narzędzi. Czas spędzony przy projektach oraz dane finansowe i informacje dotyczące głównych osiągnięć i postępów poczynionych w ramach projektu przedstawiane są w miesięcznych sprawozdaniach z postępów w realizacji projektu. Zawierające wystarczające informacje sprawozdania z postępów w realizacji projektu były regularnie przygotowywane w odniesieniu do wszystkich sześciu projektów podczas ich realizacji. Odnotowano jednak, że w przypadku projektu Target 2 SSP nie sporządzono niektórych sprawozdań ze względu na brak zasobów kadrowych. |
| --- | --- |

41.

Do monitorowania projektów IT EBC stosuje kilka narzędzi. Czas spędzony przy projektach oraz dane finansowe i informacje dotyczące głównych osiągnięć i postępów poczynionych w ramach projektu przedstawiane są w miesięcznych sprawozdaniach z postępów w realizacji projektu. Zawierające wystarczające informacje sprawozdania z postępów w realizacji projektu były regularnie przygotowywane w odniesieniu do wszystkich sześciu projektów podczas ich realizacji. Odnotowano jednak, że w przypadku projektu Target 2 SSP nie sporządzono niektórych sprawozdań ze względu na brak zasobów kadrowych.

| 42. | Jednakże czas poświęcony projektom zarejestrowany jest wyłącznie w odniesieniu do pracowników DG-IS. Czas poświęcony przez pracowników dyrekcji oraz krajowych banków centralnych został jedynie oszacowany. Ponadto nadgodzin z reguły nie rejestrowano w sposób systematyczny, lub też wcale ich nie uwzględniano. Dlatego też monitorowanie nie było oparte na pełnych i dokładnych danych dotyczących czasu. |
| --- | --- |

42.

Jednakże czas poświęcony projektom zarejestrowany jest wyłącznie w odniesieniu do pracowników DG-IS. Czas poświęcony przez pracowników dyrekcji oraz krajowych banków centralnych został jedynie oszacowany. Ponadto nadgodzin z reguły nie rejestrowano w sposób systematyczny, lub też wcale ich nie uwzględniano. Dlatego też monitorowanie nie było oparte na pełnych i dokładnych danych dotyczących czasu.

Czy na zakończenie projektów dokonywano ich formalnej oceny?

| 43. | Na zakończenie projektu należy przeprowadzić formalną ocenę osiągnięcia celów projektu i wykorzystanych zasobów. POCP zawiera sprawozdanie z zakończenia projektu, które należy przygotować po skutecznym uzyskaniu produktów fazy realizacji projektu oraz po zaakceptowaniu końcowego produktu projektu przez odpowiednią(-e) dyrekcję(-e), właściciela systemu oraz przez DG-IS/Dział Eksploatacji. Sprawozdanie z zakończenia projektu służy tym samym za dokument, na mocy którego wydawana jest zgoda na formalne zakończenie projektu. |
| --- | --- |

43.

Na zakończenie projektu należy przeprowadzić formalną ocenę osiągnięcia celów projektu i wykorzystanych zasobów. POCP zawiera sprawozdanie z zakończenia projektu, które należy przygotować po skutecznym uzyskaniu produktów fazy realizacji projektu oraz po zaakceptowaniu końcowego produktu projektu przez odpowiednią(-e) dyrekcję(-e), właściciela systemu oraz przez DG-IS/Dział Eksploatacji. Sprawozdanie z zakończenia projektu służy tym samym za dokument, na mocy którego wydawana jest zgoda na formalne zakończenie projektu.

| 44. | Dokument ten jest kompleksowy i odnosi się do wszystkich głównych kwestii, które należy uwzględnić w czasie zamykania projektu. Jego główne części to:






  i) | ocena osiągnięcia zatwierdzonego zakresu i celów projektu; |
| --- | --- | --- |

44.

Dokument ten jest kompleksowy i odnosi się do wszystkich głównych kwestii, które należy uwzględnić w czasie zamykania projektu. Jego główne części to:

i)

ocena osiągnięcia zatwierdzonego zakresu i celów projektu;

| ii) | ocena wykorzystania zasobów ludzkich i finansowych; |
| --- | --- |

ii)

ocena wykorzystania zasobów ludzkich i finansowych;

| iii) | ilościowa i jakościowa ocena korzyści; oraz |
| --- | --- |

iii)

ilościowa i jakościowa ocena korzyści; oraz

| iv) | sprawozdanie dotyczące wyciągniętych wniosków. |
| --- | --- |

iv)

sprawozdanie dotyczące wyciągniętych wniosków.

| 45. | Do 15 kwietnia 2009 r. sprawozdanie z zakończenia projektu zostało sporządzone i zatwierdzone w odniesieniu do pięciu z sześciu zbadanych projektów (zob.
  załącznik
  ). Ogólnie POCP stanowi, że projekt należy zamknąć w ciągu trzech miesięcy od zatwierdzenia jego końcowych produktów. W przypadku Target 2 SSP użytkowanie rozpoczęło się w maju 2008 r., a projekt został zamknięty 15 kwietnia 2009 r. Stało się tak, ponieważ DG-IS i właściciel systemu nie mogli dojść do porozumienia w sprawie treści umowy o gwarantowanym poziomie usług (SLA). Podczas posiedzenia grupy sterującej w październiku 2007 r. stwierdzono, że SLA musi zostać zawarta przed uruchomieniem Target 2 SSP. Szybkie zawarcie tej umowy jest konieczne ze względu na kluczowe znaczenie jasnego przedstawienia oczekiwań/usług oraz komunikacji pomiędzy działaniami i poszczególnymi użytkownikami. Podobnie w przypadku MPIDS projekt nie został zamknięty, ponieważ SLA podpisano ze znacznym opóźnieniem. |
| --- | --- |

45.

Do 15 kwietnia 2009 r. sprawozdanie z zakończenia projektu zostało sporządzone i zatwierdzone w odniesieniu do pięciu z sześciu zbadanych projektów (zob.
  załącznik
  ). Ogólnie POCP stanowi, że projekt należy zamknąć w ciągu trzech miesięcy od zatwierdzenia jego końcowych produktów. W przypadku Target 2 SSP użytkowanie rozpoczęło się w maju 2008 r., a projekt został zamknięty 15 kwietnia 2009 r. Stało się tak, ponieważ DG-IS i właściciel systemu nie mogli dojść do porozumienia w sprawie treści umowy o gwarantowanym poziomie usług (SLA). Podczas posiedzenia grupy sterującej w październiku 2007 r. stwierdzono, że SLA musi zostać zawarta przed uruchomieniem Target 2 SSP. Szybkie zawarcie tej umowy jest konieczne ze względu na kluczowe znaczenie jasnego przedstawienia oczekiwań/usług oraz komunikacji pomiędzy działaniami i poszczególnymi użytkownikami. Podobnie w przypadku MPIDS projekt nie został zamknięty, ponieważ SLA podpisano ze znacznym opóźnieniem.

Ocena osiągnięcia zatwierdzonego zakresu i celów projektu

| 46. | Na zakończenie projektu należy przeprowadzić ocenę faktycznych rezultatów projektu w odniesieniu do zatwierdzonego zakresu i celów projektu. Ocena ta powinna uwzględniać kluczowe etapy realizacji i produkty projektu oraz podawać uzasadnienie wszelkich znaczących odstępstw. |
| --- | --- |

46.

Na zakończenie projektu należy przeprowadzić ocenę faktycznych rezultatów projektu w odniesieniu do zatwierdzonego zakresu i celów projektu. Ocena ta powinna uwzględniać kluczowe etapy realizacji i produkty projektu oraz podawać uzasadnienie wszelkich znaczących odstępstw.

| 47. | Trybunał zbadał oceny przeprowadzone w odniesieniu do wszystkich czterech projektów, dla których sprawozdanie z zakończenia projektu zostało zatwierdzone do końca marca 2009 r. W sporządzonych ocenach porównano początkowy plan zawarty w dokumencie przedstawienia projektu z osiągnięciami. Odniesiono się w nich do każdego zaplanowanego etapu realizacji i produktu i przedstawiono uzasadnienie każdego z głównych odstępstw. Odnotowano jednak, że realizacja dwóch z tych projektów (21) była opóźniona w stosunku do początkowego planu (zob.
  załącznik
  ). Dwa przedstawione podstawowe powody to:






  i) | zwiększenie zakresu prac; oraz |
| --- | --- | --- |

47.

Trybunał zbadał oceny przeprowadzone w odniesieniu do wszystkich czterech projektów, dla których sprawozdanie z zakończenia projektu zostało zatwierdzone do końca marca 2009 r. W sporządzonych ocenach porównano początkowy plan zawarty w dokumencie przedstawienia projektu z osiągnięciami. Odniesiono się w nich do każdego zaplanowanego etapu realizacji i produktu i przedstawiono uzasadnienie każdego z głównych odstępstw. Odnotowano jednak, że realizacja dwóch z tych projektów (21) była opóźniona w stosunku do początkowego planu (zob.
  załącznik
  ). Dwa przedstawione podstawowe powody to:

i)

zwiększenie zakresu prac; oraz

| ii) | niedostępność zasobów kadrowych. |
| --- | --- |

ii)

niedostępność zasobów kadrowych.

| 48. | W przypadku MAU, pomimo że infrastruktura techniczna była w rzeczywistości dostępna i wykorzystywana znacznie wcześniej niż wskazano to w sprawozdaniu z zakończenia projektu, formalne zatwierdzenie i przekazanie prac było opóźnione o sześć miesięcy. |
| --- | --- |

48.

W przypadku MAU, pomimo że infrastruktura techniczna była w rzeczywistości dostępna i wykorzystywana znacznie wcześniej niż wskazano to w sprawozdaniu z zakończenia projektu, formalne zatwierdzenie i przekazanie prac było opóźnione o sześć miesięcy.

Ocena wykorzystania zasobów kadrowych i finansowych

| 49. | W ramach sprawozdania z zakończenia projektu zaleca się dokonanie porównania pomiędzy zaplanowanymi a faktycznie wykorzystanymi zasobami kadrowymi i finansowymi. Sprawozdanie z zakończenia projektu we wszystkich czterech przypadkach obejmowało takie porównanie i przedstawienie powodów najbardziej znaczących odstępstw. |
| --- | --- |

49.

W ramach sprawozdania z zakończenia projektu zaleca się dokonanie porównania pomiędzy zaplanowanymi a faktycznie wykorzystanymi zasobami kadrowymi i finansowymi. Sprawozdanie z zakończenia projektu we wszystkich czterech przypadkach obejmowało takie porównanie i przedstawienie powodów najbardziej znaczących odstępstw.

| 50. | Faktycznie wykorzystane zasoby kadrowe i finansowe były w każdym z czterech projektów mniejsze niż zabudżetowane. Wskaźnik rzeczywistych wydatków wyniósł od 3 % do 23 % poniżej zaplanowanego budżetu (zob.
  załącznik
  ). Przedstawiono szereg przyczyn tych mniejszych wydatków, które odnosiły się do poszczególnych projektów. |
| --- | --- |

50.

Faktycznie wykorzystane zasoby kadrowe i finansowe były w każdym z czterech projektów mniejsze niż zabudżetowane. Wskaźnik rzeczywistych wydatków wyniósł od 3 % do 23 % poniżej zaplanowanego budżetu (zob.
  załącznik
  ). Przedstawiono szereg przyczyn tych mniejszych wydatków, które odnosiły się do poszczególnych projektów.

| 51. | Kwestia niepełnego wykorzystania budżetu projektów została również poruszona przez Komitet Budżetowy EBC w jego sprawozdaniu oceniającym sprawozdanie z monitoringu budżetu EBC na koniec 2008 r. Wspomniano tam, że Komitet odnotował niewykorzystanie środków w wysokości 18 mln euro (28,8 %). Komitet uznał, że spowodowane było to przede wszystkim opóźnieniami w niektórych projektach i że wskazana jest poprawa planowania i realizacji projektów. Trybunał stwierdził, że opóźnienia w realizacji projektów istnieją (zob.
  załącznik
  ) i faktycznie mają wpływ na wykonanie budżetu. Zważywszy jednak, że zasoby przewidziane w początkowych planach były nadmierne, można stwierdzić, że początkowe budżety nie są ustalane wystarczająco precyzyjnie. Sprawia to, że zasoby budżetowe są związane, przez co nie są dostępne na bardziej dojrzałe projekty. |
| --- | --- |

51.

Kwestia niepełnego wykorzystania budżetu projektów została również poruszona przez Komitet Budżetowy EBC w jego sprawozdaniu oceniającym sprawozdanie z monitoringu budżetu EBC na koniec 2008 r. Wspomniano tam, że Komitet odnotował niewykorzystanie środków w wysokości 18 mln euro (28,8 %). Komitet uznał, że spowodowane było to przede wszystkim opóźnieniami w niektórych projektach i że wskazana jest poprawa planowania i realizacji projektów. Trybunał stwierdził, że opóźnienia w realizacji projektów istnieją (zob.
  załącznik
  ) i faktycznie mają wpływ na wykonanie budżetu. Zważywszy jednak, że zasoby przewidziane w początkowych planach były nadmierne, można stwierdzić, że początkowe budżety nie są ustalane wystarczająco precyzyjnie. Sprawia to, że zasoby budżetowe są związane, przez co nie są dostępne na bardziej dojrzałe projekty.

Jakościowa i ilościowa ocena korzyści

| 52. | Na zakończenie projektu przeprowadzana jest jakościowa i ilościowa ocena korzyści, które mają być osiągnięte w trakcie działania produktu końcowego. W tym kontekście należy wskazać przyczyny odstępstw od informacji przedstawionych w dokumencie przedłożenia projektu i wykorzystanych w trakcie procedury ustalania priorytetu oraz wyboru projektów. |
| --- | --- |

52.

Na zakończenie projektu przeprowadzana jest jakościowa i ilościowa ocena korzyści, które mają być osiągnięte w trakcie działania produktu końcowego. W tym kontekście należy wskazać przyczyny odstępstw od informacji przedstawionych w dokumencie przedłożenia projektu i wykorzystanych w trakcie procedury ustalania priorytetu oraz wyboru projektów.

| 53. | W przypadku wszystkich czterech projektów w sprawozdaniu z zakończenia projektu stwierdzono, że korzyści przedstawione w dokumencie przedłożenia projektu albo nadal pozostają w mocy, albo zostały osiągnięte. Szereg z tych korzyści może jednak zostać odpowiednio ocenionych dopiero po pewnym okresie funkcjonowania (zob. pkt 25). |
| --- | --- |

53.

W przypadku wszystkich czterech projektów w sprawozdaniu z zakończenia projektu stwierdzono, że korzyści przedstawione w dokumencie przedłożenia projektu albo nadal pozostają w mocy, albo zostały osiągnięte. Szereg z tych korzyści może jednak zostać odpowiednio ocenionych dopiero po pewnym okresie funkcjonowania (zob. pkt 25).

| 54. | W przypadku MDP projekt wykroczył poza wyłącznie potwierdzenie początkowej oceny przedstawionej w dokumencie przedłożenia projektu. Kolejnej oceny dokonano z zastosowaniem innej metodyki. Na jej podstawie oceniono korzyści z końcowego produktu według czterech wymiarów określonych w zrównoważonej karcie wyników, która zawierała pozytywne i negatywne wskaźniki. Celem było zatem przedstawienie rzetelnej oceny wyników projektu. Była to pozytywna inicjatywa, która mogłaby być uznana za dobrą praktykę w przyszłych projektach. Fragmenty tej oceny przedstawiono w ramce 1: |
| --- | --- |

54.

W przypadku MDP projekt wykroczył poza wyłącznie potwierdzenie początkowej oceny przedstawionej w dokumencie przedłożenia projektu. Kolejnej oceny dokonano z zastosowaniem innej metodyki. Na jej podstawie oceniono korzyści z końcowego produktu według czterech wymiarów określonych w zrównoważonej karcie wyników, która zawierała pozytywne i negatywne wskaźniki. Celem było zatem przedstawienie rzetelnej oceny wyników projektu. Była to pozytywna inicjatywa, która mogłaby być uznana za dobrą praktykę w przyszłych projektach. Fragmenty tej oceny przedstawiono w ramce 1:

Ramka 1 –   Ocena jakościowych i ilościowych korzyści z MDP na zakończenie projektu (fragmenty)

| — | Kwestie finansowe: (pozytywne) projekt został zrealizowany w ramach budżetu, (negatywne) koszt wynagrodzenia za konsultacje dotyczące opracowania rozwiązania ocenia się jako wyższy od stawek rynkowych. |
| --- | --- |

—

Kwestie finansowe: (pozytywne) projekt został zrealizowany w ramach budżetu, (negatywne) koszt wynagrodzenia za konsultacje dotyczące opracowania rozwiązania ocenia się jako wyższy od stawek rynkowych.

| — | Innowacyjność: (pozytywne) projekt przyczynił się do opracowania systemu monitorowania wspierającego umowę o gwarantowanym poziomie usług, (negatywne) projekt wprowadził nowe narzędzie z autorską bazą danych, które jest dosyć złożone i nie tak elastyczne, jak wcześniej stosowane. |
| --- | --- |

—

Innowacyjność: (pozytywne) projekt przyczynił się do opracowania systemu monitorowania wspierającego umowę o gwarantowanym poziomie usług, (negatywne) projekt wprowadził nowe narzędzie z autorską bazą danych, które jest dosyć złożone i nie tak elastyczne, jak wcześniej stosowane.

| — | Organizacja: (pozytywne) projekt przyczynił się do ustanowienia strategii dotyczącej wykorzystania danych rynkowych. |
| --- | --- |

—

Organizacja: (pozytywne) projekt przyczynił się do ustanowienia strategii dotyczącej wykorzystania danych rynkowych.

| — | Klienci: (pozytywne) projekt umożliwił włączenie danych Bloomberga, (negatywne) użyteczność rozwiązania została oceniona poniżej oczekiwań. |
| --- | --- |

—

Klienci: (pozytywne) projekt umożliwił włączenie danych Bloomberga, (negatywne) użyteczność rozwiązania została oceniona poniżej oczekiwań.

Sprawozdanie dotyczące wyciągniętych wniosków

| 55. | POCP stanowi, że sprawozdanie dotyczące wyciągniętych wniosków powinno zostać załączone do sprawozdania z zakończenia projektu. Ma to zagwarantować, że doświadczenia z realizacji danego projektu zostaną udostępnione całej organizacji, tak aby mogły zostać wykorzystane do poprawy zarządzania przyszłymi projektami. |
| --- | --- |

55.

POCP stanowi, że sprawozdanie dotyczące wyciągniętych wniosków powinno zostać załączone do sprawozdania z zakończenia projektu. Ma to zagwarantować, że doświadczenia z realizacji danego projektu zostaną udostępnione całej organizacji, tak aby mogły zostać wykorzystane do poprawy zarządzania przyszłymi projektami.

| 56. | Mimo że do wszystkich czterech sprawozdań z zakończenia projektu dołączono sprawozdanie dotyczące wyciągniętych wniosków, standard ich zawartości był różny. W przypadku EER kwestie ujęte jako wyciągnięte wnioski sprawiają wrażenie, że zostały uwzględnione, aby zademonstrować przykład dobrego zarządzania, a nie żeby wskazać sposób lepszego postępowania w takim przypadku w przyszłości. W przypadku MAU przedstawiono zbyt wiele szczegółów, co rozmyło przekaz o wnioskach wyciągniętych na użytek przyszłych projektów. |
| --- | --- |

56.

Mimo że do wszystkich czterech sprawozdań z zakończenia projektu dołączono sprawozdanie dotyczące wyciągniętych wniosków, standard ich zawartości był różny. W przypadku EER kwestie ujęte jako wyciągnięte wnioski sprawiają wrażenie, że zostały uwzględnione, aby zademonstrować przykład dobrego zarządzania, a nie żeby wskazać sposób lepszego postępowania w takim przypadku w przyszłości. W przypadku MAU przedstawiono zbyt wiele szczegółów, co rozmyło przekaz o wnioskach wyciągniętych na użytek przyszłych projektów.

| 57. | W przypadku projektów MDP i TCRTO zidentyfikowano kwestie, które faktycznie mają znaczenie dla przyszłych procedur zarządzania projektami EBC. Fragmenty kwestii opisanych w sprawozdaniu dotyczącym MDP przedstawiono w ramce 2: |
| --- | --- |

57.

W przypadku projektów MDP i TCRTO zidentyfikowano kwestie, które faktycznie mają znaczenie dla przyszłych procedur zarządzania projektami EBC. Fragmenty kwestii opisanych w sprawozdaniu dotyczącym MDP przedstawiono w ramce 2:

Ramka 2 –   Wyciągnięte wnioski przedstawione w sprawozdaniu z zakończenia projektu MDP (fragmenty)

| — | Podkreślenie wagi fazy przygotowawczej, szczególnie w zakresie określenia wymogów użytkowników. Na przyszłość sugeruje się włączenie końcowego użytkownika w podejmowanie decyzji o wyborze rozwiązania. |
| --- | --- |

—

Podkreślenie wagi fazy przygotowawczej, szczególnie w zakresie określenia wymogów użytkowników. Na przyszłość sugeruje się włączenie końcowego użytkownika w podejmowanie decyzji o wyborze rozwiązania.

| — | Podkreślenie wagi zaangażowania i rozliczalności użytkownika: bez jasnej odpowiedzialności użytkownik może nie być w pełni świadomy znaczenia swojego zaangażowania w projektowanie i testowanie rozwiązania. |
| --- | --- |

—

Podkreślenie wagi zaangażowania i rozliczalności użytkownika: bez jasnej odpowiedzialności użytkownik może nie być w pełni świadomy znaczenia swojego zaangażowania w projektowanie i testowanie rozwiązania.

| — | Podkreślenie wagi testowania produktów każdej fazy. |
| --- | --- |

—

Podkreślenie wagi testowania produktów każdej fazy.

| — | Planowanie zasobów zgodnie z priorytetem projektów: ze względu na konflikt z innym produktem dla tej samej dyrekcji, podczas każdej fazy testowania brakowało zasobów. |
| --- | --- |

—

Planowanie zasobów zgodnie z priorytetem projektów: ze względu na konflikt z innym produktem dla tej samej dyrekcji, podczas każdej fazy testowania brakowało zasobów.

| — | Uwzględnienie portalu projektu jako skutecznego narzędzia dzielenia się wiedzą: centralny, przyjazny użytkownikowi punkt dostępu do wszystkich informacji o projekcie był bardzo użyteczny. |
| --- | --- |

—

Uwzględnienie portalu projektu jako skutecznego narzędzia dzielenia się wiedzą: centralny, przyjazny użytkownikowi punkt dostępu do wszystkich informacji o projekcie był bardzo użyteczny.

| 58. | Ponadto, chociaż wyciągnięte wnioski są dostępne dla innych kierowników projektu w sprawozdaniu z zakończenia projektu, kwestie uznawane za istotne z punktu widzenia całej organizacji i które mogłyby poprawić dzielenie się doświadczeniem pomiędzy kierownikami projektu nie zostały zidentyfikowane i nie były aktywnie upowszechniane. |
| --- | --- |

58.

Ponadto, chociaż wyciągnięte wnioski są dostępne dla innych kierowników projektu w sprawozdaniu z zakończenia projektu, kwestie uznawane za istotne z punktu widzenia całej organizacji i które mogłyby poprawić dzielenie się doświadczeniem pomiędzy kierownikami projektu nie zostały zidentyfikowane i nie były aktywnie upowszechniane.

WNIOSKI I ZALECENIA

Czy EBC posiadał stosowny system zarządzania realizowanymi przez siebie projektami IT?

| 59. | EBC ustanowił system zarządzania projektami IT, jednak istnieją pewne możliwości poprawy. |
| --- | --- |

59.

EBC ustanowił system zarządzania projektami IT, jednak istnieją pewne możliwości poprawy.

| 60. | EBC nie wprowadził wieloletniej strategii IT formalnie wyznaczającej cele strategiczne i średniookresowe. W 2008 r. EBC rozpoczął strategiczny przegląd swoich działań IT. Ma on zakończyć się przygotowaniem strategii IT. |
| --- | --- |

60.

EBC nie wprowadził wieloletniej strategii IT formalnie wyznaczającej cele strategiczne i średniookresowe. W 2008 r. EBC rozpoczął strategiczny przegląd swoich działań IT. Ma on zakończyć się przygotowaniem strategii IT.

| 61. | W odniesieniu do planowania rocznego Dyrekcja Generalna Systemów Informatycznych nie przedstawiła szczegółów dotyczących zasobów finansowych koniecznych do osiągnięcia jej celów i realizacji wybranych działań. |
| --- | --- |

61.

W odniesieniu do planowania rocznego Dyrekcja Generalna Systemów Informatycznych nie przedstawiła szczegółów dotyczących zasobów finansowych koniecznych do osiągnięcia jej celów i realizacji wybranych działań.

| 62. | EBC poprawił w 2008 r. proces wyboru projektów. Jednakże dyrekcjom nie ujawniono zastosowanych kryteriów oceny. |
| --- | --- |

62.

EBC poprawił w 2008 r. proces wyboru projektów. Jednakże dyrekcjom nie ujawniono zastosowanych kryteriów oceny.

| 63. | Procedury EBC dotyczące zarządzania projektami IT w dużym stopniu pokrywają się z najlepszą praktyką. Stwierdzono uchybienia w obszarach analizy zainteresowanych podmiotów i oceny ex post oddziaływania projektu. |
| --- | --- |

63.

Procedury EBC dotyczące zarządzania projektami IT w dużym stopniu pokrywają się z najlepszą praktyką. Stwierdzono uchybienia w obszarach analizy zainteresowanych podmiotów i oceny ex post oddziaływania projektu.

Zalecenia (dotyczące pierwszego pytania kontrolnego)

| 1. | EBC powinien formalnie ustanowić wieloletnią strategię IT, która powinna być stosowana jako skuteczne narzędzie zarządzania działaniami w zakresie IT. |
| --- | --- |

1.

EBC powinien formalnie ustanowić wieloletnią strategię IT, która powinna być stosowana jako skuteczne narzędzie zarządzania działaniami w zakresie IT.

| 2. | EBC powinien wprowadzić dalsze usprawnienia do rocznego planowania w zakresie IT, dzięki opracowaniu kompleksowego dokumentu wyznaczającego cele i określającego wskaźniki umożliwiające pomiar ich wykonania. Cele powinny być podzielone według poszczególnych działań, ze wskazaniem zasobów finansowych koniecznych do ich osiągnięcia. |
| --- | --- |

2.

EBC powinien wprowadzić dalsze usprawnienia do rocznego planowania w zakresie IT, dzięki opracowaniu kompleksowego dokumentu wyznaczającego cele i określającego wskaźniki umożliwiające pomiar ich wykonania. Cele powinny być podzielone według poszczególnych działań, ze wskazaniem zasobów finansowych koniecznych do ich osiągnięcia.

| 3. | EBC powinno włączyć do procedur zarządzania projektem analizę zainteresowanych podmiotów i ocenę ex post oddziaływania projektu. |
| --- | --- |

3.

EBC powinno włączyć do procedur zarządzania projektem analizę zainteresowanych podmiotów i ocenę ex post oddziaływania projektu.

Czy ustalony system zarządzania projektami IT był stosowany zgodnie z założeniami?

| 64. | Ogólnie EBC stosował ustalony system zarządzania projektami IT zgodnie z założeniami. Wszystkie skontrolowane projekty były stosownie zaakceptowane na etapie planowania poprzez zatwierdzenie dokumentu przedłożenia projektu. Jednakże stwierdzono uchybienia w obszarze oceny ryzyka projektu, dotyczące braku szczegółowości tej oceny oraz wspólnego podejścia do oceny. Ponadto ustalone w początkowych planach budżety nie były określone dostatecznie precyzyjnie. |
| --- | --- |

64.

Ogólnie EBC stosował ustalony system zarządzania projektami IT zgodnie z założeniami. Wszystkie skontrolowane projekty były stosownie zaakceptowane na etapie planowania poprzez zatwierdzenie dokumentu przedłożenia projektu. Jednakże stwierdzono uchybienia w obszarze oceny ryzyka projektu, dotyczące braku szczegółowości tej oceny oraz wspólnego podejścia do oceny. Ponadto ustalone w początkowych planach budżety nie były określone dostatecznie precyzyjnie.

| 65. | Trybunał stwierdził, że podczas realizacji trzech projektów brakowało wyspecjalizowanych zasobów, co spowodowało opóźnienia. |
| --- | --- |

65.

Trybunał stwierdził, że podczas realizacji trzech projektów brakowało wyspecjalizowanych zasobów, co spowodowało opóźnienia.

| 66. | Ogólnie EBC ustanowił odpowiednie narzędzia i systemy informacji zarządczej umożliwiające monitorowanie projektów IT. Jednakże zasoby kadrowe wykorzystane podczas projektów IT są monitorowane tylko częściowo. |
| --- | --- |

66.

Ogólnie EBC ustanowił odpowiednie narzędzia i systemy informacji zarządczej umożliwiające monitorowanie projektów IT. Jednakże zasoby kadrowe wykorzystane podczas projektów IT są monitorowane tylko częściowo.

| 67. | W końcowej fazie realizacji projektu przeprowadzana jest formalna ocena w ramach sprawozdania z zakończenia projektu, obejmująca wszystkie główne kwestie istotne na tym etapie. Jednakże tylko jeden z sześciu projektów został zamknięty w terminie przewidzianym w dokumencie przedłożenia projektu. |
| --- | --- |

67.

W końcowej fazie realizacji projektu przeprowadzana jest formalna ocena w ramach sprawozdania z zakończenia projektu, obejmująca wszystkie główne kwestie istotne na tym etapie. Jednakże tylko jeden z sześciu projektów został zamknięty w terminie przewidzianym w dokumencie przedłożenia projektu.

| 68. | Zalecenia Trybunału są następujące:

  Zalecenia (dotyczące drugiego pytania kontrolnego)







  4. | Należy poprawić planowanie zasobów, aby zagwarantować dostępność w odpowiednim czasie wszystkich wyspecjalizowanych zasobów niezbędnych podczas realizacji projektu oraz bardziej rygorystyczne określanie budżetu. |
| --- | --- | --- |

68.

Zalecenia Trybunału są następujące:

Zalecenia (dotyczące drugiego pytania kontrolnego)

4.

Należy poprawić planowanie zasobów, aby zagwarantować dostępność w odpowiednim czasie wszystkich wyspecjalizowanych zasobów niezbędnych podczas realizacji projektu oraz bardziej rygorystyczne określanie budżetu.

| 5. | Należy dodatkowo poprawić koordynację pomiędzy DG-IS i dyrekcjami, aby móc osiągnąć porozumienie w sprawie SLA bardziej terminowo. |
| --- | --- |

5.

Należy dodatkowo poprawić koordynację pomiędzy DG-IS i dyrekcjami, aby móc osiągnąć porozumienie w sprawie SLA bardziej terminowo.

| 6. | Sprawozdanie dotyczące wyciągniętych wniosków powinno mieć na celu określenie możliwości poprawy na potrzeby przyszłych projektów, o których to możliwościach należy aktywnie informować wszystkich kierowników projektu. |
| --- | --- |

6.

Sprawozdanie dotyczące wyciągniętych wniosków powinno mieć na celu określenie możliwości poprawy na potrzeby przyszłych projektów, o których to możliwościach należy aktywnie informować wszystkich kierowników projektu.

Niniejsze sprawozdanie zostało przyjęte przez Trybunał Obrachunkowy w Luksemburgu na posiedzeniu w dniu 10 grudnia 2009 r.

W imieniu Trybunału Obrachunkowego

Vítor Manuel da SILVA CALDEIRA

Prezes

---

(1)  Art. 105 ust. 1 Traktatu ustanawiającego Wspólnotę Europejską, obecnie art. 127 ust. 1 Traktatu o funkcjonowaniu Unii Europejskiej.

1

(2)  Statut ESBC oraz EBC jest protokołem załączonym do Traktatu.

2

(3)  Art. 27 ust. 2 stanowi: „Postanowienia artykułu 248 Traktatu stosują się tylko do badania skuteczności zarządzania EBC”. Postanowienia instytucjonalne odnoszące się do Europejskiego Banku Centralnego zawarte są w art. 112–115 traktatu WE, obecnie art. 283, 294, 134 i 135 Traktatu o funkcjonowaniu Unii Europejskiej.

3

(4)  EBC podzielony jest na 17 dyrekcji o obszarach działalności odzwierciedlających pełny zakres funkcji banku. Na czele każdej dyrekcji, z wyjątkiem Zespołu Doradców Zarządu i Przedstawicielstwa EBC w Waszyngtonie, stoi członek wyższej kadry zarządzającej (dyrektor generalny lub dyrektor), który podlega jednemu z członków Zarządu.

4

(5)  Chodzi tu o projekty EBC dotyczące zasobów IT, w odniesieniu do których zarządzanie projektami odbywa się w ramach odnośnej dyrekcji oraz Dyrekcji Generalnej Systemów Informatycznych.

5

(6)  POCP ostatnio zaktualizowano w 2006 r.

6

(7)  PMBOK określa standardy i wytyczne, które są powszechnie uznawane za najlepszą praktykę i które są stosowane również przez EBC jako standard dla jego procedur zarządzania projektami.

7

(8)  Na przykład: ściślejsze powiązanie podstawowych działań z IT oraz przejście od podejścia projektowego do podejścia programowego.

8

(9)  Na przykład: przyjęcie najlepszych praktyk dotyczących realizacji projektów i procesu zarządzania oraz realizacja projektów IT zgodnie z uzgodnionymi kosztami, czasem i jakością obejmującą przyjazność dla użytkownika.

9

(10)  Pierwszy filar: standardowe pytania (22 parametry), drugi filar: zagregowana analiza w klastrach oraz trzeci filar: zagregowane kryteria ustalania priorytetów na poziomie EBC na potrzeby podjęcia ostatecznej decyzji.

10

(11)  Dyrekcja Projektów Informatycznych podzielona jest na pięć dziedzin. Każda dziedzina odpowiada za projekty zainicjowane przez różne dyrekcje.

11

(12)  Z POCP wyłączone są małe zadania, projekty, które realizowane są w ramach jednej dyrekcji lub też niewymagające żadnych rozwiązań informatycznych, a także zadania związane z infrastrukturą IT o niskim zakresie testowania, niskim poziomie innowacyjności, niskim wpływie organizacyjnym, w wyniku których nie powstaje nowa usługa. Wszystkie projekty wybrane do szczegółowej kontroli Trybunału wchodziły w zakres POCP.

12

(13)  Zgodnie z częścią 2.2 PMBOK jest to konieczne ze względu na zapewnienie powodzenia projektu. W PMBOK stwierdza się dalej, że fakt niezidentyfikowania kluczowego zainteresowanego podmiotu może mieć negatywny wpływ na projekt. W części 10.1 PMBOK dotyczącej komunikacji w ramach projektu stwierdzono, że zidentyfikowanie potrzeb zainteresowanych podmiotów oraz określenie odpowiednich sposobów zaspokojenia tych potrzeb jest ważnym czynnikiem powodzenia projektu.

13

(14)  Fazy rozpoczęcia, przygotowania i realizacji projektu.

14

(15)  TCERTO, Target 2 SSP i EER.

15

(16)  MDP, MPIDS i MAU.

16

(17)  MDP, MPIDS i Target 2 SSP.

17

(18)  W dokumencie rozpoczęcia projektu, dokumencie przygotowania projektu i dokumencie przedłożenia projektu.

18

(19)  TCERTO, MAU i EER.

19

(20)  Etap 3 został wybrany do kontroli Trybunału.

20

(21)  MDP i TCERTO.

21

---

ZAŁĄCZNIK

Zestawienie projektów zbadanych przez Europejski Trybunał Obrachunkowy

| Projekt | Czas realizacji projektu | Koszty projektu (w euro) | |
| --- | --- | --- | --- |
| Termin rozpoczęcia realizacji | Planowany termin przedstawienia produktów | Planowany termin zakończenia projektu | Faktyczny termin przedstawienia produktów | Faktyczny termin zakończenia projektu | Zabudżetowane zasoby ogółem | Faktyczne zasoby ogółem | Różnica |
| 1) | Main computer rooms Area Upgrade at the Eurotower building (MAU) |

Projekt

Czas realizacji projektu

Koszty projektu (w euro)

Termin rozpoczęcia realizacji

Planowany termin przedstawienia produktów

Planowany termin zakończenia projektu

Faktyczny termin przedstawienia produktów

Faktyczny termin zakończenia projektu

Zabudżetowane zasoby ogółem

Faktyczne zasoby ogółem

Różnica

1)

Main computer rooms Area Upgrade at the Eurotower building (MAU)

28.6.2007

3.3.2008

18.4.2008

4.9.2008

2.12.2008

1 406 644

1 363 336

–43 308

–3,1 %

| 2) | ECBLAN Eurotower Refresh (EER) |
| --- | --- |

2)

ECBLAN Eurotower Refresh (EER)

1.7.2006

13.4.2007

25.5.2007

15.2.2007

30.3.2007

1 158 692

1 014 359

– 144 333

–12,5 %

| 3) | Teleconference, CoreNet, ESCB-Net enlargement to Bulgaria and Romania (TCERTO) |
| --- | --- |

3)

Teleconference, CoreNet, ESCB-Net enlargement to Bulgaria and Romania (TCERTO)

1.3.2006

16.10.2006

19.1.2007

28.3.2007

27.6.2007

2 060 927

1 594 595

– 466 332

–22,6 %

| 4) | Monetary Policy Implementation Decision support System Phase 3 (MPIDS) |
| --- | --- |

4)

Monetary Policy Implementation Decision support System Phase 3 (MPIDS)

1.3.2007

20.11.2007

29.2.2008

do uzupełnienia przez EBC

do uzupełnienia przez EBC

790 192

do uzupełnienia przez EBC

—

—

| 5) | Market data Provision (MDP) |
| --- | --- |

5)

Market data Provision (MDP)

2.1.2007

30.9.2007

30.11.2007

31.12.2007

14.2.2008

1 859 379

1 458 105

- 401 274

-21,6 %

| 6) | ECB Integration with the Target 2 Single Shared Platform (Target 2 SSP) |
| --- | --- |

6)

ECB Integration with the Target 2 Single Shared Platform (Target 2 SSP)

15.5.2006

20.5.2008

8.8.2008

18.5.2008

15.4.2009

508 387

540 339

+31 952

+6,3 %

---

ODPOWIEDŹ EUROPEJSKIEGO BANKU CENTRALNEGO

Europejski Bank Centralny (EBC) z zadowoleniem przyjmuje sprawozdanie Europejskiego Trybunału Obrachunkowego za rok budżetowy 2007 i dziękuje za zgłoszone przez Trybunał uwagi i propozycje ulepszeń. EBC pragnie też odnotować fakt uznania przez Trybunał, że: i) EBC ustanowił system zarządzania projektami informatycznymi; ii) procedury EBC dotyczące zarządzania projektami informatycznymi w dużym stopniu pokrywają się z najlepszą praktyką; iii) ogólnie EBC stosował ustalony system zarządzania projektami informatycznymi zgodnie z założeniami.

EBC przyjmuje do wiadomości zgłoszone przez Trybunał uwagi i propozycje ulepszeń. Poniżej przedstawiono odpowiedzi EBC na wybrane punkty sprawozdania i sześć zaleceń Trybunału.

Punkty 12, 13 i 60

EBC uważa, że wprowadzony przez niego wieloletni portfel projektów informatycznych jest powiązany ze strategicznymi celami całego EBC i poszczególnych jego dyrekcji. Podstawę do definiowania nowych projektów stanowią ogólne priorytety EBC, określone w piśmie Prezesa oraz w strategicznych wytycznych poszczególnych dyrekcji. Każdy projekt wymaga przedstawienia strategicznego uzasadnienia biznesowego, zawierającego szczegółowe informacje dotyczące zgodności ze średniookresowymi celami strategicznymi EBC i danej dyrekcji. Projekty informatyczne są następnie regularnie oceniane i szeregowane według ważności podczas corocznej aktualizacji portfela.

W kwestii wieloletniej strategii informatycznej, mającej dużo szerszy zakres niż portfel projektów informatycznych, EBC zwraca uwagę na fakt, że w lipcu 2008 r. rozpoczęto strategiczny przegląd systemów informatycznych. W grudniu 2008 r. zatwierdzono strategiczne wymagania biznesowe określone w pierwszej fazie przeglądu, a w styczniu 2009 r. przyjęto dokument w sprawie strategicznego ukierunkowania systemów informatycznych. Następnie na podstawie strategicznego ukierunkowania systemów informatycznych oraz strategicznych wymagań biznesowych opracowano strategiczny plan działań informatycznych na lata 2009–2013. W maju 2009 r. zatwierdzono cele strategiczne i związane z nimi inicjatywy informatyczne (druga faza przeglądu). W sierpniu 2009 r. zatwierdzono strategiczny plan działań informatycznych na lata 2009–2013 (trzecia faza przeglądu).

Punkty 18 i 61

Wytyczne strategiczne wyznaczają wieloletni kierunek strategii. Roczny program prac jest bardziej szczegółowy i stanowi podstawę do określania działań służących realizacji celów strategicznych, a także wymienia konkretne działania operacyjne. Szczegółowe informacje finansowe dotyczące wszystkich projektów zawarte są w różnych dokumentach zatwierdzających, poczynając od formularza rejestracyjnego projektu. Dla każdego działania w ramach projektu przedstawia się szczegółowe informacje nt. planów, aby zapewnić skuteczne planowanie i kontrolę.

W odniesieniu do działań niezwiązanych z projektami (np. działań operacyjnych w dziedzinie informatyki) planowanie i alokacja zasobów ludzkich i finansowych odbywają się w ramach sporządzania budżetu rocznego. Dodatkowo do planowania i alokacji zasobów ludzkich przydzielanych do Dyrekcji Generalnej Systemów Informatycznych na potrzeby projektów i działań operacyjnych wykorzystuje się system alokacji zasobów iRACT.

Punkt 24

EBC przyznaje, że procedury organizacji i kontroli projektów nie nakładają obowiązku formalnego dokumentowania analizy zainteresowanych stron. Sama analiza jest jednak prowadzona. Zainteresowane strony identyfikuje się na etapie rozpoczęcia projektu, którego wynikiem jest dokument rozpoczęcia projektu. Głównym celem etapu rozpoczęcia projektu jest skoncentrowanie się na problemie lub potrzebie biznesowej oraz możliwych rozwiązaniach, by na tej podstawie wskazać zainteresowane strony (czyli dyrekcje, których sprawa dotyczy) i potencjalnych wykonawców. W ramach przygotowania dokumentu rozpoczęcia projektu powstaje grupa sterująca projektu, w której skład wchodzą wszystkie zainteresowane strony lub ich przedstawiciele.

Punkt 38

Rozważając zaangażowanie tego usługodawcy zarówno na etapie opracowania projektu MPD, jak i do obsługi danych, EBC miał wyraźnie na uwadze zminimalizowanie całościowych kosztów i ryzyka, zarówno związanych z rozwojem, jak i operacyjnych, a nie tylko ich części (tj. kosztów rozwoju). Uzyskane wyniki pozwoliły zoptymalizować całkowity koszt właścicielski oraz zmniejszyć ryzyko związane z projektem (czyli z wykonawcą, gdyż ryzyko związane z zarządzaniem różnymi dostawcami oprogramowania i zbiorów danych zostało wyeliminowane).

EBC przyznaje, że opracowanie oprogramowania nie należało do podstawowej działalności wykonawcy. Dlatego zlecone prace rozwojowe ograniczały się do funkcji niezbędnych do integracji podstawowego rozwiązania, a w kolejnych etapach cyklu projektowego prowadzono więcej testów w celu zapewnienia wysokiej jakości produktów.

Zalecenie 1

EBC uważa, że posiadał odpowiedni system zarządzania projektami informatycznymi, obejmujący wyznaczanie wieloletnich celów strategicznych i powiązanie z portfelem projektów informatycznych. EBC zgadza się co do znaczenia wieloletniej strategii informatycznej, obejmującej całość działalności informatycznej, a nie tylko projekty. Dlatego właśnie EBC wprowadził strategiczny plan działań informatycznych, począwszy od roku 2009. W wyniku strategicznego przeglądu systemów informatycznych, rozpoczętego w lipcu 2008 r., opracowano strategiczny plan działań informatycznych na lata 2009–2013. W maju 2009 r. zatwierdzono cele strategiczne i związane z nimi inicjatywy informatyczne (druga faza przeglądu), zaś w sierpniu 2009 r. zatwierdzono strategiczny plan działań informatycznych na lata 2009–2013 (trzecia faza przeglądu).

Zalecenie 2

Zgodnie z uwagami dotyczącymi punktów 18 i 61 raportu ECA EBC jest zdania, że istniejący system zarządzania projektami informatycznymi, służący do planowania, alokacji zasobów i monitorowania postępów, jest odpowiedni. Dostępny jest kompleksowy dokument dotyczący całości działalności informatycznej, w tym działań niezwiązanych z projektami, który przedstawia cele, zadania, wskaźniki wykonania i konkretne działania; możliwe ulepszenia dotyczą ewentualnie wyraźniejszego powiązania poszczególnych działań z właściwymi kosztami.

Zalecenia 3, 4 i 5

EBC przyjmuje zalecenia 3, 4 i 5.

Zalecenie 6

EBC zaczął już tworzyć bazę danych/rejestr wyciągniętych wniosków, na użytek kierowników i grup sterujących projektów. Będzie z nich też korzystać Dyrekcja Generalna Kadr przy sporządzaniu oceny projektu dla Komitetu Sterującego.

Wdrożenie zaleceń

Zalecenie 1 zostało już wdrożone. Zalecenie 2 zostało w większości wdrożone w 2008 r., a wdrożenie pozostałej części (jak wskazano powyżej) nastąpi przed końcem 2010 r. Zalecenia 3–6 zostaną wdrożone przed końcem 2010 r.

---