ELEKTRONIKUS KÖZIGAZGATÁS OPERATÍV PROGRAM KÖZIGAZGATÁSI SZOLGÁLTATÁSOK ELEKTRONIZÁLÁSA EKOP-1-A-1-08/C

ELEKTRONIKUS KÖZIGAZGATÁS OPERATÍV PROGRAM KÖZIGAZGATÁSI SZOLGÁLTATÁSOK ELEKTRONIZÁLÁSA EKOP-1-A-1-08/C-2009-0010 Legfőbb Ügyészség Ügyészségi eljárások elektronizálása Projekt Alapító Dokumentum v1.1 2010. LU_PAD_1 0 1/36

Dokumentum ellenőrzés Változások Dátum Szerző Verzió Hivatkozás 2010.05.10. Csomán Gábor, külső projektvezető 2010.05.21. Csomán Gábor, külső projektvezető 2010.06.01. Csomán Gábor, külső projektvezető 2010. 06. 07 Csomán Gábor, külső projektvezető v0.1 v0.2 v0.9 v1.0 Átnézték Dátum Név Beosztás PFB tag PFB tag PIB tag PIB tag PIB tag PIB tag Kapják Sorszám Név Hely 1. PFB tagjai Legfőbb Ügyészség 2. PIB tagjai Legfőbb Ügyészség LU_PAD_1 0 2/36

Jóváhagyják Név Aláírás Dátum LU_PAD_1 0 3/36

Tartalomjegyzék 1 Bevezetés... 6 1.1 Rövidítések... 6 1.2 PAD hatálya... 6 2 A Projektalapító Dokumentum bemutatása... 7 2.1 A PAD célja... 7 2.2 A Dokumentum forrásai... 7 2.3 A Dokumentum elkészítése és aktualizálása... 7 3 A projekt bemutatása... 8 3.1 A projekt neve... 8 3.2 A projekt meghatározása, céljai... 8 3.3 A projekt szakmai tartalma... 8 3.4 A projekttől elvárt eredmények... 10 3.5 A projekt kritériumai, mérése... 11 3.5.1 A teljesítménymutatók... 11 3.5.2 A projekttényezők, a projekt sikerkritériumai... 11 3.5.3 A projekt ütemezése... 13 3.5.4 A projekt eredményei, termékei... 16 4 A projektszervezet - Projekt Végrehajtási Egység (PVE)... 16 4.1 A projekt résztvevői... 16 4.2 A projekt résztvevőinek felelőssége... 16 4.3 A PVE - projektszervezet összetétele... 17 4.3.1 A projektszervezet felépítése, szervezeten belüli elhelyezkedése... 17 4.3.2 Projekt szereplői, feladataik és felelősségük... 17 5 Projektdokumentáció kezelése... 24 5.1 Nyilvántartott dokumentumok... 24 LU_PAD_1 0 4/36

6 A projekt működése... 26 6.1 Az ülésezés rendje és a döntéshozatali eljárások... 26 6.1.1 A Projektfelügyelő Bizottság... 26 6.1.2 A Projekt Irányító Bizottság... 26 6.1.3 Szakmai csoportok... 27 7 Főbb projekteljárások... 28 7.1 Nyitott kérdések kezelésére vonatkozó eljárás... 28 7.2 Változáskezelési eljárás... 29 7.2.1 A változtatáskérés felvetése... 29 7.2.2 A változtatás meghatározása... 30 7.2.3 A változtatás végrehajtása... 31 7.2.4 Eljárás vitás kérdésekben... 31 7.3 Átadás-átvételi eljárások... 32 7.4 A projekt kockázatai és azok kezelése... 34 7.5 Minőségbiztosítás... 35 7.6 Státuszjelentés... 36 7.7 Kommunikáció... 36 LU_PAD_1 0 5/36

1 Bevezetés A Projektalapító Dokumentum a Legfőbb Ügyészség számára Ügyészségi eljárások elektronizálása EKOP-1.A.1 projekt (továbbiakban projekt) végrehajtási szabályzata. 1.1 Rövidítések Jelen dokumentumban használt rövidítések: o PAD Projektalapító Dokumentum o Projekt EKOP-1-A-1-08/C-2009-0010 azonosító számon nyilvántartásba vett projekt o LÜ Megrendelő, Legfőbb Ügyészség o PFB Projekt Felügyelő Bizottság o PIB Projekt Irányító Bizottság o PV Projektvezetői szervezet o SZCS Szakmai csoportok o ANSWARE Vállalkozó, Answare Kft., a Megrendelő oldali külső projektmenedzsment o IT Információ Technológia 1.2 PAD hatálya Hatály: Jelen PAD az alábbi témaköröket határozza meg: o PAD bemutatása o A projekt bemutatása o A projektterv o A projektszervezet struktúrája és szereplői szerepkörök alapján o Projektdokumentáció-menedzsment o A projekt működése o Főbb projekteljárások LU_PAD_1 0 6/36

Alkalmazása A PAD a projektbe bevont minden munkatársra vonatkozik, beleértve az LÜ és az ANSWARE munkatársait, illetve minden olyan szakembert, aki a projekttel kapcsolatos bármely feladatot ellát. Érvényessége A PAD a PFB általi elfogadásával lép hatályba, és a projekt hivatalos lezárásáig érvényben marad. A projekt tervezett élettartamát időben a következő nyitó és záró mérföldkövek határolják be: Kezdés: 2009. október 28. Befejezés: 2011. május 30. (a projekt ütemterv szerinti záró dátuma) A Projekt zárását hivatalosan, a vonatkozó Támogatási Szerződésben meghatározott Megvalósítási Záró Beszámoló dokumentumának elkészítése, elküldése és a közreműködő szervezet (Váti Kht.) általi elfogadása jelenti. A PAD és annak mellékletei a projekt teljes ideje alatt a változásmenedzsment eljárás keretén belül módosítható, kiegészíthető. 2 A Projektalapító Dokumentum bemutatása 2.1 A PAD célja A PAD célja az LÜ Ügyészségi eljárások elektronizálására létrehozott projekt működési környezetének és a kapcsolódó szabályoknak az összefoglalása. A PAD-ot az LÜ és az ANSWARE közösen dolgozták ki és a projekt lezárásáig karbantartják. A PAD kialakításakor, a szabványok betartása mellett figyelembe vettük az LÜ projektalapításra vonatkozó megközelítését és igényeit. 2.2 A Dokumentum forrásai A PAD kidolgozásnak forrásanyagai: o Az EKOP 1.A.1 pályázat keretében az LÜ által leadott teljes pályázati anyag, pénzügyi tervek, a nyertes pályázat támogatási szerződése o Vállalkozói szerződés projektmenedzsment tevékenység ellátására az ANSWARE-ral. 2.3 A Dokumentum elkészítése és aktualizálása A PAD első változatát az LÜ és az ANSWARE munkatársai készítették el. LU_PAD_1 0 7/36

