9.2.2010   

LT

Europos Sąjungos oficialusis leidinys

C 32/1

COBIT

Informacinių ir susijusių technologijų kontrolės tikslai (Control Objectives for Information and related Technology)

DG H

Žmogiškųjų išteklių, biudžeto ir organizavimo generalinis direktoratas

DG IS

Informacinių sistemų generalinis direktoratas

ECB

Europos centrinis bankas

EER

ECBLAN Eurotower pastato atnaujinimas (ECBLAN Eurotower Refresh)

ECBS

Europos centrinių bankų sistema

IT

Informacinės technologijos

MAU

Eurotower pastato pagrindinių kompiuterių salių zonos modernizavimas (Main computer rooms Area Upgrade)

MDP

Rinkos duomenų rengimas (Market Data Provision)

MPIDS

Sistema, padedanti priimti pinigų politikos įgyvendinimo sprendimus (Monetary Policy Implementation Decision support System)

PMBOK

Su projektų valdymu susijusių žinių visuma (Project Management Body of Knowledge)

POCP

Projektų organizavimo ir kontrolės procedūros (Project Organisation and Control Procedures)

PVI

Projektų valdymo institutas

Target 2 SSP

Target 2 viena bendra platforma (Target 2 Single Shared Platform)

TCERTO

Telekonferencijos, CoreNet ir ECBS tinklo naudojimo išplėtimas apimant Bulgariją ir Rumuniją

1.

Europos centrinis bankas (ECB – „Bankas“) ir visų ES valstybių narių nacionaliniai centriniai bankai sudaro Europos centrinių bankų sistemą (ECBS). Pagrindinis ECBS tikslas – palaikyti kainų stabilumą. ECBS taip pat remia Sąjungos bendrąsias ekonominės politikos kryptis, kad padėtų siekti Sąjungos tikslų (1). Siekdamas šio tikslo, ECB atlieka savo statute (2) nustatytas užduotis ir yra atsakingas už savo veiklos ir finansų valdymą.

2.

Audito Rūmų atliekamas ECB veiklos efektyvumo auditas pagrįstas protokolo dėl ECBS ir ECB statuto 27 straipsnio 2 dalimi (3). Audito tema buvo 2007 ir 2008 finansiniais metais ECB vykdytas IT projektų valdymas. Taip pat buvo atsižvelgta į 2009 m. pirmojo ketvirčio ECB taikomos praktikos pokyčius.

3.

ECB biudžetas skirstomas į dvi pagrindines dalis: „banko veiklos vykdymo“ (ECB veiklos sričių veiklos išlaidos (4) ir „banko pertvarkos/statybos“ veiklą. Pastarąją sudaro dvi pagrindinės veiklos grupės:

4.

2007 m. su IT projektais (5) susijusios ECB išlaidos sudarė apie 20 milijonų eurų bendros 31 milijono eurų sumos, kuri buvo išleista visoms su projektais susijusios veiklos sritims finansuoti.

5.

Pagrindinis Audito Rūmų audito tikslas buvo įvertinti ECB vykdomą IT projektų valdymą atsakant į šiuos du audito klausimus:

6.

Audito metu buvo įvertintos įvairiuose IT projektų valdymo etapuose taikomos ECB taisyklės ir procedūros bei išnagrinėtas jų taikymas.

7.

Audito Rūmams vertinant, ar ECB buvo įdiegęs tinkamą valdymo sistemą, buvo nagrinėjami visi pagrindiniai su IT projektų valdymu susiję dokumentai ir procedūros. Pagrindinis dokumentas, naudojamas valdant projektus, yra Projektų organizavimo ir kontrolės procedūrų (POCP) dokumentas (6). Vertinant IT valdymo sistemos tinkamumą taip pat buvo vadovaujamasi tarptautiniu mastu pripažintais standartais ir geriausia praktika, kaip antai Projektų valdymo instituto (PVI) su projektų valdymu susijusių žinių visuma (PMBOK) (7) ir IT valdymo instituto informacinių ir susijusių technologijų kontrolės tikslais (COBIT).

8.

Buvo atliktas išsamus šešių IT projektų auditas siekiant įvertinti, ar taisyklės ir procedūros projektų lygmeniu buvo taikomos taip, kaip numatyta. Atrinktų projektų auditas buvo pagrįstas pokalbiais su projektų vadovais, projektų grupėmis ir galutiniais vartotojais bei atitinkamos projektų dokumentacijos analize.

9.

Sudarant imtį buvo remiamasi ECB biudžeto eilute „svarbiausi ECB projektai“. 2007 finansiniais metais ją sudarė 16 svarbiausių projektų, iš kurių keturiolika buvo susiję su informacinėmis technologijomis. Atranka buvo pagrįsta šiais kriterijais: i) projekto tipu, ii) projektui skirtu biudžetu ir iii) projekto užbaigimo etapu. Priede pateikta kiekvieno projekto aprašymo santrauka kartu su informacija apie projekto trukmę ir išlaidas.

