Sprawozdanie z kontroli skuteczności zarządzania Europejskim Bankiem Centralnym w roku budżetowym 2007 wraz z odpowiedziami Europejskiego Banku Centralnego.
Dz.U.UE.C.2010.32.1
Akt nienormatywny(2010/C 32/01)
(Dz.U.UE C z dnia 9 lutego 2010 r.)
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 rawozdanie 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.
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
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.
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?
– 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.
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.
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;
– skutecznie planował swoje działania związane z projektami IT w cyklu rocznym;
– stosował rzetelne kryteria wyboru do realizacji projektów IT; oraz
– 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.
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).
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.
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.
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ń.
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.
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.
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.
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
Notka Redakcji Systemu Informacji Prawnej LEX
Grafiki zostały zamieszczone wyłącznie w Internecie. Obejrzenie grafik podczas pracy z programem Lex wymaga dostępu do Internetu.
..................................................
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.
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.
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
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,
– 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
– 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.
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.
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ń.
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.
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.
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.
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.
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ć.
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.
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.
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;
iii) ilościowa i jakościowa ocena korzyści; oraz
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.
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.
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.
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.
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.
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.
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:
| 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. |
| - 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. |
| - 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.
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:
| 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 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. |
| - 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. |
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.
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ń.
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.
| 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. |
| 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. |
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.
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.
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. |
| 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. |
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.
(2) Statut ESBC oraz EBC jest protokołem załączonym do Traktatu.
(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.
(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.
(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.
(6) POCP ostatnio zaktualizowano w 2006 r.
(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.
(8) Na przykład: ściślejsze powiązanie podstawowych działań z IT oraz przejście od podejścia projektowego do podejścia programowego.
(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.
(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.
(11) Dyrekcja Projektów Informatycznych podzielona jest na pięć dziedzin. Każda dziedzina odpowiada za projekty zainicjowane przez różne dyrekcje.
(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.
(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.
(14) Fazy rozpoczęcia, przygotowania i realizacji projektu.
(15) TCERTO, Target 2 SSP i EER.
(16) MDP, MPIDS i MAU.
(17) MDP, MPIDS i Target 2 SSP.
(18) W dokumencie rozpoczęcia projektu, dokumencie przygotowania projektu i dokumencie przedłożenia projektu.
(19) TCERTO, MAU i EER.
(20) Etap 3 został wybrany do kontroli Trybunału.
(21) MDP i TCERTO.