A PAD-ot a PFB hagyja jóvá, így módosításáról is ezen testületnek kell dönteni. 3 A projekt bemutatása Ez a fejezet a projekt rövid bemutatását, a mérföldköveket, valamint a fontosabb ellátandó feladatokat foglalja össze. 3.1 A projekt neve Ügyészségi eljárások elektronizálása (EKOP-1.A.1-08/C-2009-0010 azonosító számon nyilvántartásba vett pályázat) 3.2 A projekt meghatározása, céljai A projekt célja egy olyan modulszerűen felépülő integrált rendszer létrehozása, amely - képes az ügyészségre egyes eljárástípusokban érkező elektronikus iratok (ABEV nyomtatványok szükség esetén csatolt mellékletekkel), valamint más elektronikus adatok fogadására, érkeztetésére, előzetes feldolgozására; - az érkezett adatok ügyészségen belüli útját, megváltoztatását rögzíti; valamint az adatokat tárolja; támogatja az eljárások gyorsabb befejezését; - az ügyészek munkája során létrejövő határozatokat stb., valamint a társszervek nyilvántartásai számára szükséges ügyészségi adatokat hitelt érdemlően azonosítja, és a címzettek számára eljuttatja; - robusztus háttérrendszerként a jövőben modulárisan továbbfejleszthető, s ezáltal is támogatja az ügyészség külső ügyfélkapcsolatainak és belső folyamatainak elektronizálását, azok optimális egymáshoz illesztését. 3.3 A projekt szakmai tartalma A projekt alapvető célja az elektronikus kapcsolattartás lehetőségének megteremtése az ügyészség felé közvetlenül az ügyfélkapun keresztül, illetve társhatóságokkal a hivatali kapu szolgáltatásaira alapozva, konkrétan minél több eljárási cselekménynél, az elektronikus forma alkalmazásának biztosítása. A projekt keretében az ügyészségen egy olyan modulszerűen felépülő integrált rendszer kerül megvalósításra, amely: képes az ügyészségre érkező e-mailek, elektronikus (ABEV) nyomtatványok, valamint a társhatóságok nyilvántartásai által küldött adatok fogadására, érkeztetésére; az elektronikus LU_PAD_1 0 8/36

formában érkezett adatokat az ügyészek számára megjeleníti, illetve igény esetén az adatokat kinyomtatja, az ügyészégen belül azok útját, megváltoztatását rögzíti; valamint az adatokat tárolja; az ügyészek munkája során létrejövő határozatokat, válaszleveleket stb., valamint a társszervek nyilvántartásai számára szükséges ügyészségi adatokat hitelt érdemlően azonosítja, és a címzettek számára eljuttatja. A megvalósítás az elképzelések szerint a rendszer központi részét képező egységes jogosultságkezelésen alapuló ügyfélkezelő és dokumentum menedzsment rendszer (dokumentumtár) és az e köré szervezett szolgáltatások összessége lesz. A központi dokumentumtár szolgáltatás köré szervezett további szolgáltatások: munkafolyamat támogató workflow rendszer; ügyészségi hivatali kapu; elektronikus tértivevény; elektronikus kézbesítés; interfészek és tranzakciós modul, amelyek biztosítják a különböző rendszerek és szolgáltatások egységes csatlakozását a központi rendszerhez; elektronikus dokumentumok fogadása (kitölthető, ABEV technológiával készített, illetve ABEV sémát alkalmazó űrlapok, e-mail-ek és elektronikusan aláírt dokumentumok email csatolmányként való fogadása), illetve kézbesítésük az ügyfélkapu, kézbesítési tárhely és a hivatali kapu szolgáltatások igénybevételével. A felállított logikai koncepció szerint a fejlesztés egy olyan dokumentumtár létrehozására irányul a dokumentumtár maga a logikai modell központi eleme -, mely az alapvető dokumentumtár funkcionalitás és szolgáltatás halmazon túlmenően több funkcióval rendelkezik. Egyrészt támogatja a határozatok tárolását, kézbesítését, ezen kívül workflow menedzsment modulja hatékony keretbe foglalja, szabályozza és támogatja a munkafolyamatok végrehajtását. A dokumentumtárból és a munkafolyamat-motorból többszempontú statisztikai lekérdezések is megvalósíthatók. Mindezeken felül egy tanúsított a vonatkozó hatályos jogszabályi követelményeknek megfelelő - iktatórendszer is kapcsolódik a dokumentumtárhoz. Az ügyészségi iratok elektronikus kezelése kapcsán nem lehet megkerülni a hitelesség kérdését. A jogosultságkezelést ezért mindenképpen össze kell kapcsolni az elektronikus aláírás komponensekkel kapcsolatos problémákkal, a tanúsítvány és az időbélyeg kezelésével. A dokumentumtár logikai koncepciójának záróláncszeme az - akár SOA-alapú - interfész felület. Ezen interfészeken keresztül teremtődik meg az Ügyfélkapu-kapcsolat (ügyfélazonosítás), hivatali kapu kapcsolat, az összeköttetés az elektronikus dokumentumarchiváláshoz, az ügyészségi szakrendszerekhez és iktató rendszerhez, a hivatali kapuhoz és elektronikus kézbesítési tárhelyhez. A dokumentumtárra épülő elektronikus ügyintézést támogató modullal valósul meg a projekt egyik fő célja, az ügyfélkapcsolatok tulajdonképpeni elektronizálása. A projekt eredményeképpen létrejött eredmények megteremtik a lehetőségét az ügyészségi szakrendszerek integrálásának, valamint a rendszer rugalmasságából adódóan lehetőséget teremt arra LU_PAD_1 0 9/36

is, hogy a későbbiekben megvalósuló az ügyészség elektronikus működésében ugyancsak igen fajsúlyos rendszer ügytár is integrálódni tudjon egy interfészen keresztül. Az ANSWARE és a vállalkozók munkájának terjedelmére a velük kötött vállalkozói szerződések és mellékleteik az irányadóak. 3.4 A projekttől elvárt eredmények A tervezett megoldási mód szerint a projekt megvalósításának tervezése során alapvetően a Legfőbb Ügyészség, illetve az ügyészségi hálózat és a kapcsolódó rendszerek adottságaiból indulunk ki. A rendelkezésre álló szoftver és hardver infrastruktúra jó alapot ad a megvalósításhoz, ugyanakkor szükséges új komplett rendszer elemek létrehozása és a jelenlegi elemek kiegészítése, fejlesztése. Új elemek létrehozása szükséges kiemelten a központi és területi dokumentumtárak kialakításához, a tranzakciós és workflow mondulok kialakításához, a kapcsolódó rendszer elemek integrálását lehetővé tévő interfészekhez, PKI szolgáltatások integrálásához. A teljesen új fejlesztések és a jelenlegi rendszerek továbbfejlesztése, kiegészítése a projekt eredményeképpen egy olyan központi rendszer, infrastruktúra létrejöttét eredményezi, amely: o egységes szabályozott hozzáférésű elektronikus dokumentumkezelést, tárolást valósít meg, elektronikus aláírási lehetőséggel o megteremti az elektronikus kommunikáció lehetőségét (elektronikus beadványok fogadása, elektronikus kézbesítés, ügyfelekkel és társintézményekkel való elektronikus kommunikáció) o munkafolyamat támogatási lehetőséget biztosít a szakmai folyamatokhoz, ezáltal egyes elektronikus ügyintézési eljárási cselekmények munkahatékonyságát növeli, egyes lépések automatizálhatóságához alapot teremt o a központi dokumentumkezelő rendszerhez egységes hozzáférést és alkalmazási logikát biztosít a kialakítandó interfész rendszeren keresztül a szakalkalmazások számára o a központi elektronikus szolgáltatások igénybevétele biztosítja azt, hogy az ügyfél és társintézményi kapcsolatokban minden esetben az egységes, e-kormányzati céloknak megfelelő technikai szinten és megoldással lehessenek elérhetők a rendszer szolgáltatásai o az ügyészség vezetői számára átláthatóbbá, ezáltal tervezhetőbbé teszi a szervezet működését. A fentiekben felsorolt projekt célok és a kifejlesztendő eszközök hozzájárulnak a hosszú távú szabályozott működéshez, az elektronikus ügyintézés intézményrendszeren belüli mind szélesebb LU_PAD_1 0 10/36