10.

Atlikdami IT projektų valdymo sistemos auditą, Audito Rūmai nagrinėjo, ar ECB:

11.

Tam, kad ištekliai būtų veiksmingai panaudojami, turėtų būti nustatyta daugiametė su bendraisiais organizaciniais tikslais ir siekiais suderinta IT strategija. Ši strategija turėtų būti suformuluota pateikiant ilgamečio IT veiklos planavimo ir vykdymo gaires, kurios leistų nustatyti tinkamą IT išlaidų lygį jas sutelkiant tose srityse, kuriose jų labiausiai reikia. Ji turėtų būti grindžiama bendruoju IT poreikių įvertinimu, kuris sudarytų sąlygas priimti pagrįstus sprendimus, susijusius su intervencijos sričių prioritetų nustatymu.

12.

Audito Rūmai nustatė, kad ECB neturėjo daugiametės IT strategijos, kurioje būtų apibrėžti ir pateikti jo strateginiai tikslai ir IT vidutinės trukmės siekiai. Taip pat nebuvo atliktas oficialus bendrasis poreikių įvertinimas siekiant nustatyti intervencijos sričių prioritetus vidutinės trukmės laikotarpiu. Tačiau tiek Pirmininko raštas, tiek veiklos sričių strateginiai/veiklos metmenys yra naudojami kaip pagrindas nustatant naujus IT projektus, kurie tuomet yra išdėstomi pagal svarbą kasmet atnaujinant projektų paketą (žr. 19–21 dalis).

13.

2008 m. Informacinių sistemų generalinis direktoratas (DG IS) ir Žmogiškųjų išteklių, biudžeto ir organizavimo generalinis direktoratas (DG H), glaudžiai bendradarbiaudami su kitomis už ECB veiklos sritis atsakingomis tarnybomis, inicijavo strateginę ECB IT veiklos peržiūrą. Ši peržiūra Audito Rūmų audito atlikimo metu (2009 m. pirmąjį ketvirtį) dar nebuvo baigta. Pirmajame peržiūros etape buvo siekiama išsamiai išnagrinėti veiklos sričių tikslus ir siekius bei nustatyti jų strateginius veiklos poreikius, susijusius su ateinančių penkerių metų (2009–2013 m.) laikotarpio naujomis IT sistemomis, projektais ir paslaugomis. Šis etapas buvo užbaigtas 2008 m. gruodžio mėn. Tikimasi, kad užbaigus šį etapą bus suformuluota visas DG IS funkcijas (įskaitant IT projektus) apimanti IT strategija.

14.

Sudarant metinį IT projektų planavimo ciklą būtina nustatyti metinius tikslus, apibrėžti šiems tikslams pasiekti skirtus vykdytinus veiksmus bei nustatyti pagrindinius veiklos rezultatų įvertinimo rodiklius.

15.

2007 m. DG IS parengė 2007 m. skirtų strateginių/veiklos metmenų dokumentą, kuriame buvo išdėstyta nemažai plataus pobūdžio tikslų, kurių keletas buvo susiję su IT projektų valdymu (8). Tačiau jais remiantis nebuvo nustatyti konkretūs tikslai ir veiksmai bei nebuvo apibrėžti numatomi rezultatai.

16.

2008 m. DG IS parengė du planavimo dokumentus: bendruosius „2008 m. strateginius/veiklos metmenis“ ir „2008 m. darbo programą“. 2008 m. strateginiai/veiklos metmenys apėmė pagrindinių iššūkių, su kuriais DG IS susidūrė 2008 m., santrauką, tikslų apžvalgą ir 2008 m. pagrindinius veiklos rezultatų rodiklius. Kai kurie šių tikslų buvo susiję su IT projektų valdymu (9). Šių tikslų pasiekimas turėjo būti vertinamas taikant konkrečius kiekybinius pagrindinius veiklos rezultatų rodiklius, kuriems buvo nustatyti 2008 m. antrąjį ir ketvirtąjį ketvirtį siektini rezultatai.

17.

2008 m. darbo programoje buvo pateikta išsamesnė informacija apibrėžiant vykdytinus veiksmus, skirtus kiekvienam iš šių tikslų pasiekti. Tai – teigiamas pokytis palyginus su padėtimi 2007 m., kuris padidina planavimo proceso kokybę. Tačiau buvo pažymėta, kad 2008 m. darbo programoje buvo pateikta žymiai daugiau tikslų nei pirmiau minėtame 2008 m. strateginių/veiklos metmenų dokumente. Darbo programa nebuvo sudaryta taip, kad galima būtų plėtoti strateginių/veiklos metmenų dokumente nustatytus tikslus, konkrečiai įvardyti, kaip šie tikslai galėtų būti pasiekti ar įtraukti naujus tikslus.

18.

Galiausiai, nė vienas 2008 m. planavimo dokumentas nėra pakankamai išsamus, kad pasitarnautų kaip veiksminga planavimo priemonė. Be to, nėra nurodyta, kokių finansinių išteklių reikia kiekvienam tikslui pasiekti ir kiekvienam atrinktam veiksmui įgyvendinti.

19.

Esamų išteklių nepakanka visiems galimiems projektams kiekvienais metais finansuoti, todėl būtina nustatyti didžiausio prioriteto projektų atrankos procesą ir tokiu būdu optimaliausiai panaudoti esamus išteklius.

20.

2007 m. projektų suskirstymo pagal svarbą ir atrankos procesas buvo grindžiamas trejų metų vidutinės trukmės projektų paketo planu. Kiekvienais metais ECB, atsižvelgdamas į savo bendruosius tikslus, iš naujo įvertina visus projektus (tebevykdomus projektus, projektų sistemoje užregistruotus, bet dar nepradėtus vykdyti bei naujai užregistruotus projektus). Šis vidutinės trukmės planas atnaujinamas dukart per metus siekiant įtraukti naujai užregistruotus projektus ir atsižvelgti į kitus pokyčius. Projektų įvertinimas yra pagrįstas siūlomais projektų veiklos modeliais ir numatomu jiems skirtų išteklių panaudojimu. Nebuvo apibrėžti aiškūs prioritetų nustatymo kriterijai. Dėl šios priežasties projektų atranka buvo ne tokia objektyvi, o tai padidina riziką, kad esami ištekliai nebus optimaliausiai panaudoti.

21.

2008 m. buvo sukurta pagerinta projektų suskirstymo pagal svarbą metodika. Šią metodiką, pagrįstą „trijų ramsčių sąvoka“ (10), sudarė specialieji sričių (11) įvertinimai, kurie vėliau buvo konsoliduojami ECB lygmeniu. 2008 m. įdiegta IT projektų valdymo sistema suteikė pakankamai informacijos sprendimams priimti.

22.

ECB parengė Projektų organizavimo ir kontrolės procedūrų (POCP) dokumentą, kuriuo turi būti vadovaujamasi valdant visus projektus, įskaitant IT projektus (12). POCP dokumente pateikta išsami projekto apibrėžtis ir aiškiai nustatyta jo taikymo sritis. Jame taip pat nustatyta projektams taikoma organizacinė struktūra, įskaitant atitinkamų dalyvaujančių subjektų funkcijas ir atsakomybę.

23.

POCP dokumente apibrėžta projekto gyvavimo ciklo sąvoka leidžia nustatyti veiksmingą projektų kontrolės struktūrą, projektus suskirstant į loginius etapus ir nustatant tikslius sprendimų priėmimo tarpsnius (žr.  1 diagramą ). Atlikus POCP ir PMBOK lyginamąją analizę, paaiškėjo, kad POCP dokumentas didžia dalimi atitiko šią geriausią praktiką. Dvi sritys, kuriose POCP dokumentas galėtų būti patobulintas, tai – suinteresuotųjų šalių analizė ir projekto poveikio ex post įvertinimas. Esami trūkumai ir jų poveikis išsamiai apibūdinami tolesnėse dalyse.

24.

POCP dokumente nereikalaujama atlikti oficialios dokumentais paremtos suinteresuotųjų šalių analizės. Tai reiškia, kad projekto grupė neturi oficialiai nustatyti suinteresuotųjų šalių ir jų konkrečių su projektais susijusių poreikių (13). Tai, kad nėra oficialiai nustatomos visos suinteresuotosios šalys ir jų poreikiai, gali turėti neigiamos įtakos projekto sėkmei. Reikia pažymėti, kad patikrintų konkrečių projektų atveju buvo atsižvelgta į vartotojų poreikius (žr. 33 ir 36 dalis).

25.

Nėra numatytas projekto rezultatų ir poveikio ex post įvertinimas praėjus tam tikram projekto vykdymo laikotarpiui. Toks įvertinimas, be kita ko, leistų pareikšti oficialią nuomonę dėl gautos kokybinės ir kiekybinės naudos, kuri buvo numatyta projekto patvirtinimo dokumentuose, ir tokiu būdu padėtų planuoti būsimus projektus (žr. 53 dalį). Naujausias teigiamas pokytis šioje srityje buvo tai, kad buvo sukurtas naujas šablonas, pagal kurį reikalaujama kasmet pateikti galutinių vartotojų atsiliepimus apie IT projektus siekiant sužinoti, kiek jie yra patenkinti suteiktos paslaugos kokybe.