kiterjeszthetőségéhez, egyben indokolják a projektet, és teremtik meg a megvalósítás szakmai hátterét. 3.5 A projekt kritériumai, mérése 3.5.1 A teljesítménymutatók A projekt a Projekt ütemterv -ben vázolt feladatok elvégzésével, az EKOP pályázatban nevesített és elérendő célként vállalt célok elérését tekinti eredménynek. További számszerű eredmények a pályázatban vállalt, a pályázat által kötelezővé tett eredménymutatók értékei. A projektben résztvevő felek által teljesítendő feladatokat, az eredményre gyakorolt felelősségi körüket a szállítói szerződések és a végleges ajánlatok egyértelműen tartalmazzák és szabályozzák. 3.5.2 A projekttényezők, a projekt sikerkritériumai A projekt sikere a projektszereplők számára eltérő tartalmú lehet, azonban az alábbi tényezők gondos és körültekintő kezelése vezethet a projekt sikerességéhez: 1. A projekt abban az esetben sikeres, ha a projekt termékei maradéktalanul, szakmailag megfelelő minőségben, tervszerű kivitelezésben az LÜ felé átadásra kerülnek, és a Projekt Megvalósításának Záró Beszámolója a Váti Kht. általi elfogadása megtörtént. Ennek előfeltétele a projekt során készített Projekt Előrehaladási Jelentések (PEJ) befogadása. 2. A projekt nem tisztán IT projekt, hanem összetettebb tartalmú, amely magába ötvözi a technológiák, emberi erőforrások, folyamatok tudatos változásmenedzsmentjét, ezért azok szabályoknak megfelelő kezelése fontos. 3. A projektben résztvevők, és a külvilág számára biztosítani kell a tartalmilag jól megcélzott kommunikáció megfelelő működtetését. 4. A projekt teljesítményének, a feladatok tartalmának, fontosságának és a határidők betartásának folyamatos minőségi ellenőrzése. 5. A projekt által kialakítandó rendszer követelményeinek felmérése teljes körű és szakmailag megalapozott legyen már a rendszertervezés alatt is. 6. A rendszer kialakítása során, a későbbi kulcsfelhasználók időben ismerkedjenek meg a megoldás architektúrájával, az újszerű kezelési módszerekkel, és képesek legyenek már a projekt során is befogadni a szükséges ismereteket. 7. Szükséges a feladatok egyértelmű kiosztása a projektben, az egyes szakmai csoportok között és azokon belül is. LU_PAD_1 0 11/36

8. Egyértelmű felsővezetői (projektgazdai) támogatottság. 9. A projektben résztvevők elkötelezettsége, és motiváltsága. LU_PAD_1 0 12/36

3.5.3 A projekt ütemezése A projekt ütemezése szempontjából a mindenkor érvényben lévő projekttervben definiált határidők a mérvadók. Jelen ütemezés a Projekt feladatainak vázlatát, valamint azok előzetes ütemezését tartalmazza. A Projekt megvalósítási fázisát megelőzően, a beszerzések lebonyolítása után a nyertes szállítók által is elfogadott részletes projektterv készítése szükséges, amely igazodva a megvalósítási körülmények és igények által meghatározott fő határidőkhöz részfeladatonként kell, hogy tartalmazza a megvalósítás konkrét menetét és a létrehozandó eredmények specifikációját. A jelenlegi ütemezés magas szinten tartalmazza a Projekt fő feladatköreinek és fázisainak időbeli tervezését. A részletes projektterveknek a későbbiekben heti, illetve kritikus esetben napi határidőket megállapítva kell tartalmaznia a részletes feladatokat. A részletes projektterv elkészítése mindenképpen valamely erre készült célszoftverrel ajánlott (jelen projektben a Microsoft Project,) amelyekkel az egyes részprojektek és azok feladatai közötti függőségek vizuálisan is jól szemléltethetők, az erőforrás szükségletek jól tervezhetők. A teljes Projekt magas szintű ütemezését, az egyes részfeladatokhoz rendelt fő intézkedések feltüntetésével az alábbi Gantt diagram foglalja össze. A diagramon függőlegesen a projekt fő feladatkörei és az azokba tartozó feladatok megnevezései találhatók, feltüntetve az adott feladat kezdő és végdátumát, tervezett időtartamát. A grafikus megjelenés időben vizuálisan szemlélteti a feladatokat, azok időtávját és az egyes feladatok közötti függőségeket. LU_PAD_1 0 13/36

Azonosító Tevékenység neve Időtartam Kezdés Befejezés Függőség 1 LEGFŐBB ÜGYÉSZSÉG EKOP 1.A.1 495 nap 2009.07.01 2011.05.24 2 3 ELŐKÉSZÍTÉSI FÁZIS 135 nap 2009.07.01 2010.01.05 4 Alap követelmények meghatározása 20 nap 2009.07.01 2009.07.28 5 Közbeszerzés előkészítése, műszaki dokumentáció 25 nap 2009.07.29 2009.09.01 6 Előkészítés vége 0 nap 2009.09.01 2009.09.01 4 7 Pályázati fázis 90 nap 2009.09.02 2010.01.05 8 Közbeszerzés lefolytatása 90 nap 2009.09.02 2010.01.05 5 9 Pályázat vége 0 nap 2010.01.05 2010.01.05 7 10 Külső projektmenedzsment 306 nap 2010.03.22 2011.05.23 11 kiválasztás 25 nap 2010.03.22 2010.04.23 12 szerződéskötés 1 nap 2010.04.26 2010.04.26 13 1. PEJ előkészítése 10 nap 2010.04.27 2010.05.10 14 1. PEJ leadása 1 nap 2010.05.11 2010.05.11 13 LU_PAD_1 0 14/36

15 1. sz. minőségbiztosítási jelentés leadása 1 nap 2010.08.19 2010.08.19 35 16 2. sz. minőségbiztosítási jelentés leadása 1 nap 2010.09.17 2010.09.17 28 17 3. sz. minőségbiztosítási jelentés leadása 1 nap 2010.11.29 2010.11.29 40 18 záró minőségbiztosítási jelentés leadása 1 nap 2011.05.23 2011.05.23 54 19 Záró PEJ előkészítése 15 nap 2011.05.02 2011.05.20 20 Záró PEJ leadása 0 nap 2011.05.23 2011.05.23 19 21 1. kifizetési kérelem benyújtása 1 nap 2010.10.18 2010.10.18 22 2. kifizetési kérelem benyújtása 1 nap 2011.05.23 2011.05.23 23 KÖVETELMÉNYPSECIFIKÁCIÓ 140 nap 2010.03.01 2010.09.13 24 Jelenlegi folyamatok felmérése, folyamattervezés 25 nap 2010.03.01 2010.04.02 25 Követelményspecifikáció v1.0 készítése 20 nap 2010.04.05 2010.04.30 24 26 követelményspecifikáció v1.0 leadása 1 nap 2010.05.31 2010.05.31 25 27 követelményspecifikáció v1.0 véleményezése, további verziók leadása, véleményezése 74 nap 2010.06.01 2010.09.10 26 28 követelményspecifikáció v2.0 átadása 0 nap 2010.09.13 2010.09.13 27 29 Közbeszerzés 128 nap 2010.06.16 2010.12.10 30 központosított közbeszerzés 128 nap 2010.06.16 2010.12.10 31 központosított közbeszerzéssel történő eszközök/szolgáltatások kijelölése 6 nap 2010.06.16 2010.06.23 32 központosított közbeszerzés lefolytatása 122 nap 2010.06.24 2010.12.10 31 33 nyílt közbeszerzési eljárás 110 nap 2010.06.28 2010.11.29 34 előkészítés 38 nap 2010.06.28 2010.08.18 35 közbeszerzési eljárás kiírása 0 nap 2010.08.19 2010.08.19 34 36 1. szakasz eredményhirdetése 1 nap 2010.10.05 2010.10.05 37 értékelési szempontrendszer 5 nap 2010.10.06 2010.10.12 36 38 tárgyalásos szakasz lefolytatása 23 nap 2010.10.06 2010.11.05 36 39 eredményhirdetés 1 nap 2010.11.08 2010.11.08 38 40 szerződéstervezet véleményezése 35 nap 2010.10.06 2010.11.23 36 41 szerződéskötés 0 nap 2010.11.29 2010.11.29 42 KIVITELEZÉS 182 nap 2010.07.29 2011.04.08 43 Eszközbeszerzés 40 nap 2010.09.13 2010.11.05 28 44 HW és alap SW telepítések 20 nap 2010.07.29 2010.08.25 45 Rendszerek testre szabása Wf paraméterezés 60 nap 2010.11.08 2011.01.28 43 46 Tranzakciós modulok és interfészek kifejlesztése 85 nap 2010.09.13 2011.01.07 28 47 Integrációs fejlesztések 50 nap 2011.01.31 2011.04.08 44;45 48 Fejlesztés vége 0 nap 2011.02.15 2011.02.15 46 49 TESZTELÉS 58 nap 2011.03.02 2011.05.20 50 Üzemeltetői rendszerteszt 10 nap 2011.04.11 2011.04.22 47 51 Terhelési teszt 5 nap 2011.03.02 2011.03.08 52 Végfelhasználói tesztelés 20 nap 2011.04.25 2011.05.20 50 LU_PAD_1 0 15/36