26.

Siekiant užtikrinti efektyvų ir rezultatyvų projektų įgyvendinimą būtina nustatyti jų valdymo sistemą, nurodant aiškius atskaitomybės santykius bei procese dalyvaujančių organizacinių darinių pareigas ir funkcijas.

27.

POCP dokumente nustatyta ECB projektų valdymui taikytina organizacinė struktūra, įskaitant atitinkamų dalyvaujančių subjektų funkcijas ir atsakomybę bei sandarą (žr.  2 diagramą ).

28.

POCP dokumente nustatyti aiškūs su projektų valdymo procesu susijusių organizacinių darinių atskaitomybės santykiai ir funkcijos. Projektų iniciatyvinis komitetas yra pagrindinis ECB vidaus sprendimų, susijusių su projektų suskirstymu pagal svarbą, planavimu, tvirtinimu ir priežiūra, priėmimo organas. POCP dokumente sukurta struktūra apima visas būtinas funkcijas; joje pateikiamos aiškios sprendimų priėmimo procedūros nurodant iš anksto apibrėžtas funkcijas ir atsakomybę.

29.

Tikrindami, kaip taikoma IT projektų valdymo sistema, Audito Rūmai nagrinėjo, ar ECB:

30.

Projektų planavimas yra tinkamas, kai atsižvelgiama į šiuos aspektus: i) bendruosius projekto tikslus ir apimtį, ii) siūlomą sprendimą, iii) pagrindinius projekto etapus ir siektinus rezultatus, iv) finansinius ir žmogiškuosius išteklius ir v) projekto grupę.

31.

Projekto teikimo dokumentas yra pagrindinis planavimo dokumentas (žr.  1 diagramą ). Šiuo dokumentu remiamasi priimant sprendimą, ar turėtų būti įgyvendintas su projektu susijęs pasirinktas sprendimas. Visų šešių patikrintų projektų atveju šis dokumentas buvo išsamus; jame buvo analizuojami visi pagrindiniai klausimai, kurie turi būti išnagrinėti tvirtinant projektą.

32.

Visiems projektams leidimai buvo suteikti laikantis POCP dokumente numatytų procedūrų. Prieš prasidedant kiekvienam iš trijų projekto etapų (14), oficialų sprendimą dėl tolesnės veiklos priėmė projektų iniciatyvinis komitetas. Trys projektai (15) buvo laikomi būtinais siekiant atitikti ECBS ar kitas taikomas normas. Kiti projektai (16) buvo atrinkti remiantis projektų suskirstymo pagal svarbą metodika. Visi projektai atitiko DG IS strateginius/veiklos metmenis arba bendrąsias atitinkamų veiklos sričių strategijas.

33.

Trijų patikrintų projektų atveju (17) planavimo etape vartotojų poreikiai buvo įvertinti ir paremti dokumentais. Kadangi kiti trys projektai buvo tik esamo tinklo išplėtimo (TCERTO) arba esamos infrastruktūros modernizavimo (EER ir MAU) dalis, vartotojai į planavimo etapą nebuvo įtraukti. MPIDS atveju projekto specifikacijos buvo parengtos taikant pakartotinai atliekamų testų metodą. Kadangi šis metodas nebuvo taikomas kiek įmanoma geriau, buvo vėlavimo atvejų, o testų variantai nebuvo pakankamai išsamiai parengti, kaip buvo tikėtasi.

34.

Rizika, kad nebus pasiekti projekto tikslai, turėtų būti pakankamai išsamiai nustatyta, o planavimo etape – struktūrizuota ir nuodugniai įvertinta atsižvelgiant į jos tikimybę bei galimą poveikį projekto tikslų pasiekimui.

35.

Į visų trijų planavimo dokumentų (18) šablonus įtraukta konkreti rizikos analizei skirta dalis. Ši dalis buvo užpildyta visuose projekto teikimo dokumentuose. Tačiau nebuvo taikomas bendras rizikos, su kuria galėjo būti susidurta vykdant projektus, nustatymo ir jos tikimybės bei poveikio vertinimo metodas. Atliekant įvertinimą buvo vadovaujamasi kiekvieno projekto vadovo patirtimi. Į MDP pradinį rizikos įvertinimą buvo įtraukta tik su išorės rangovais susijusi rizika. Vykdant projektus taip pat iškilo vidaus rizika, pavyzdžiui, su ištekliais susiję apribojimai. Kadangi šie veiksniai nebuvo pripažinti kaip rizika, planavimo etape nebuvo numatyti taisomieji veiksmai. MPIDS atveju projekto teikimo dokumente taip pat galėjo būti numatyti kiti rizikos veiksniai, kaip antai su projekto taikymo sritimi susijusių veiklos procesų sudėtingumas, tačiau šiame dokumente jie nebuvo paminėti.

36.

Trijų patikrintų projektų (19) atveju projektui įgyvendinti skirti ištekliai ir sukaupti įgūdžiai buvo pakankami. Kitų trijų projektų atveju buvo susidurta su specializuotų išteklių problema, nes jų nebuvo pakankamai skirta laiku. MDP atveju vartotojų paslaugomis ne visuomet buvo galima pasinaudoti, nes tuo pačiu metu turėjo būti užbaigtas kitas panašus projektas. Dėl to buvo projekto įgyvendinimo vėlavimo atvejų. MPIDS atveju projekto grupei nebuvo priskirtas verslo analitikas, o DG IS darbuotojai ne visuomet būdavo pasiekiami, kai to prireikdavo. Tris mėnesius buvo vėluojama vykdyti projektą dėl išorės vykdytojo paslaugų pirkimo. Vykdytoją pasamdžius, jis dažnai keitėsi, tokiu būdu iškilo su projekto įgyvendinimu susijusių problemų. Dėl savo sudėtingumo projektas buvo vykdomas skirtingais etapais (20). Nepavyko perduoti žinių iš antrojo etapo į trečiąjį etapą, kaip buvo planuota, nes daugelis pagrindinių ankstesnės projekto grupės narių, įskaitant projekto vadovą, trečiajame etape nebedirbo.

37.

Visų atrinktų projektų įgyvendinimo metu vartotojams buvo reguliariai suteikiama informacija. Daugelio projektų atveju vartotojai būdavo atstovaujami projekto iniciatyvinės grupės ir (arba) projekto grupės susitikimuose. Jiems taip pat būdavo teikiamos mėnesinės projekto padėties ataskaitos.

38.

MDP projekto atveju buvo suteiktas leidimas netaikyti ECB viešųjų pirkimų taisyklių remiantis tuo, kad šie viešieji pirkimai negalėjo būti atskirti nuo ankstesnio duomenų tiekėjo pasirinkimo. Tačiau programinės įrangos kūrimas ir palaikymas nebuvo šio tiekėjo pagrindinės veiklos dalis, todėl techninio aptarnavimo plėtra buvo brangesnė nei numatyta.

39.

Naujo ar pakeisto siektino IT elemento testavimas yra ECB procedūrų dalis ir turi būti atliktas prieš pradedant taikyti kiekvieną iš šių elementų. Visi šeši projektai buvo testuojami prieš pradedant juos vykdyti. Testus parengė projekto grupė, tačiau galutiniai vartotojai ne visuomet dalyvavo rengiant testus, dėl to nebuvo laiku įvardyti būtini patobulinimai.

40.

Projektų vadovai turėtų disponuoti pakankama ir patikima informacija, kad galėtų veiksmingai prižiūrėti įgyvendinamus projektus siekiant laiku aptikti ir išspręsti problemas.

41.

ECB savo IT projektams prižiūrėti naudoja keletą priemonių. Projektams skirtas laikas kartu su finansiniais duomenimis ir informacija apie pagrindinius projekto pasiekimus bei pasiektą pažangą atspindimi mėnesinėje projekto padėties ataskaitoje. Šios ataskaitos, kuriose buvo pateikta pakankamai informacijos, buvo reguliariai teikiamos visų šešių projektų įgyvendinimo metu. Tačiau buvo pažymėta, jog Target 2 SSP atveju kai kurios ataskaitos nebuvo parengtos dėl žmogiškųjų išteklių stygiaus.

42.

Vis dėlto pažymėtina, kad buvo registruojamas tik DG IS darbuotojų projektams skirtas laikas. Laikas, kurį projektams skyrė už veiklos sritis atsakingi darbuotojai ir nacionalinių centrinių bankų tarnautojai, yra tik apytikriai apskaičiuotas. Be to, paprastai viršvalandžiai nėra nuosekliai fiksuojami ar išvis neregistruojami, todėl priežiūra nėra pagrįsta išsamia ir tikslia su laiku susijusia informacija.

43.