53 Hibajavítás 20 nap 2011.04.06 2011.05.03 51 54 Tesztelés-hibajavítás vége 0 nap 2011.05.20 2011.05.20 52 55 PROJEKTZÁRÁS 15 nap 2011.05.04 2011.05.24 56 Projekt adminisztratív zárása, átadás-átvétel 15 nap 2011.05.04 2011.05.24 53 57 Projekt vége 0 nap 2011.05.24 2011.05.24 3.5.4 A projekt eredményei, termékei A projekt előrehaladása során az egyes szakaszokban termékek kerülnek kidolgozásra, majd a projektütemtervben előírt időpontokban átadásra. A projekt végterméke a létrejövő informatikai támogatottságú elektronikus szolgáltatás. A projekt végrehajtása során termékek keletkeznek. A projekttermékek fejlesztett szoftverelemeire a PAD-ban szabályozott átadás-átvételi eljárásokat kell alkalmazni. A projekt során keletkeznek olyan résztermékek, amelyek később beépülnek egy-egy termékbe, de természetüknél fogva már korábban is használatba vehetőek. Azaz egy rész-, illetve előteljesítésnek tekinthetőek, de pénzügyi vonzatuk nincs. 4 A projektszervezet - Projekt Végrehajtási Egység (PVE) 4.1 A projekt résztvevői A projekt résztvevői a következők: Megrendelői oldal: LÜ Projekttámogató oldal: ANSWARE Az ANSWARE által a projektszervezetbe delegált személy: Csomán Gábor, helyettese: Poncsák Zsuzsa. 4.2 A projekt résztvevőinek felelőssége A projekt résztvevőinek a projekt termékeivel kapcsolatos felelősségeit az alábbi táblázat tartalmazza, amely a szállítói szerződésekben és a végső ajánlatokban rögzítettekkel teljes. LU_PAD_1 0 16/36

Részvevő megnevezése 1. Megrendelői oldal LÜ ANSWARE Felelősségek A projekt megrendelői oldalának teljes, osztatlan felelőssége. A projekt tanácsadó oldali vállalkozója. A felelősségét a Megrendelővel kötött szerződés szabályozza. Felelősségek: o megrendelő oldali projektmenedzsment támogatása, o monitoring feladatok elvégzése o a közreműködő szervezettel való folyamatos együttműködés, jelentések előkészítése 4.3 A PVE - projektszervezet összetétele A Legfőbb Ügyészség Ügyészségi eljárások elektronizálása című EKOP 1.A.1-08/A-2009-010 jelű pályázat megvalósítására irányuló projekt megvalósítása 1. Az LÜ vezetőjéből, mint projektgazdából; 2. Az LÜ által a projektben való együttműködéssel megbízott köztisztviselőiből, megbízott szakértőiből, külső közreműködőiből; 3. Az ANSWARE projekttámogató cég munkatársaiból áll. 4.3.1 A projektszervezet felépítése, szervezeten belüli elhelyezkedése A projekt szervezet LÜ-n belüli résztvevőinek a projekten belüli feladatellátáshoz szükséges rendelkezésre állását a Projektgazda, mint az LÜ vezetője biztosítja. 4.3.2 Projekt szereplői, feladataik és felelősségük A projekt szervezeti egységei hierarchikusan, döntéskör szerint csökkenő rendezéssel: o Projektgazda (projekten kívüli szerep) o Projektszponzor o PFB o PIB - Projekt Felügyelő Bizottság - Projekt Irányító Bizottság o A szakmai csoportok (az LÜ munkatársai, a bevont cégek szakértőinek támogatásával) o Az egyes szervezeti egységekben dolgozó munkatársak különböző szerepekben, illetve szerepkörben fordulhatnak elő. LU_PAD_1 0 17/36

A projekt hosszú átfutási idejű, így az egyes szerepekben személyi változások történhetnek, ezért a projekt szereplőinek nevesítése esetén a PAD új verziójának kiadása szükséges. Projektgazda Projektszponzor Megrendelő Oldali Projektirányítás (MOP) Projekt Felügyelő Bizottság (PFB) Külső Projektmenedzsment Elnök: Projektszponzor Projekt Irányító Bizottság (PIB) Projekt Iroda Projektkoordinátor Projektadminisztrátor Elnök: Projektkoordinátor Ügyészségi Szakmai Munkacsoport Elnök: Projektszponzor Tagjai: A Projektszponzor által felkért személyek Állandó meghívottak: Projektadminisztrátor IT Szakmai Munkacsoport Elnök: Projektszponzor Tagok: Stratis Kft. képviselői Ügyészségi projekt-koordinátor Állandó meghívottak: Külső projektmenedzser Projektadminisztrátor Közbeszerzésért felelős Munkacsoport Elnök: Projektszponzor Tagjai: Közbeszerzés feladataival megbízott cég képviselője Gazdasági Főigazgatóság képviselője Ügyészségi projekt-koordinátor Külső projektmenedzser 4.3.2.1 A Projektgazda A Projektgazda az LÜ vezetője Feladatai: A projekt képviselete a külvilág felé, a projekt legmagasabb szintű támogatása az LÜ-n belül. Az LÜ részéről munkatársak kijelölése és megbízása a következő pozíciókba: o Projektszponzor (Projektvezető) o Projektvezető-helyettes o Projektkoordninátor név dátum LU_PAD_1 0 18/36