Baigiant projektą turėtų būti atliktas oficialus projekto tikslų pasiekimo ir panaudotų išteklių įvertinimas. POCP dokumente numatyta, kad projekto užbaigimo ataskaita turi būti pateikta po to, kai sėkmingai pasiekiami visi įgyvendinimo etape numatyti rezultatai ir galutinį projekto produktą patvirtina už atitinkamą(-as) veiklos sritį(-is) atsakingos tarnybos, sistemos valdytojas ir DG IS operacijų skyrius. Tokiu būdu projekto užbaigimo ataskaita yra dokumentas, kuriuo remiantis suteikiamas oficialaus projekto užbaigimo patvirtinimas.

44.

Šis dokumentas yra išsamus, nes jame analizuojami visi svarbiausi klausimai, kurie turi būti išnagrinėti projekto užbaigimo metu. Jo pagrindinės dalys yra šios:

45.

Iki 2009 m. balandžio 15 d. buvo parengtos ir patvirtintos penkios iš šešių patikrintų projektų užbaigimo ataskaitos (žr.  Priedą ). POCP dokumente numatyta, kad paprastai projektas turi būti užbaigtas per tris mėnesius nuo galutinių projekto rezultatų patvirtinimo. Target 2 SSP projekto atveju veikla buvo pradėta vykdyti 2008 m. gegužės mėn., o projektas buvo užbaigtas 2009 m. balandžio 15 d. Taip buvo todėl, kad DG IS ir sistemos valdytojas negalėjo susitarti dėl paslaugų lygio susitarimo turinio. 2007 m. spalio mėn. įvykusiame projekto iniciatyvinės grupės susitikime buvo paminėta, kad paslaugų lygio susitarimas turi būti pasirašytas prieš pradedant eksploatuoti Target 2 SSP ir kad tai turi būti padaryta kiek įmanoma greičiau, kadangi aiškus lūkesčių ir paslaugų pateikimas bei komunikacija tarp operacijų skyriaus ir skirtingų vartotojų yra labai svarbūs. Taip pat ir MPIDS atveju projektas nebuvo užbaigtas, nes buvo labai vėluojama pasirašyti paslaugų lygio susitarimą.

46.

Baigiant projektą turėtų būti atliktas faktinių projekto rezultatų įvertinimas juos lyginant su patvirtinta jo apimtimi bei nustatytais tikslais. Įvertinime turėtų būti nagrinėjami pagrindiniai projekto etapai ir siektini rezultatai pagrindžiant bet kokius ženklius nukrypimus.

47.

Audito Rūmai išnagrinėjo visų keturių projektų, kurių projekto užbaigimo ataskaitos buvo patvirtintos iki 2009 m. kovo mėn. pabaigos, įvertinimus. Atliktuose įvertinimuose gauti rezultatai buvo lyginami su projekto teikimo dokumento pradiniu planu. Juose buvo nagrinėjamas kiekvienas suplanuotas pagrindinis etapas ir siektinas rezultatas, pateikiant visų svarbiausių plano nukrypimų paaiškinimus. Tačiau buvo nustatyta su dviem projektais (21) susijusių vėlavimo lyginant su pradiniu planu atvejų (žr.  Priedą ). Pagrindinės pateiktos priežastys buvo šios:

48.

MAU projekto atveju, nors akivaizdu, kad technine infrastruktūra buvo galima naudotis ir ji veikė daug anksčiau nei nurodyta projekto užbaigimo ataskaitoje, ją oficialiai patvirtinti ir perduoti buvo vėluojama šešis mėnesius.

49.

Projekto užbaigimo ataskaitoje nustatyta, kad turi būti atlikta planuojamų ir faktinių žmogiškųjų ir finansinių išteklių lyginamoji analizė. Visų keturių projektų užbaigimo ataskaitose tokia analizė buvo pateikta; jose buvo pateikti ir svarbiausių nukrypimų nuo plano paaiškinimai.

50.

Kiekvienam iš keturių projektų panaudoti faktiniai žmogiškieji ir finansiniai ištekliai buvo mažesni nei biudžete numatyti ištekliai. Faktinės išlaidos buvo 3 %–23 % mažesnės nei biudžete numatytos išlaidos (žr.  Priedą ). Buvo pateiktos kelios su konkrečiais projektais susijusios nepakankamą išlaidų lygį pagrindžiančios priežastys.

51.