dr. Kovács Tamás Legfőbb Ügyész 2009. október - 4.3.2.2 A Projektszponzor A Projektszponzor az LÜ vezetője által a projekt egyszemélyi felelős vezetője Feladata: A projekt képviselete a külvilág felé, a projekt megvalósításának felügyelete név dr. Tancsik Rudolf Személyügyi, továbbképzési és Igazgatási Főosztály dr. Nagy Tibor Számítástechnika-alkalmazási és Információs Főosztály dátum 2009. október - 2009. december 2009. december - A Projektszponzor-helyettese A Projektszponzort akadályoztatása esetén helyettese képviseli. név Pálmainé Kossányi Judit Számítástechnika-alkalmazási és Információs Főosztály dátum 2009. december - 4.3.2.3 A Projektfelügyelő Bizottság (PFB) Elnöke: Tagjai: o Projektszponzor: dr. Nagy Tibor, Számítástechnika-alkalmazási és Információs Főosztály o Laskai Ede, LÜ csoportvezető, Gazdasági Főigazgatóság o Projektkoordinátor: dr. Kis Gergely, LÜ ügyész, Számítástechnika-alkalmazási és Információs Főosztály o külső projektmenedzsmentet ellátó cég képviselője: Csomán Gábor Állandó meghívottak: o Projektadminisztrátor: Jaczina Krisztina, LÜ tisztviselő, Számítástechnika-alkalmazási és Információs Főosztály LU_PAD_1 0 19/36

A PFB vezetője a PFB üléseire belátása szerint meghívhat bárkit. Feladatai: o A projekt hatáskörét, a projekt kereteit meghaladó módosulások (emberi és pénzügyi erőforrások megváltozása, határidő módosulás, tartalmi módosítás, bővítés, szerződési keretek módosulása) kezelése, erre vonatkozó döntések hozatala o A PFB feladata a projekt előrehaladásának magas szintű felügyelete, és a projekt elszámoltatása a projektcélok teljesüléséről, o A PIB által készített beszámolók, tájékoztatók fogadása, o PIB vezetője által előterjesztett kérdésben döntés (változáskezelés), o A projektszervezet működésének értékelése. 4.3.2.4 A Projekt Irányító Bizottság (PIB) Elnöke: Tagjai: o Projektkoordinátor: dr. Kis Gergely, LÜ ügyész, Számítástechnika-alkalmazási és Információs Főosztály o dr. Székely István, főosztályvezető-helyettes ügyész, Személyügyi, továbbképzési és Igazgatási Főosztály o dr. Tancsik Rudolf, osztályvezető ügyész, Személyügyi, továbbképzési és Igazgatási Főosztály o Laskai Ede, LÜ csoportvezető, Gazdasági Főigazgatóság o külső projektmenedzsmentet ellátó cég képviselője: Csomán Gábor Állandó meghívottak: o PFB elnöke: dr. Nagy Tibor, Számítástechnika-alkalmazási és Információs Főosztály o Projektadminisztrátor: Jaczina Krisztina, LÜ tisztviselő, Számítástechnika-alkalmazási és Információs Főosztály o Pálmainé Kossányi Judit, főosztályvezető-helyettes, Számítástechnika-alkalmazási és Információs Főosztály o dr. Pintér Zsuzsanna, LÜ tisztviselő, Személyügyi, Továbbképzési és Igazgatási Főosztály Meghívottak: o igény szerint a szakmai csoportok vezetői o igény szerint a szakmai csoportok tagjai LU_PAD_1 0 20/36

Feladatok: o A PFB tájékoztatása. o A projektvezető döntéséhez irányítási segítséget nyújt, és a projektvezető indítványára javaslatot készít a döntéshez. o A projekt működésének értékelése. o A projekt költségeinek és határidőinek adminisztratív ellenőrzése. o A projekt működésének biztosítása a projekt hatáskörén belül. o A projektkockázatok megvitatása előrehaladási értekezlet keretében. A kockázatok kezelésére a PIB közvetlen döntési és utasítási jogkörrel rendelkezik. o A PIB vezetője intézkedik a PIB ülésének összehívásáról. 4.3.2.5 Projektkoordinátor Feladata: o A projekt iroda vezetése. o A projektszponzor munkájának segítése. o Annak biztosítása, hogy a pályázati kötelezettségeknek, adminisztrációs és beszámolási rendnek teljes körűen megfeleljen o A PIB döntéshozatali hatáskörébe tartozó kérdésekben előterjesztést készít, javaslatot tesz a szükséges döntésre. o a szakmai csoportok részéről indított eszkalációt felterjeszti a PIB felé. o A PFB és a PIB döntéseit nem igénylő kérdésekben meghozza a szükséges döntéseket. o A PIB és a szakmai csoportok támogatásával végzi feladatait. o Bármely szakmai csoport döntését szakmai szempontból felülbírálhatja a PFB egységes véleménye alapján. o A PIB felé tájékoztatási kötelezettséggel rendelkezik. o Együttműködik a projekttámogatóval, amennyiben szükséges, a projekttel kapcsolatban kikéri véleményét. o Együttműködik a projekt egyéb szereplőivel. o Szükség esetén, a szabályozotton kívül összehívja a projektvezetői értekezletet. o PIB összehívásának kezdeményezése. o A projekt termékeinek átvétele. o A szakmai csoportok, és a projekt státuszjelentések jóváhagyása. LU_PAD_1 0 21/36

név dr. Kis Gergely LÜ ügyész, Számítástechnika-alkalmazási és Információs Főosztály dátum 2010. január - 4.3.2.6 A projektadminisztrátor Feladata: o A belső kommunikáció támogatása (dokumentumok szétküldése, értesítések, egyeztetések). o A projekt menedzsment adminisztratív támogatása (dokumentumok kötése, fűzése, telefon kezelése). o Határidőkre való figyelmeztetés. o Elhelyezi a projektkönyvtárban (projektadatbázis) a hivatalosan iktatott iratok másolatait. o Elhelyezi a projektkönyvtárban (projektadatbázis) a keletkező projektdokumentumokat és nyilvántartja azokat Feladatait a projektkoordinátor iránymutatásának megfelelően végzi. név Jaczina Krisztina LÜ tisztviselő, Számítástechnika-alkalmazási és Információs Főosztály dátum 2010. február - 4.3.2.7 A szakmai csoportok vezetése és munkarendje A projektben szakigazgatási, informatikai és gazdasági tevékenységet, közreműködést ellátó LÜ munkatársak szakmai csoportokat alkotnak. A szakmai csoportok mellérendeltségi viszonyban állnak egymással, tevékenységük azonban nem független egymástól. Kölcsönös tájékoztatási, együttműködési kötelezettségük van, mivel munkájukat többször átfedés jellemzi. A projektben az alábbi szakmai csoportok működnek: o Ügyészségi Szakmai Munkacsoport (ÜSZM) o IT Szakmai Munkacsoport (ITM) o Közbeszerzési Munkacsoport (KM) A szakmai csoportok vezetője a Projektszponzor, távollétében helyettese jár el. A Projektszponzor feladatai a szakmai csoportok kapcsán: LU_PAD_1 0 22/36