Nepakankamo biudžete projektams numatytų lėšų panaudojimo klausimą taip pat iškėlė ECB biudžeto komitetas savo teikiamoje su ECB 2008 metų pabaigos biudžeto priežiūros ataskaita susijusioje įvertinimo ataskaitoje. Joje nurodyta, kad komitetas pažymėjo, jog liko nepanaudota 18 milijonų eurų (28,8 %). Komitetas manė, kad tai daugiausia lėmė su kai kuriais projektais susiję vėlavimo atvejai ir pareiškė, kad yra galimybių gerinti projektų planavimą ir įgyvendinimą. Audito Rūmai pažymėjo, kad yra projekto įgyvendinimo vėlavimo atvejų (žr.  Priedą ) ir kad jie išties turi įtakos biudžeto vykdymui. Tačiau tai, kad pradiniuose planuose numatyti ištekliai viršijo reikiamus išteklius, rodo, kad pradiniai biudžetai nesudaromi taip tiksliai, kaip turėtų būti sudaryti. Todėl prisiimami įsipareigojimai dėl biudžeto išteklių, kurių negalima panaudoti geriau parengtiems projektams vykdyti.

52.

Baigiant projektą atliekamas kokybinės ir kiekybinės naudos, kuri turi būti gauta galutinio produkto naudojimo metu, įvertinimas. Turėtų būti paaiškinti nukrypimai nuo projekto teikimo dokumente pateiktos informacijos, naudotos projektų suskirstymo pagal svarbą ir jų atrankos procedūros metu.

53.

Visų keturių projektų užbaigimo ataskaitose buvo nurodyta, kad projekto teikimo dokumente pateikta nauda liko galioti arba buvo gauta. Tačiau nemaža šios naudos dalis gali būti tinkamai įvertinta tik praėjus tam tikram veiklos laikotarpiui (žr. 25 dalį).

54.

MDP projekto atveju buvo ne vien tik patvirtintas į projekto teikimo dokumentą įtrauktas pradinis įvertinimas. Buvo atliktas kitas įvertinimas taikant skirtingą metodiką. Jame buvo vertinama galutinio produkto nauda ją lyginant su keturiomis dimensijomis, pateiktomis subalansuoto vertinimo lentelėse, apimančiose teigiamus ir neigiamus rodiklius. Tokiu būdu juo buvo siekiama teisingai įvertinti projekto išdavas. Tai buvo teigiama iniciatyva, kuri galėtų būti laikoma geros praktikos pavyzdžiu įgyvendinant būsimus projektus. 1 langelyje pateiktos šio įvertinimo ištraukos:

—

Finansai: projektas buvo įgyvendintas neviršijant skirto biudžeto ribų (teigiamas aspektas); laikoma, kad konsultavimo mokesčiai, sumokėti už sprendimo plėtojimą, yra didesni nei rinkos kaina (neigiamas aspektas).

—

Naujovės: projektas prisidėjo plėtojant paslaugų lygio susitarimo priežiūros sistemą (teigiamas aspektas); projektą įgyvendinus buvo įdiegta nauja patentuota duomenų bazė, kuria buvo gana sudėtinga naudotis ir kuri nėra tokia lanksti kaip jau naudotos sistemos (neigiamas aspektas).

—

Organizavimas: projektas prisidėjo nustatant rinkos duomenų naudojimo politiką (teigiamas aspektas).

—

Vartotojai: projektas sudarė sąlygas „Bloomberg“ duomenų integravimui (teigiamas aspektas); manoma, kad sprendimo pritaikymo galimybės neatitiko lūkesčių (neigiamas aspektas).

55.

POCP dokumente numatyta, kad ataskaita apie įgytą patirtį turėtų būti teikiama kaip projekto užbaigimo ataskaitos priedas. Tikslas – užtikrinti, kad visa organizacija galėtų pasinaudoti įgyvendinant konkrečius projektus įgyta patirtimi siekiant pagerinti būsimų projektų valdymą.

56.

Nors visose keturiose projekto užbaigimo ataskaitose buvo pateikta ataskaita apie įgytą patirtį, skyrėsi jos turinio lygis. Susidarė įspūdis, kad EER projekto atveju problemos, nagrinėtos kaip įgytos patirties dalis, į ataskaitą buvo įtrauktos tam, kad būtų įrodyta, jog jos buvo sėkmingai išspręstos, o ne siekiant nurodyti, kaip jos galėtų būti geriau sprendžiamos ateityje. MAU projekto atveju buvo pateikta pernelyg daug paaiškinimų, dėl to tapo neaiški įgytos patirties idėja, kurią būtų galima pritaikyti įgyvendinant būsimus projektus.

57.

MDP ir TCERTO projektų atveju buvo iškelti klausimai, turintys tiesioginės svarbos ateityje taikant ECB projektų valdymo procedūras. 2 langelyje pateiktos MDP projekto ataskaitoje paminėtų klausimų ištraukos:

—

Akcentuoti rengimo etapo svarbą, ypač vartotojų poreikių nustatymą. Siūloma ateityje galutiniams vartotojams suteikti daugiau galių nusprendžiant, koks sprendimas turėtų būti pasirinktas.

—

Akcentuoti vartotojo dalyvavimo ir atskaitomybės svarbą: neapibrėžus aiškios atsakomybės vartotojas gali ne visiškai suvokti savo dalyvavimo rengiant sprendimo koncepciją ir jį testuojant svarbos.

—

Akcentuoti siektinų rezultatų kiekviename etape testavimo svarbą.

—

Planuoti išteklius atsižvelgiant į projektų svarbą: vykdant projektą kiekviename testavimo etape buvo susidurta su išteklių trūkumu, kadangi tuo pačiu metu buvo siekiama kito tos pačios veiklos srities numatyto rezultato.

—

Traktuoti projekto portalą kaip veiksmingą žinių mainų priemonę: centrinis ir patogus vartotojui prieigos prie visos su projektu susijusios informacijos punktas buvo labai naudingas.

58.

Galiausiai, nors kiti projektų vadovai gali pasinaudoti įgyta patirtimi pasitelkę projektų užbaigimo ataskaitas, nebuvo įvardyti visos organizacijos mastu rūpimi klausimai, kurie galėtų pagerinti projektų vadovų patirties mainus, be to, informacija apie šiuos klausimus nebuvo aktyviai skleidžiama.

59.

ECB įdiegė savo IT projektams valdyti skirtą valdymo sistemą, tačiau yra galimybių ją tobulinti.

60.

ECB nenustatė daugiametės IT strategijos, kuri oficialiai apibrėžtų jo strateginius tikslus ir vidutinės trukmės siekius. 2008 m. ECB inicijavo strateginę savo IT veiklos peržiūrą. Tikimasi, kad ją užbaigus IT strategija bus suformuluota.

61.

Skirtingai nei ECB IT projektai, kuriems numatyti finansiniai ištekliai buvo apskaičiuoti, Informacinių sistemų generalinio direktorato metiniuose planavimo dokumentuose nebuvo pateikta išsami informacija, kokių finansinių išteklių reikia tikslams pasiekti ir atrinktiems veiksmams įgyvendinti.

62.

2008 m. ECB pagerino savo projektų atrankos procesą suteikdamas pakankamos informacijos sprendimams priimti.

63.

IT projektams valdyti skirtos ECB procedūros iš esmės atitinka geriausią praktiką. Buvo nustatyta su suinteresuotųjų šalių analize ir projekto poveikio ex post įvertinimu susijusių trūkumų.

1.

ECB turėtų oficialiai nustatyti daugiametę IT strategiją, kuri būtų naudojama kaip veiksminga IT veiklos valdymo priemonė;

2.

ECB ir toliau turėtų gerinti savo metinį IT planavimą sudarydamas išsamų dokumentą, kuriame būtų nustatyti tikslai ir apibrėžti šių tikslų pasiekimui vertinti skirti veiklos rezultatų rodikliai. Tikslai turėtų būti suskirstyti į konkrečius veiksmus nurodant finansinius išteklius, būtinus jiems pasiekti;

3.

ECB į savo projektų valdymo procedūras turėtų įtraukti suinteresuotųjų šalių analizę ir projekto poveikio ex post įvertinimą.

64.

Apskritai ECB taikė įdiegtą IT projektams valdyti skirtą valdymo sistemą taip, kaip buvo numatyta. Visiems tikrintiems projektams planavimo etape buvo suteikti tinkami leidimai juos vykdyti patvirtinant projekto teikimo dokumentą. Tačiau projekto rizikos įvertinimo srityje buvo nustatyta trūkumų, susijusių su atliekant įvertinimą teikiama nepakankamai išsamia informacija ir bendro vertinimo metodo nebuvimu. Be to, pradiniuose planuose nustatyti biudžetai nebuvo sudaryti taip tiksliai, kaip galėtų būti sudaryti.

65.

Audito Rūmai nustatė, kad trijų projektų įgyvendinimo metu buvo susidurta su specializuotų išteklių trūkumu, dėl to buvo vėlavimo atvejų.

66.

Apskritai ECB įdiegė tinkamas savo IT projektams prižiūrėti skirtas priemones ir valdymo informacines sistemas. Tačiau IT projektams naudojami žmogiškieji ištekliai yra tik iš dalies prižiūrimi.

67.

Projekto užbaigimo etape atliktas oficialus įvertinimas yra pateikiamas projekto užbaigimo ataskaitoje, į kurią įtraukti visi svarbiausi šiame etape nagrinėtini klausimai. Tačiau tik vienas projektas iš šešių buvo užbaigtas laikantis projekto teikimo dokumente numatytų terminų.

68.

Audito Rūmai rekomenduoja:

Rekomendacijos (antrasis audito klausimas)