o Koordinálja a szakmai csoport működését. o A szakmai csoport feladatait a tagoknak határidő kitűzésével kiosztja. o A feladatok határidőre történő elvégzését folyamatosan ellenőrzi. o A szakmai csoportjának üléseiről emlékeztetőt és státuszjelentést készíttet, véleményez és elfogad. o Gondoskodik a végleges iratanyagok iktatásáról, és egy iktatószámmal ellátott példány visszajuttatásáról a projektadminisztrátor részére. o Utasítási joggal rendelkezik szakmai csoportjának tagjai felett, figyelembe véve a munkáltatói jogokat. A Projektszponzor felelőssége a szakmai csoportok kapcsán: o A szakmai csoportvezető felelős a szakmai csoport által végrehajtandó feladatok határidőre történő elvégzéséért. o A szakmai csoport tagok szükség szerint megbízás alapján a Projektszponzorral történő egyeztetést követően delegálhatóak másik szakmai csoportokba. o A szakmai csoportok megbeszéléseiről emlékeztető készül igény szerint hangfelvétel alapján. A szakmai csoportok maguk határozzák meg a munkarendjüket, a megbeszélésekről emlékeztető készül. A szakmai csoportokat a Projektszponzor (akadályoztatása esetén a helyettese) jogosult bármikor összehívni a megbeszélések előtt legalább két munkanappal e-mailben kiküldött meghívókkal. 4.3.2.8 A szakmai csoportok tagjai ÜGYÉSZSÉGI SZAKMAI MUNKACSOPORT (ÜSZM) - dr. Molnár Ervin, ny. főosztályvezető-helyettes ügyész, LÜ tanácsadó - dr. Szabolcsi László, LÜ ügyész - dr. Szeder Gyula, ny. főosztályvezető ügyész, LÜ tanácsadó - dr. Szekér Ildikó, LÜ ügyész IT SZAKMAI MUNKACSOPORT (ITM) - Projektkoordinátor: dr. Kis Gergely, LÜ ügyész, Számítástechnika-alkalmazási és Információs Főosztály - Stratis Kft. képviselője: Lokodi György LU_PAD_1 0 23/36

Állandó meghívottak: - külső projektmenedzsmentet ellátó cég képviselője: Csomán Gábor - Projektadminisztrátor: Jaczina Krisztina, LÜ tisztviselő, Számítástechnika-alkalmazási és Információs Főosztály KÖZBESZERZÉSI MUNKACSOPORT (KM) - Laskai Ede, LÜ csoportvezető, Gazdasági Főigazgatóság - Projektkoordinátor: dr. Kis Gergely, LÜ ügyész, Számítástechnika-alkalmazási és Információs Főosztály - külső projektmenedzsmentet ellátó cég képviselője: Csomán Gábor Állandó meghívottak: - Projektadminisztrátor: Jaczina Krisztina, LÜ tisztviselő, Számítástechnika-alkalmazási és Információs Főosztály 5 Projektdokumentáció kezelése Ez a fejezet a projekt működéséhez szükséges projektdokumentációs alapelveket, eljárásokat és feladatokat tartalmazza. 5.1 Nyilvántartott dokumentumok Általános elv, hogy minden, a projekt szempontjából információt hordozó dokumentumot nyilván kell tartani. Nyilvántartásba kell venni minden hivatalosan iktatott ( Iktatószám -mal ellátott) és nem iktatott, de a projekt szempontjából fontos végleges dokumentumot, az alábbiak szerint: o a dokumentum indítója ellátja a szükséges információkkal a projektadminisztrátort, o a projektadminisztrátor összeállítja a dokumentumot a kapott mellékletekkel együtt, o az összeállított dokumentumot az indító véleményezi és jóváhagyja, o a projekt adminisztrátor gondoskodik az Iktatás -ról, LU_PAD_1 0 24/36

o a végleges dokumentumokat a projekt dokumentum nyilvántartásban (papír alapú és elektronikus) el kell helyezni A nyilvántartás, a dokumentum megfelelő módon való elhelyezését jelenti az elektronikus könyvtárstruktúrában, és a papír alapú projektdossziékban. Dokumentumok típusai: o Projektmenedzsment dokumentumok o A projekt résztvevői által elkészítendő dokumentumok o munkaközi verziók, o végleges verziók. Nyilvántartásba kerül az összes olyan dokumentum, amelyet: o a projekt valamely szervezeti egysége megtárgyalt, és az illetékes jóváhagyó által elfogadásra került (végleges verzió), o a projekt valamely szervezeti egység munkájának eredményeként létrejön, és az illetékes jóváhagyó által elfogadásra került, beleértve az ülésekről szóló emlékeztetőket is, o az ülések összehívására küldtek ki, o a projekttel kapcsolatosan Feljegyzés formájában készítettek. Továbbá nyilvántartásba kerülnek azok a dokumentumok is, amelyeket a fentieken kívül a projektvezető rendel el. A projekt során keletkező egyéb dokumentumokat nem kell nyilvántartásba venni. A dokumentumokat elektronikus úton kell elkészíteni. Abban az esetben, ha elektronikus formában nem áll rendelkezésre egy dokumentum, akkor azt be kell szkennelni. Amennyiben valamilyen ok miatt (például a méret), a dokumentum nem szkennelhető be, akkor papír formában kell tárolni. LU_PAD_1 0 25/36

6 A projekt működése 6.1 Az ülésezés rendje és a döntéshozatali eljárások 6.1.1 A Projektfelügyelő Bizottság A PFB rendszeres tájékoztatását a PIB rendszeres státuszjelentése szolgáltatja. A PFB üléseit a projektindítást követően minden projekt ütemterv szerinti mérföldkő elérésénél illetve szükség szerint tartja. A PFB-t szükség esetén a PIB vezetőjének kezdeményezésére a PFB vezetője hívja össze az ülés napját megelőzően legalább három munkanappal. A meghívás e-mail küldésével történik, amelyben közlik az ülés helyét és idejét, valamint csatolják az ülés anyagát. A szükséges információkat, a PIB vezetőjétől kapottak alapján a PFB vezetője adja a projektadminisztrátornak, aki kiküldi a meghívókat. Az üléseket a PFB vezetője vezeti le. A PFB döntéseit a PFB tagjaival való konzultációt követően a PFB vezetője hozza. Az ülésekről a projektadminisztrátor jegyzőkönyvet ír, és a PFB vezetője hitelesíti azt aláírásával. 6.1.2 A Projekt Irányító Bizottság A PIB a projekt legmagasabb döntési szintű szervezete. A PIB üléseit (a projektindító elnöki értekezlet) követően az egyes projekt ütemterv szakaszok lezárásakor, illetve szükség szerint tartja. Az üléseket a PIB vezetője hívja össze az ülés napját megelőzően legalább három munkanappal. A meghívás e-mail küldésével történik, amiben közlik az ülés helyét és idejét, valamint csatolják az ülés anyagát. Azonnali döntést igénylő kérdésben az ülés napját megelőzően egy munkanappal is küldhető meghívó. Az üléseket a PIB vezető vezeti le. Az ülésen minden tag köteles megjelenni. Bármely tag akadályoztatása esetén köteles e-mailben hiányzását előre jelezni a projektadminisztrátornak, és lehetőleg helyettesítéséről gondoskodni. A PIB tagjai a PIB üléseken a döntést igénylő kérdésekben konszenzusos döntés meghozatalára törekednek. Amennyiben a döntés nem konszenzuson alapul vagy döntés nem születik, akkor joga van bármely tagnak a PIB vezetőjénél a PFB összehívását kérni. Az ülésekről emlékeztető készül. Az emlékeztetőt a projektadminisztrátor írja, és a PIB vezetője hitelesíti aláírásával. LU_PAD_1 0 26/36

6.1.3 Szakmai csoportok A szakmai csoportok üléseire a meghívókat a Projektszponzor kérésére a projektadminisztrátor küldi ki. A meghívóhoz szükséges információkat (címzettek, időpont, napirendi pontok és kérdések, kapcsolódó dokumentumok) a Projektszponzor szolgáltatja a projektadminisztrátornak. A meghívókat, ha lehetséges, a találkozók előtt legalább két munkanappal kell kiküldeni. A szakmai csoportok üléseiket a projekt által megkívánt időközönként tartják meg, a Projektszponzor által előre meghatározott napokon. Az üléseken köteles minden állandó tag részt venni. Bármely tag akadályoztatása esetén köteles előzetesen az akadály felmerülésekor azonnal e-mailben értesíteni Projektszponzort a hiányzásról. A szakmai csoportok ülésein a csoport vezetője a Feladatlista szerint kiosztja a feladatokat. A Feladatlista az emlékeztető sablon része. # Feladat megnevezése Határidő Felelős 1. 2. 3. Minden szakmai csoport a projektvezető szakmai iránymutatása és döntései alapján köteles eljárni. A szakmai csoport feladatait érintő kérdésekben a döntéseket a szakmai csoport vezetője hozza meg, a szakmai csoport tagjaival való konzultációt követően. Egyet nem értés esetén eszkalációs eljárás keretében e nyitott kérdést a PIB, majd szükség esetén a PFB tárgyalja meg és hoz konszenzuson alapuló döntést. A szakmai csoportok üléseiről a projektadminisztrátor emlékeztetőt készít, amely elkészült tartalmát egyezteti a csoport vezetőjével. Az így előálló emlékeztetőt a projektadminisztrátor kiküldi minden érintettnek e-mailben. Az emlékeztető kötelező része a Feladatlista. LU_PAD_1 0 27/36

7 Főbb projekteljárások 7.1 Nyitott kérdések kezelésére vonatkozó eljárás A projekt alatt bármikor felvetődhetnek olyan fontos kérdések, illetve akadályozó tényezők (más néven úgynevezett nyitott kérdések), amelyek o megválaszolására vagy elhárítására az adott személy nem illetékes, o megválaszolása vagy elhárítása az adott pillanatban nem lehetséges, megoldásához pótlólagos információk begyűjtése, más szervezetekkel való koordináció szükséges. E kérdéseknek a szabályozott menedzselése rendkívül fontos a projekt előrehaladása szempontjából, mivel alapvetően befolyásolják a termékek minőségét és a kitűzött határidők teljesítését. A nyitott kérdések kezelése Az elemzési-tervezési munka során felvetődő nyitott kérdéseket, problémákat minden esetben az adott projekt szervezeti szinten az elektronikus dokumentumtárban elérhető nyitott kérdések listájában kell rögzíteni. A projektvezető, szakmai vezető illetve az érintett szakmai csoportvezetők a lehető legrövidebb időn belül rögzítik a felmerült nyitott kérdést. A projekt adminisztrátor rögzíti a nyitott kérdések nyilvántartásában. A rögzítés során a nyitott kérdésre vonatkozóan nyilván kell tartani: 1. egyedi azonosító 2. kérdés leírása 3. a teljesítési határidő 4. a kérdés gazdája (felelőse) 5. a megoldás leírása 6. a nyitott kérdés státusza A 6. pont annyiszor ismétlődik, ahány státusza lesz a nyitott kérdésnek, de legalább kettő, nevezetesen a rögzítési és a megoldási dátumokhoz kötődő státuszok. A projektvezető koordinálja a nyitott kérdés megválaszolását. A problémát a projektvezető szakmai kérdés esetén - amennyiben nem tudja feloldani - a PIB elé terjeszti (erőforrás hozzárendelések, ütközések stb.). LU_PAD_1 0 28/36

A nyitott kérdések kezelése estén is működik eszkalációs eljárás, ahol először a PIB, majd szükség esetén a PFB tárgyalja meg a kérdést és hoz döntést. Amennyiben a kérdés a megadott határidőig nem kerül lezárásra, akkor az illetékes munkatárs soron kívül értesíti a projektvezetőket a késedelemről. A szükséges döntés meghozatalának legmagasabb fóruma a PFB. A nyitott kérdések kezelése során előálló esetleges késedelem következményeit át kell vezetni a projektterven, illetve az összes kapcsolódó dokumentáción. A nyitott kérdéseket minden esetben szerepeltetni kell az előrehaladási jelentésben. Amennyiben két héten belül a nyitott kérdésre nem történik válaszadás (nem megoldás), akkor az a PFB elé kerül. 7.2 Változáskezelési eljárás A projekt alatt bármelyik fél felvetheti a szerződés tárgyában, a követelményspecifikációban, valamint egyéb, a rendszer leszállítását meghatározó dokumentumban foglaltakra vonatkozó változtatási kérelmét. Azonban, különösképpen az informatikai projektek egyik legnagyobb kockázatát az jelenti, hogy a projekt futamideje alatt a projekt terjedelme, illetve tartalma ellenőrizetlenül és határok nélkül módosulhat. Ennek hatására megváltoznak az eredeti tervhez képest a termékek, a költségek, az átfutási idők valamint a minőség is. Ezért a projekten belüli változtatásokra csak szabályozott körülmények között kerülhet sor. Az összes változtatási kérés megvizsgálásra kerül. A projekt változáskezelési folyamata az alábbi lépésekből áll: 1. A változtatáskérés felvetése és felülvizsgálata annak meghatározására, hogy valódi változtatást jelent-e az adott dokumentumban meghatározott feladat a projekt terjedelmében vagy tartalmában. 2. A változtatás specifikációjának elkészítése, illetve elfogadása. 3. A változtatás végrehajtása. 4. Eljárás vitás esetben. 7.2.1 A változtatáskérés felvetése Az érintett fél (LÜ, ANSWARE) aki a változtatást kéri, elkészíti a változtatáskérés dokumentumát, amely az alábbiakat foglalja össze: 1. a változtatás terjedelme és tartalma, LU_PAD_1 0 29/36

2. a változtatás jogossága, 3. a változtatás valószínű hatása. A változtatáskérést az érintett fél továbbítja a projektadminisztrátornak, aki egy e célra megnyitott naplóban nyilvántartásba veszi. A változtatáskérést a PIB megvizsgálja, javaslatot dolgoz ki. A projektvezető a változtatáskéréssel kapcsolatos egyeztetéseket vezeti. A projektvezetők az egyeztetéseken, a dokumentum alapján megvizsgálják, hogy a változtatáskérés valódi változtatásokat jelent-e, vagy az részét képezi az eredeti szerződésnek, tehát nem valós változtatási kérelemről van szó. Amennyiben nem alakul ki konszenzusos döntés, akkor az Eljárás vitás kérdésekben fejezet szerint kell eljárni. A változtatási kérelmet a nyitott kérdésekhez hasonlóan szerepeltetni kell a PIB előrehaladási jelentésben, függetlenül attól, hogy valós vagy vélt változtatási kérelemről van-e szó. 7.2.2 A változtatás meghatározása Amennyiben a projektvezetők együttesen úgy döntenek, hogy a változtatáskérés valódi változtatást jelent, és annak végrehajtását támogatják, akkor az érintett szakmai csoportok munkatársai elkészítik a változtatás meghatározását (specifikációját), amelyben az alábbiak kerülnek azonosításra: 1. a változtatás nyilvántartási száma, 2. a változtatás neve, 3. a változtatás rövid ismertetése, 4. a változtatás pénzügyi összefoglalója (a kifizetések alakulása, a változtatás implementációjának költségei, és amennyiben a változtatás jellege úgy kívánja, akkor a felmerülő folyamatos és működtetési költségekre való hatása), 5. a változtatás következményének hatásai az erőforrásokra, az ütemezésre és a függőségben lévő egyéb tevékenységekre, 6. a változtatás tartalmának részletes specifikációja, 7. a változtatás végrehajtásának munkaterve, 8. a változtatásoknak a dokumentációkon való átvezetési ütemterve. Az elkészült specifikációt a PIB véleményezi, és javaslatot tesz az LÜ számára annak elfogadására vagy az esetleg szükséges korrekciókra. A projektvezetők és a szakmai vezetők a projekt illetékes LU_PAD_1 0 30/36

szakértőinek bevonásával jóváhagyják a változtatás specifikációját, majd azt követően a projekt vezetője intézkedik annak kivitelezéséről. 7.2.3 A változtatás végrehajtása A specifikáció jóváhagyásával a változáskérés elfogadottnak tekintett, és ennek megfelelően a projekt tervek kiegészítéseként kell kezelni. Az elfogadott változtatáskérésnek megfelelően módosítani kell a projekt érintett tervdokumentációit. A végrehajtást a napi munka részeként be kell építeni a projekttervbe és az egyéb dokumentumokba, azaz a fentiek alapján a változtatások menedzselése részét képezi a projekt napi irányítási tevékenységének. 7.2.4 Eljárás vitás kérdésekben Amennyiben a projektvezetők szintjén nincs egyetértés a változáskérés jogosságáról, akkor eszkalációs eljárás lép érvénybe. Egyet nem értés vitás kérdések a jóváhagyási folyamat során leginkább az alábbi esetekben merülhetnek fel: 1. a változtatáskérés időpontjában a vitát az képezi, hogy a változtatás valódi-e azaz a szerződés hivatalos kiegészítéseként kell kezelni vagy pedig az nem valós változtatáskérés, mivel azt az eredeti szerződés keretében kell megoldani, esetleg a változtatáskérés időpontjában, amikor a vita valószínűleg abból alakul ki, hogy a változtatást valódiként kell e kezelni azaz a szerződés hivatalos kiegészítéseként, vagy pedig a meglévő szerződésnek kell azt tartalmaznia, 2. a változtatáskérés valódinak minősül, azonban a specifikáció kézbevételekor (például: amikor a változtatás végrehajtásának költségei, illetve az ütemezés hatásai kerülnek megállapításra) vita alakul ki, amikor a változtatás végrehajtásának ráfordításai (költségei, illetve az ütemezés hatásai) meghaladhatják a változtatásból származó előnyöket. A vitás kérdések rendezésére eszkalációs eljárás áll rendelkezésre, amelyek a következők: 1. szerződés a vitás kérdések elsőszintű tisztázására a PIB előrehaladási értekezlet, 2. egyet nem értés esetén a következő fórum második szinten a PFB, 3. harmadik szinten a Projektgazda, 4. majd végső soron független szakértő, választott bíróság, illetve a szerint választott jogi fórum hivatott eljárni. LU_PAD_1 0 31/36

7.3 Átadás-átvételi eljárások Általános alapelv, hogy átadás-átvétel esetén az átadást minden esetben egyértelművé kell tenni, és kötelező visszaigazoltatni öt munkanapon belül! Ezt követően az átvételt végző írásban kérelmezheti az észrevétel határidejének hosszabbítását megfelelő indokkal. Azonban ebben az esetben, tudatában kell lennie a következményekkel. Az elhúzódó átadás vagy átvétel által okozott változtatási igényeket a változtatáskezelés alkalmazásával kell érvényesíteni. Átadás-átvétel, teljesítési igazolás A szerződésszerű teljesítést készre jelenti a projekt mérföldkövekkel lezárt munkaszakaszaihoz rendelt tevékenységeinek elvégzését követően, Teljesítési Jegyzőkönyv készítésével, és annak az LÜ felé történő benyújtásával, Az LÜ a minőségi ellenőrzést követően elfogadja, az elfogadás tényét a Teljesítési Jegyzőkönyv aláírásával igazolja. Az LÜ az elfogadást írásban és megfelelő indoklással tagadhatja meg. A teljesítés elfogadásáról az LÜ öt munkanapon, vagy a projektvezetők által külön megegyezett időtartamon belül köteles dönteni, illetve korrekciós igény felmerülése esetén köteles e határidőn belül igényét írásban a vállalkozók, illetve ANSWARE tudomására hozni. A vállalkozók, illetve az ANSWARE az indokolt korrekciós tevékenységeket a Felek által közösen elfogadott határidőn belül elvégzi, ezt követően a korrekciós tevékenységgel érintett munkaszakasz teljesítését ismételten Teljesítési Jegyzőkönyvben adja át az LÜ-nak. Amennyiben a vállalkozó nem kap választ öt munkanapon belül, akkor a PIB felé fordulhat. A teljesítés elfogadása az LÜ részéről az átadástól számított öt munkanapon vagy a projektvezetők által külön megegyezett időtartamon belül esedékes (lásd általános alapelv). Folyamat Az átadás-átvételi eljárások egyrészt a minőség biztosításának eszközei, másrészt a pénzügyi teljesítések alapjai. LU_PAD_1 0 32/36

Az átadás-átvételi eljárások szabályozásának szintén fontos szerepe van abban, hogy a projekttervben ütemezett feladatok a megadott határidőkre elvégezhetők legyenek, és a késedelmek ne akadályozzák a tervszerű végrehajtást. Ilyen megközelítésből tekintve a fentiek a projekt kockázatai csökkentésének fontos elemét képezik. A rendszerfejlesztési projekt előrehaladása során a termékek a projektszervezet irányítása és működtetése kivételével egyrészt dokumentum típusúak, másrészt működőképes szoftverek. A szoftver típusú termékek leszállítandók mint pl. az alkalmazási rendszer prototípusa, az interfész programok, vagy a konverziós programok átadás-átvételére a projekt megoldás-tervezési szakaszában kidolgozásra kerülő tesztelési koncepció előírásai szerint kialakított tesztelési tervek alapján elvégzett sikeres tesztelések után kerül sor. Az elkészített tesztelési koncepcióban, majd az ezek alapján az LÜ által előállított tesztelési tervekben megfogalmazott feltételek szerint a LÜ által kijelölt munkatársak a tesztüzemben a funkcionális-, az integrációs-, valamint a teljesítmény-tesztelések során győződnek meg arról, hogy az elkészült alkalmazási rendszer megfelel-e a részletes követelményspecifikációban megfogalmazottaknak. Az úgynevezett érvényesítési tesztelés során kerül ellenőrzésre, hogy az alkalmazási rendszer éles üzemi viszonyok között működésre alkalmas-e. A sikeres érvényesítési teszt jelenti az alkalmazási rendszer, illetve az egyes rendszerkomponensek hivatalos átadás-átvételét. A fejlesztési projekt során elkészített termékek (dokumentumok, szoftverek) Átadás-átvételi jegyzőkönyv -vel kerülnek átadásra az LÜ részére. Az LÜ szakértői az adott termékekhez a szerződésben meghatározott átvételi időtartam alatt minősítik az átadott dokumentumot, illetve rendszermodult, funkciót, és elfogadják azt, kiegészítést kérnek vagy elutasítják annak átvételét. A kiegészítés azonban nem haladhatja meg a projekt terjedelmét, illetve ha igen, akkor az a változások felügyeleti és jóváhagyási folyamat szabályai szerint történhet meg. A minősítést a megadott határidőn belül írásban kell átadnia a kivitelező vállalkozó(k) részére. Kiegészítési igény vagy elutasítás esetén a minősítésben a Megrendelőnek indokolnia kell az okokat. Azokra a termékekre, amelyekre az LÜ az előírt határidőn belül nem ad át minősítést emlékeztetőben, vagy jegyzőkönyvben rögzíteni kell a minősítés elmaradásának tényét az okokkal és a megoldási javaslattal együtt. A rendezés módja végső soron az eszkalálás. A kiegészítési igények, valamint az elutasított termékek pótlásának feltételeiben a felek megállapodnak, és annak következményeivel módosítják a projekttervet. LU_PAD_1 0 33/36