PROJEKTCSATORNA RENDSZER-FEJLESZTÉSI KONCEPCIÓ ÉS ON-LINE ALKALMAZÁS-TERV

PROJEKTCSATORNA RENDSZER-FEJLESZTÉSI KONCEPCIÓ ÉS ON-LINE ALKALMAZÁS-TERV A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektalapú termelési, fejlesztési és együttműködési kapcsolatainak fejlesztése érdekében

Készült:

a Közép-Pannon Regionális Fejlesztési Zrt., az AE-Plasztik Kft., az Ajkai Elektronikai Kft., az Ajkai Gépészeti Gyártó és Szolgáltató Kft., a KONTEX Kereskedelmi és Szolgáltató Kft., a Poppe + Potthoff Hungária Gépgyártó Kft. és az Unimontex Kft. alkotta Konzorcium gondozásában, az EX ANTE Tanácsadó Iroda Kft. közreműködésével, „Az Ajkai Mechatronikai és Járműipari Klaszter szolgáltatásainak bővítése és kiterjesztése a Bakony-Balaton Térségére” című, KDOP1.2.1-11-2011-0002 azonosítószámú projektjének keretein belül.

Bakony-Balaton Mechatronikai és Járműipari Klaszter Cím: 8000. Székesfehérvár, Zichy liget 12. 8200. Veszprém, Budapest út 3. Telefon: +36-22-315-402, +36-88-429-008 E-mail: [email protected] , Honlap: www.bbmjk.hu

Bevezetés A Nemzeti Fejlesztési Hivatal és a Közép-Dunántúli Regionális Fejlesztési Ügynökség Közhasznú Nonprofit Kft. Tanács 2011. tavaszán tette közzé az Új Széchenyi Terv Közép-Dunántúli Operatív Programjának Vállalati együttműködés és klaszterek támogatása c. konstrukciójához kötődő, KDOP-1.2.1.-11 sz. pályázati felhívását, melyre a Közép-Pannon Regionális Fejlesztési Zrt., az AEPlasztik Kft., az Ajkai Elektronikai Kft., az Ajkai Gépészeti Gyártó és Szolgáltató Kft., a KONTEX Kereskedelmi és Szolgáltató Kft., a Poppe + Potthoff Hungária Gépgyártó Kft. és az Unimontex Kft. alkotta Konzorcium mint az Ajkai Mechatronikai és Járműipari Klaszter tagjai az „Ajkai Mechatronikai és Járműipari Klaszter szolgáltatásainak bővítése és kiterjesztése a Bakony-Balaton Térségére „Közép-Dunántúli Regionális Klaszter-közösség kialakítása és fenntartható fejlesztése” címmel sikeres pályázatot nyújtott be. Jelen munka a KDOP-1.2.1-112011-0002 azonosítószámú projekt keretein belül elkészült, a klaszter termelési, fejlesztési és együttműködési kapcsolatai célzó „Projektcsatorna rendszer” fejlesztését megalapozó, - a rendszer működtetését támogató információs rendszer tervét is magába foglaló - tanulmány. A dokumentum gyakorlati segítséget ad a végleges rendszer megvalósítói számára mind a komplex projektcsatorna rendszer – s annak részeként egy interaktív információs rendszer - tartalmát, mind a megvalósítás mikéntjét tekintve. A tanulmány keretein belül igyekeztünk választ keresni a legalapvetőbb koncepcionális, módszertani és rendszertechnikai kérdésekre. Munkánk során – saját tapasztalatainkon, illetve dokumentumok-elemzésen túlmenően - nagy segítségünkre voltak azok a személyes konzultációk, amivel a klaszter-közösség tagjai rendelkezésünkre álltak, és amiért ezúton is köszönetet 2

mondunk. Az egyeztetések alapján egyértelművé vált, hogy elvárás olyan megoldást találnunk, mely 

a klaszter projektalapú fejlesztéseit kedvezően befolyásolja,



és, hogy felhasználói oldalról alapvetően nyilvános, internetes hozzáférésű rendszerre tegyünk javaslatot.

Mindezeket szem előtt tartva készítettük el a jelen dokumentumot. Az anyaggal mindenekelőtt a következő célokat kívántuk elérni: 

meghatározni a klaszter-közösség projektcsatorna rendszerének alapelveit és alapkövetelményeit oly módon, hogy az megfeleljen mind a hazai, mind az uniós sztenderdeknek és ajánlásoknak;



feltárni, hogy a rendszernek milyen információigénye, adatigénye van;



meghatározni a rendszer alapvető informatikai követelményeit, ezen belül javaslatot tenni a rendszertechnikai és az adatmigrációs megoldásokra;

Ennek megfelelően maga a dokumentum két fő egységre tagolódik: 

Az első egységben szó esik a projekt-fejlesztéssel összefüggő általános alapelvekről, feladatokról.



A záró fejezet pedig a megvalósítás kérdéseit tárgyalja. Ezen belül a súlyponti kérdés a különböző forrásokból (klasztertagoktól, pályáztató szervezetektől, befektetőktől) származó adatok átvételének és rendszerbe kerülésének problémája,

illetve

a

felhasználók

számára

nyújtott

szolgáltatások

meghatározása. Emellett összefoglaljuk a megvalósítás konkrét lépéseit is. Hangsúlyozni kell, hogy a jelen tanulmány a gyakorlati kivitelezést megalapozó, ahhoz elvi és gyakorlati iránymutatást nyújtó anyag, de magának az információs rendszernek a tényleges megvalósítása további jelentős időt, munkát és forrásokat igényel. E tekintetben mindenekelőtt szükség van a szükséges számítástechnikai

fejlesztések

(programtervezés,

installálás) kivitelezésére.

3

programozás,

tesztelés,

Székesfehérvár, 2012. április 10.

Tartalom

1 Alapelvek és alapkövetelmények......................................................................................................................10 1.1 A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének premisszái..............................................................................................................................11 1.1.1 A projektcsatorna-rendszer társadalmi-gazdasági funkciói..........................................12 1.1.2 Az uniós alapelvek megjelenése a projektcsatorna rendszerben................................13 1.2 A projektcsatorna rendszer működtetésével kapcsolatos alapvetések..........................17 1.2.1 A projektalapú együttműködés indokoltsága, főbb területei.........................................18 1.3 A koncepcióalkotással kapcsolatos alapvetések..............................................................21 1.3.1 Mutatók, indikátorok a klasztertagok specifikumainak és a környezet projektalapú elvárásainak tükrében...................................................................................................21 1.3.2 Ellenőrzés, értékelés, monitoring..................................................................................27 1.4 A projektfejlesztés sajátosságai..........................................................................................30 1.4.1 A projektek komplex fejlődési rendszerbe illeszkedése...............................................30 1.4.2 A projektcsatorna koncepció.........................................................................................32 1.4.3 A projektek értékelése...................................................................................................34 Az egyik legalapvetőbb feltétel, hogy a projekt célrendszere illeszkedjen a tágabb program, a klaszterszintű stratégia célrendszeréhez.......................................................35 A gazdasági értékelés során elsősorban rentabilitási kérdéseket, a ráfordítások és az eredmények viszonyát vizsgálják (költség/haszon elemzés, költséghatékonyság, megtérülés stb.).....................................................................................................................35 A pénzügyi (financiális) értékelés a költségterv megalapozottságának vizsgálatát jelenti: 4

reálisak-e a projekt-tervben feltüntetett költségek, rendelkezésére áll-e a kellő időben a szükséges pénzalap, az ténylegesen fedezi-e a kivitelezési költségeket stb.............35 A technikai (szakmai) értékelés során a projekttel megoldani kívánt probléma elvi aspektusait vizsgálják: a megoldandó probléma természete és kiterjedése, a lehetséges megoldási alternatívák és a megoldásként kiválasztott alternatíva megfelelősége, a célok és az alkalmazni kívánt módszerek összhangja, a tervezés módszerének és a kiválasztott megvalósítási technikák helyessége, a projektterv (pl. ütemezés) realitása stb.........................................................................................................35 A szervezeti kérdések a megvalósító szervezet (és a közreműködő szakemberek) tapasztalatait, referenciáit, felkészültségét foglalják magukban, beleértve azokat a szervezeti, intézményi kereteket is, amelyek a projekt befejezése után annak működtetését biztosítják......................................................................................................35 Esetenként értékelési szempont lehet a projekt eredményeinek és tapasztalatainak szélesebb körű hasznosítása, disszeminációja, illetve ezek biztosítása.......................35 Az értékelés során számos esetben külön figyelmet fordítanak arra, hogy a projekttulajdonos (klaszter egésze, klasztertagok konzorciuma vagy egyedi klasztertag) megfelelően megtervezte-e a projekt előrehaladásának ellenőrzését, azaz a projekt értékelését, ellenőrzését, monitoringját............................................................35 1.4.4 A projekt-monitoring......................................................................................................39 A kritikus tevékenységekre, hiszen ezek bármilyen csúszása a projekt egészének határidejét veszélyezteti.......................................................................................................41 A hosszú átfutási idejű tevékenységekre, amelyek esetleg lerövidíthetők a teljesítmény fokozásával, amivel időt lehet nyerni..................................................................................41 Az átlagnál több és költségesebb erőforrást igénylő tevékenységekre..............................42 2 A projektnyilvántartás és követés....................................................................................................................44 3 Javaslat a megvalósításra....................................................................................................................................48 3.1 A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének alapkövetelményei................................................................................................................49

5

3.1.1

A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének informatikai fogalmi alapvetései............................................................50

3.1.2 A rendszer főbb integrációs elemei..............................................................................51 3.1.3 Tartalomkezelés............................................................................................................54 3.1.4 Biztonság.......................................................................................................................56 Kommunikációs alapú – a hálózaton keresztül, védelmek megkerülésével transzferált információk............................................................................................................................56 Hozzáférés alapú – védelmeken keresztüli, jogosultnak tűnő, ám valójában jogosulatlan bejelentkezés, illetéktelen azonosító-használat révén transzferált információk...........56 Kommunikációs alapú – a hálózaton keresztül, védelmek megkerülésével eltávolított információk............................................................................................................................57 Hozzáférés alapú – védelmeken keresztüli, jogosultnak tűnő, ám valójában jogosulatlan bejelentkezés, illetéktelen azonosító-használat révén eltávolított információk............57 3.1.5 Elérhetőség, rendelkezésre állás..................................................................................57 3.1.6 Fejlesztő és integrációs eszközök, platformok.............................................................59 3.1.7 A megbízható üzemeltetés alapja.................................................................................59 3.2 Az információs rendszerhez illeszkedő adatmigrációs javaslat......................................61 3.2.1 A rendszer elemei.........................................................................................................62 3.2.2 A rendszerelemek értelmezése....................................................................................68 3.3 A felhasználók számára nyújtott szolgáltatások................................................................76 3.3.1 Felhasználói csoportok.................................................................................................76 3.3.2 A rendszer alapszolgáltatásai.......................................................................................77 3.4 A megvalósítás logikai rendje..............................................................................................82 3.4.1 A megvalósítandó lépések............................................................................................82 Az emberi erőforrások kiválasztása, a projekt-team konkrét közreműködőinek, szakértőinek megnevezése. A résztvevők megismertetése a projekt céljaival, terveivel,

a

megvalósítása

kapcsán

felmerülő

szerepükkel,

végrehajtandó

feladataikkal, a szervezet tagjainak globális, személyes indító konzultációja..............82

6

A fejlesztéshez, tervezéshez szükséges technikai feltételek megteremtése, a meglévő eszközök tesztelése, a szükséges beszerzések megvalósítása......................................82 A projekt információs csatornáinak kiépítése, különös tekintettel az elektronikus kapcsolattartás eszközeire...................................................................................................82 Az implementációt előkészítő elméleti előkészítés (jelen dokumentum) ............................82 Az elméleti előkészítés eredményeinek elfogadása...............................................................82 A szakaszt összefoglaló dokumentációk elkészítése.............................................................82 Részletes rendszerterv elkészítése, azaz a megvalósítandó rendszer funkcióinak és működtetési

környezetének

pontos

meghatározása.

Tartalmazza

a

követelményrendszert, a segédfunkciók, utilityk leírását, áttekinthető funkciótervet, menüstruktúrát, működtetési tervet, azaz a rendszer moduláris kapcsolatrendszerét. .................................................................................................................................................82 Részletes adatbázisterv elkészítése, azaz a megvalósítandó rendszer adatmodelljének és adatbázistervének pontos definiálása. Tartalmazza a logikai adatmodellt, a megvalósítandó fizikai modellt, az adattáblák oszlopainak magyarázatát, az azokra vonatkozó formai és tartalmi előírásokat, restrikciókat, adatfolyam-diagramot...........82 A rendszer-, és adatbázisterv elfogadása................................................................................83 A szakaszt összefoglaló dokumentációk elkészítése.............................................................83 A programozási tevékenység megtervezése, azaz a programozási feladat eszköz-, humán-,

és

kapcsolati

erőforrásainak

és

azok

kapcsolati

rendszerének

meghatározása......................................................................................................................83 Programozás, a rendszer-, illetve adatbázistervek alapján a rendszer számítógépes implementációja. Megvalósítása során:.............................................................................83

7

meg kell határozni a már rendelkezésre álló modulokat, részmegoldásokat, melyeket a fejlesztés során fel lehet használni,..............................................................................83 figyelmet kell fordítani az ajánlott névhasználat konvencióira,.............................................83 ügyelni kell a felhasználói felület kialakítását szabályozó belső szabványokra,..................83 a programokat el kell látni ún. kommentekkel,......................................................................83 a fejlesztőknek el kell végezniük az egyes programrészletekre, illetve modulokra a fejlesztői tesztet, mely elemi módon ellenőrzi a megírt program működőképességét, 83 A programozási tevékenység elfogadása, esetleges visszacsatolások elvégzése............83 A szakaszt összefoglaló dokumentációk elkészítése.............................................................83 Az megbízható üzemeltetéshez szükséges esetleges hardver fejlesztések, beszerzések megvalósítása........................................................................................................................83 Belső rendszerteszt, ennek figyelése, ez alapján a szükséges korrekciók megvalósítása, a rendszertervben megfogalmazottak megvalósulásának ellenőrzése, a kezelhetőség, megbízhatóság, működési metódusok minősítése, megfelelő visszacsatolások folyamatos elvégzése, jobbító intézkedések átvezetése..................................................83 Információfogadás, kezdeti adatkinyerés, azaz a rendszer adatokkal történő feltöltése, kritikus adatmennyiség-kísérletek, konkurens hozzáférések figyelése. A nagytömegű adatkezelés, az általános válaszidők ellenőrzése, konkurens hozzáférés zavartalan biztosítása, azaz annak tesztelése, hogy a párhuzamosan, ugyanazon adathalmazon dolgozó munkaállomások ne zavarják egymást. Kulcsfontosságú szempont az ún. deadlock szituációk kiszűrése.............................................................................................84 A rendszert hasznosítani tudók bevonása a tesztelési folyamatba, pilot projekt indítása, a rendszer

használatának

„laikus

felhasználó”

általi

minősítése,

megfelelő

visszacsatolások folyamatos elvégzése, jobbító intézkedések átvezetése...................84 A tesztelési tevékenység elfogadása........................................................................................84 A szakaszt összefoglaló dokumentációk elkészítése.............................................................84 Az üzemszerű működés teljes körű beindítása. A megvalósítás során a projektvezető. . .84

8

gondoskodik az installáló anyagok és installálási/üzembehelyezési forgatókönyv összeállításáról,............................................................................................................84 megszervezi a végleges üzembe helyezés feladatait, és egyezteti a feladatokat,..............84 feladata a sikeres záró telepítés, a funkcionális működőképesség bemutatása, a kapcsolódó alapoktatás valamint a belső átadás/átvétel utáni teljesítési jegyzőkönyv elkészítése,...................................................................................................................84 megszervezi a záró „üzemi próbát”, s annak kiértékelését jegyzőkönyvben rögzíti,...........84 gondoskodik az installáló anyagok elhelyezéséről, valamint azok megfelelő védelméről,..84 megszervezi a kapcsolódó üzemeltetési oktatást, betanítást. Ehhez biztosítja a megfelelő oktatási anyagokat, segédletet, számítástechnikai hátteret, oktatót/oktatókat, ütemezést......................................................................................................................85 Járulékos intézkedések, a projekt „utóéletének” biztosítása. Ez jelenti a más projektben is

használható

megoldások

dokumentálását,

a

fenntarthatóság

érdekében

foganatosított intézkedések, „utóéletért” felelős funkciók és személyek kijelölése....85 Az eredmények publikálása, a rendszer várható eredményeinek második lépcsős felvázolása, a hasznosulás társadalmi és pénzügyileg kifejezhető értékelése.............85 A szakaszt záró, összefoglaló dokumentációk elkészítése...................................................85 3.4.2 A feladatok időbeli ütemezése......................................................................................85 4 Mellékletek...................................................................................................................................................................86

9

1 ALAPELVEK ÉS ALAPKÖVETELMÉNYEK

10

1.1 A Bakony-Balaton Mechatronikai és Járműipari Klaszter 1 projektcsatorna rendszerének premisszái A tanulmány készítésének hátterét jelentő projekt lényege a Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének kialakítása és fenntartható fejlesztése, mely 

a klaszter tagjaira és elsősorban a Bakony-Balaton térségének területi lehatárolására vonatkozik



ugyanakkor figyelembe veszi és kiaknázza a Bakony-Balaton térségén túlmutató

szinergikus

hatásokat

és

interregionális

együttműködési

lehetőségeket 

felállításakor a Közép-Dunántúli Régió stratégiájában nevesített, meghatározó iparágai közül a mechatronika és a járműipar iparágai köré szerveződik



kiterjesztett célja a minél teljesebb iparági kooperáció, melynek érdekében a kialakított

hierarchiában

a

klasztertagságtól

eredő

kezdeményezéseket

összefogó, menedzsment szervezet szuperponálódik A projektcsatorna rendszer létrejöttének kiterjesztett céljai 

a KKV-k foglalkoztatási szerepének megőrzése,



fejlődésük segítése, különösen innovatív képességük fejlesztése révén,



valamint

a

térségben

megjelent

külső

működő

tőke

beágyazása,

megtartásának elősegítése. A Bakony-Balaton Mechatronikai és Járműipari Klaszter közösségén 

a mechatronika és járműipar területéhez kötődő,



a Bakony-Balaton térségében koncentrálódott



együttműködő kis- közép és nagyvállalkozások, K+F intézmények, fejlesztési

1

A Bakony-Balaton Mechatronikai és Járműipari Klaszter 2012. április 4-én, az Ajkai Mechatronikai

és Járműipari Klaszter és a Közép-Dunántúli Regionális Innovációs Klaszter fúziójával jött létre, elődszervezetei jogutódjaként

11

szervezetek formális hálózatát értjük. A Bakony-Balaton Mechatronikai és Járműipari Klasztert tekintve elmondható, hogy az utóbbi esztendőkben a átlépte a pusztán ipari tevékenység határait, és az együttműködés egyre inkább az innováció, K+F, hozzáadott érték termelés felé irányult. A klaszter-közösséget befogadó – egyben lehatároló - térség társadalmi, gazdasági és környezeti jellemzőinek nyomon követéséhez, a változások figyelemmel kíséréséhez, illetve azok előrejelzéséhez többszintű, egymással együttműködni

képes

információ-rendszerekre

van

szükség.

Az

ilyen

rendszerekkel kapcsolatos alapvető követelményeket és funkciókat – ebben a fejezetben még csak a legáltalánosabb szinten tekintve – nemcsak technikai, technológiai

oldalról

kell

vizsgálni,

hiszen

lényeges

gazdaság-

és

társadalompolitikai kérdések is kapcsolódnak hozzá. Mind a társadalmi, mind a gazdasági,

mind

a

technológiai

aspektusokkal

összefüggésben

releváns

problémaként fogalmazódik meg továbbá az uniós alapelvekhez való illeszkedés, pontosabban ezen alapelvek érvényesülésének elősegítése.

1.1.1 A projektcsatorna-rendszer társadalmi-gazdasági funkciói Egy projektcsatorna rendszernek funkciója szerint nem csupán leírni, követni vagy előre jelezni kell a projektalapon szerveződő folyamatokat, hanem elő is segíteni ezek kiteljesedését. A Bakony-Balaton Mechatronikai és Járműipari Klaszter által létrehozott, működtetett és felügyelt rendszerrel szemben támasztott alapvető követelmény, hogy a klaszter tagjai akkor és azon a helyen férjenek hozzá az őket érdeklő

projektalapú

információkhoz,

a

projektek

létrejöttét

segítő

szolgáltatásokhoz, ahogy kívánják - mindezt a legegyszerűbb módon. A klaszter közösségébe tartozó tagok számára létfontosságú, hogy minél gyorsabban és pontosabban juthassanak az üzletmenetükhöz szükséges információhoz, illetve üzletmenetük projektalapú eredményesebbé tétele érdekében tehessenek közzé saját információkat - biztosítva ezzel versenyképességüket a hazai és nemzetközi piacon egyaránt. 12

Mindezek mellett az információs társadalom követelményeire és hatásaira is figyelemmel kell lenni, ami új dimenzióba helyezi a térségi és iparági együttműködés lehetőségeit. Az internetalapú, szabad hozzáférésű technikák egyrészről lehetőséget kínálnak tagság jobb információ ellátásához, hatékonyabb együttműködéséhez. Az információs társadalom megteremti a modern információés kommunikáció-technológiával széles körben élni tudó közösségeket. Ennek érdekében, a projektcsatorna rendszer informatikai háttérbázisául: 

olyan

konstrukció

kialakítása

szükséges,

melyek

a

projektcsatorna

szolgáltatásokat a klaszter tagjai és környezetük szereplői (szállítók, vevők, partnerek)

számára,

természetesen

szelektáltan,

becsatornázottan,

ténylegesen elérhetővé teszik. 

a tagokat segíteni szükséges abban, hogy képessé váljanak a modern információ- és kommunikáció-technikai eszközök használatára. Lehetővé kell tenni, hogy megismerjék a technikai kultúrát, az informatika adottságait és élni tudjanak az azok nyújtott lehetőségekkel, beépüljenek mindennapjaikba.

1.1.2 Az uniós alapelvek megjelenése a projektcsatorna rendszerben Az előbbiekből egyértelműen kitűnik, hogy a projektcsatorna rendszer léte és funkciója több szálon is erőteljesen kötődik az uniós alapelvekhez és elvárásokhoz. Ez a kapcsolat kétirányú, egyrészt meg kell felelni ezeknek az alapelveknek, másrészt elő kell segíteni azok érvényesülését. Egy regionális szintű, stratégiai szövetségre alapozott információs rendszernél figyelembe veendő legfontosabb alapelvek az alábbiak: 

Szubszidiaritás A szubszidiaritás elve értelmében minden problémát azon a szinten kell kezelni, ahol az a leghatékonyabban és a legoptimálisabban megoldható. Informatikai szempontból ez két oldalról is megközelíthető: egyrészt arról van szó ugyanis, hogy a döntéseknek azon a szinten kell megszületni, ahol a legnagyobb az informáltság és a döntések következményeinek vállalhatósága, s az ehhez szükséges információk rendelkezésre állnak. Másrészt viszont 13

minden döntési szintet el kell látni a hatékony és eredményes működéshez (döntéshozatalhoz) szükséges információkkal. Az információs rendszerek lényegében a döntésekhez szükséges információkat szolgáltatják. Minthogy a különböző szinten hozandó döntések összefüggnek (a klaszter közösségének menedzsment szervezetében és egyes tagjainál is), az információ-rendszer terén is olyan működést kell támogatni, hogy a különböző szereplők érdekei érvényesítésére a befolyásolás lehetőségeit biztosítsa a magasabb döntési szinteken is, ugyanakkor integrálja az alacsonyabb szintek döntéseit. 

Partnerség Nyilvánvaló következménye az előzőeknek is, hogy a létrejövő rendszernek együtt kell működnie mind a magasabb szintű (országos) rendszerekkel, mind az eltérő célból létrejött külföldi, más régióbéli, intézményi, vállalkozói stb. rendszerekkel. E tekintetben a közreműködő partnerek autonómiájának (és természetesen az érvényes jogszabályoknak) tiszteletben tartása mellett elsősorban az adatelérés, inputszolgáltatás feltételeit kell megteremteni. A fejlesztés követelménye ebből adódóan a nyílt rendszer elv betartása, amely biztosítja

a

rendszerek

–

első

megközelítésben

statikus

-

összekapcsolhatóságát, az információk megosztását. 

Forráskoncentráció Egy projektcsatorna rendszer fejlesztése és működtetése olyan folyamat, amelyet csak elkezdeni lehet, de gyakorlatilag sohasem fejeződhet be. Az igények gazdagodása a rendszer tartalmi és területi hatáskörét, kapcsolati viszonyait folyamatosan módosítja, amihez biztosítani kell a rendszer működtetésének feltételeit. Informatikai megközelítésben mindez a hardver, szoftver, alkalmazói rendszerek, hálózatok, humán feltételek kategóriáját jeleníti

meg.

A

rendszer

fejlesztése

(és

továbbfejlesztése)

során

a

fokozatosság elvének betartásával a legnagyobb hatékonyságot ígérő fejlesztésekre kell koncentrálni az erőforrásokat, figyelemmel az együttműködő rendszerek fejlesztési és működtetési követelményeire. 

Addicionalitás A különböző szintű és jellegű projektcsatorna rendszerek fejlesztése és működtetése az abban érdekeltek jó együttműködésének feltétele is. Ez 14

egyben a különböző helyeken rendelkezésre álló források (támogatáspolitikai eszközök,

tudásmegosztó

eredményezheti.

A

erőforrások

rendszerek

tekintetében

fejlesztésénél

a

is)

egyesítését

központi

is

források

felhasználása, a helyi célok és források egyesítése mellett a különböző pályázati formában elnyerhető források felhasználhatóságát is számításba kell venni. Ehhez – kapcsolódva a partnerségnél mondottakhoz is – ki kell dolgozni a különböző rendszerek (általános és informatikai) együttműködésének modelljét. 

Programozás A projektcsatorna rendszer fejlesztése és összehangolt működtetése feltételezi a koordinációt. Az egyes szerelők együttműködéséhez – az autonóm célok tiszteletben tartása mellett – meg kell fogalmazni azokat a szervezési elveket, beleértve az informatikai követelményeket is, amelyek lehetővé teszik a rendszerek harmonikus együttműködését.

Jelen dolgozat keretében az előzőekben kifejtett általános alapelveket és általános követelményeket olyan szakmai követelményekké transzformáljuk át, amelyek a rendszer tervezésének és fizikai megvalósításának, általános és informatikai működtetésének egyaránt az alapját jelentik. Már az eddigiek alapján is előrebocsátható, hogy ezek az alapelvek egy koncentrált, ugyanakkor nyílt (és globális) projektcsatorna rendszer igényéhez vezetnek, ami informatikailag leginkább egy, a Bakony-Balaton Mechatronikai és Járműipari Klaszter információs rendszerének magvát jelentő internetes portál keretein belül jeleníthető meg. A koncentráltság megjelenése a megvalósítás kötelező eleme, hiszen a projektcsatorna rendszer nem más, mint a klaszter projektalapú információinak, kapcsolati közegének praktikus koncentrátuma. A rendszer elsődleges alakítói a klasztertagok projektalapú információi valamint a releváns, nyílt hozzáférésű, on-line módon elérhető elemek támogató információi, hírei

(pl.

pályázati

lehetőségek,

befektetési

információk,

partnerkereső

adatbázisok). A projektcsatorna rendszer révén létrejött integráció kiterjesztve a régió

autóiparának,

mechatronikai

iparának

15

belső

működését

teheti

hatékonyabbá, megteremtve a gyors és megbízható adatáramlás lehetőségét. A nyitottság és a globalitás megfelelő jogosultságokkal párosuló megvalósítása mindenekelőtt a klaszter www.bbmjk.eu URL-en elérhető portáljának révén biztosítható. A klaszter megújuló honlapján, portálján kialakítandó projektcsatorna szegmens létrehozásával és működtetésével kapcsolatos alapkövetelmény, hogy tegye lehetővé az adatokkal, eseményekkel és alkalmazásokkal való szoros integrációt, nyújtson személyre szabott hozzáférést a különböző forrásokból (elsősorban klasztertagoktól) származó adatokhoz. A projektcsatorna rendszer információinak kezelésére tehát a célorientált, egyszerű, könnyen használható és könnyen testre szabható, a klaszter hivatalos portáljának részeként felépített, web-alapú alkalmazás jelentheti a megoldást, mely egységes felületet teremt az alkalmazások, adatforrások eléréséhez, kezeléséhez. A projektcsatorna rendszer segítségével speciális információk „beszerzése” történhet meg, közhasznú információk tehetők közzé, emellett remek lehetőséget nyit a partnerek elektronikus kapcsolattartására. A személyre szabhatóság a biztosítéka annak, hogy a rendszer szereplői (mint felhasználók) számára rendelkezésre álló adatok, komponensek az egyén szerepétől függően legyen elérhető, illetve informatikailag megjeleníthető. A klaszter közösségének fejlődésének szempontjából a leginkább priorizálható területek a projektalapú együttműködés „gépezetének”, a közös stratégiai alapelveknek kidolgozása, és a rendelkezésére álló eszközök és források optimális felhasználásának projektalapú támogatása, azaz a projekt-fejlesztés feladatainak komplex kezelése.

16

1.2 A projektcsatorna rendszer működtetésével kapcsolatos alapvetések A A Bakony-Balaton Mechatronikai és Járműipari Klaszter tagjainak többsége, hasonlóan az ország más térségeihez a globális gazdasági válság kialakulása óta akkut tőke- és forráshiányban szenved. A tőkehiány és a forrásproblémák mellett a helyzet kezeléséhez kapcsolódó tapasztalat is hiányzik, amely még az előző tényezőnél is súlyosabb gondot jelent a vállalkozások, intézmények számára. A tagok többsége szervezetileg felkészületlen a kihívásoknak való megfelelésre jelen helyzetben. A projektcsatorna rendszer kialakításának és a klasztertagok projektalapú

együttműködései

szükségességének

gazdaságpolitikai

indoka

hármas: 

a klaszterekben a közszféra a KKV-k fejlődését támogatja; a KKV-k foglalkoztatásban

betöltött

szerepe

nyilvánvaló,

a

nagyvállalatok

termelékenység növelése létszámleépítéssel jár együtt, amelyet a KKV-k szívhatnak

fel;

Jelen

helyzetben

azonban

a

KKV-k

forrás-

és

eszközlehetőségei erősen korlátozottak, mely a természetszerűen kialakuló folyamatok ellen hat. 

a globalizált és válságban lévő világgazdaság korában a multinacionális nagyvállalatok nem kötődnek térséghez, termelésüket profit maximalizáló célrendszerük függvényében viszonylag könnyedén telepítik egyik régióból a másikba, a KKV-k viszont erősen helyhez kötöttek, egy térség gazdaságának integráns, elválaszthatatlan részét képezik. A működő tőke vonzására, a nagyvállalatok betelepítésére nagyobb az esélye azoknak a régióknak, amelyek adott húzóágazatban (ld. járműipar, mechatronika) együttműködő vállalatokkal,

adekvát

ipari

infrastruktúrával

és

szolgáltatási

háttérrel

rendelkeznek; 

a támogatások jobban hasznosulnak és hatékonyabbak, amennyiben nem egy-egy klasztertag kapja azokat, hanem a tagság egésze vagy a tagság egy csoportja részesül belőlük.

17

1.2.1 A projektalapú együttműködés indokoltsága, főbb területei A Bakony-Balaton Mechatronikai és Járműipari Klaszter tagságának projektalapú együttműködései 

költség-megtakarítást

képesek

elérni

vásárlói

pozícióikban

(pl.

közös

energiavételezés), 

termelékenységük javul (eltérő intenzitású és elvárású vevői igények kiszolgálási képessége fejlődik a közös kompetencialeltárak révén),



innovációs képességük nő (a K+F keresleti- és kínálati oldalának projektalapú illesztése révén),



közös és összehangolt piaci megjelenésük szintén erőt demonstrál, valamint költséget takarít meg (közös marketing, nagyságrend, kapacitás).

A Közép-Dunántúli Régió a Bakony-Balaton Mechatronikai és Járműipari Klaszter révén egy stabil hálózati szerveződést mondhat magáénak. A klaszter projektcsatorna rendszerének nevesíthető hozadéka, előnyei 

az együttműködés, a partnerség kultúrájának erősítése, mely a kollektív tanulással és innovációval, mint kulcs-kifejezésekkel jellemezhető



az iparági szereplők versenyképességének növelése



a támogató intézmények támogatási hajlandóságának erősödése, elsősorban a kialakuló projektek előkészítése és megindításához kapcsolódó támogatási kérelmek (pályázatok) benyújtása révén

A projektcsatorna rendszer fontos alapelve kell, hogy legyen ugyanakkor az is, hogy saját tevékenységéért, információszolgáltatásáért ki-ki önállóan felel, és a tagok tudomásra jutott (esetenként bizalmas!) információk felhasználása az információszolgáltató tag önálló piaci tevékenységét semmiben nem korlátozza, visszaélésszerű tevékenységet nem eredményez. A projektcsatorna rendszer keretében a fő cél megerősíteni a klasztertagok

18

projektalapú együttműködését - a konzorciumvezető klasztermenedzsmentszervezet regionális szintű koordinálásával. A projektcsatorna rendszer 

nem csak az egyes klaszter-tagok saját projektjeinek fejlesztését és megvalósítását jelentené,



hanem a tagok együttes projektjeinek fejlesztését is,



amellyel új piaci területekre léphetnek ki



és közösen, komplex fejlesztési feladatokat valósíthatnak meg.

A projektcsatorna együttműködés további speciális előnyöket jelent az alábbi területeken: 

kapcsolati tőke megosztása



összehangolható metodika kialakítása



kölcsönös támogatás



összehangolt beszerzés



erőforrás biztosítás

Fentiek alapján elmondható, hogy - a klasztertagok egyedi elképzeléseit felvázolva -, a lehetséges fejlődési irányokat meg lehet határozni és közös együttműködés

eredményeként

integrált

fejlődési

pályákat,

konkrét

együttműködéseket kialakítani. Ilyen együttműködési területek lehetnek pl. a tagok energiaellátásának közös projektje vagy kiállításokon, vásárokon való együttes megjelenés. A

koordináló

projektalapú

menedzsment

szervezet

(Közép-Pannon

Zrt.)

rendelkezik

partner-közvetítéshez szükséges szervezetek, befektetői- és

hitelezési információkkal bír és folyamatosan hírt kap pályázati felhívásokról, kapcsolati tőkéjét szintén megosztaná a klasztertagokkal. A projektcsatorna rendszer informatikai platformja összekapcsolja a regionális menedzsmentet a tagokkal; Kialakul, és rendszeressé válik az egymás közti olyan kommunikáció, amely a rendszeressége következtében minden tag számára egy általános 19

gazdasági képet nyújthat és projektalapú fejlődésüket nagymértékben segítheti. Ezek az információs többletek lehetőséget biztosítanának ahhoz is, hogy a tagok hazai, illetve a határon átívelő pályázatokon részt vegyenek, illetve hazai és külföldi

klaszterekkel

és

klasztertagokkal

együttműködési

kapcsolatot

létesíthessenek. A tervezett projektcsatorna rendszer fő, egyedi előnyei tekintetében - fenti gondolatokon túlmenően, kiegészítésként - az alábbiak említhetők 

Tematikus integráció projekt-szinten



Erőforrás hozzáférés, utánpótlás biztosítása



Nagy projektek kivitelezhetősége



Komplex szolgáltatások létrehozhatósága



Infrastrukturális megtakarítások



Összehangolt − marketing, − oktatás, − minőség-ellenőrzés, − metodikák



Átjárható (kölcsönösen igénybe vehető) projekt menedzsment-háló



Kölcsönös pénzügyi, számviteli, jogi, munkaügyi támogatás



Összehangolt beszerzések, nagyobb volumenből eredően jobb tárgyalási pozíciók megszerzése

20

1.3 A koncepcióalkotással kapcsolatos alapvetések Az elkészítendő projektcsatorna rendszer egyik alapvető funkciója, hogy segítse a klaszter-tagok projektalapú együttműködésének koncepcionális, stratégiai és operatív feladatait. Fontos tehát, hogy mindenekelőtt rögzítsük az ezzel kapcsolatos alapelveket és alapkövetelményeket, ezen belül az Európai Uniós elvárásokat és előírásokat, egyebek között a vonatkozó uniós jogszabályok és módszertani ajánlások alapján. A

Bakony-Balaton

Mechatronikai

és

Járműipari

Klaszter

projektcsatorna

rendszerének kialakítása során 

egyfelől a klaszterintegráció belső jellemzőit kell, hogy alapul vegye,



másfelől azonban szükséges külső környezetének vizsgálata.

Előbbi információgyűjtése belső kutatáson, klasztertagok adatszolgáltatásán hogy alapuljon, míg utóbbi információk hazai és uniós dokumentumokon, befektetési és forráshoz jutási információkon kell, hogy alapuljanak. Mivel a belső adatgyűjtés alapvetései maguktól értetődőek, a következő fejezetekben a külső környezet statisztikákon, mutatókon, indikátorokon alapuló feltérképezéséhez fogalmazunk meg ajánlásokat – természetesen beleszőve belső jellemzőkre vonatkozó megállapításokat is.

1.3.1 Mutatók, indikátorok a klasztertagok specifikumainak és a környezet projektalapú elvárásainak tükrében 1.3.1.1 A mutatók alkalmazásának hazai és uniós elvei és gyakorlata Az uniós törekvések egyértelműen olyan mutatók kialakítására és figyelésére irányulnak,

amelyek

révén

egyszerűen

mérhető

és

kezelhető

adott

szervezet/integráció teljesítménye projektalapú fejlesztéseinek tükrében. Az EU számos területen alkalmaz olyan mutatókat, melyek ajánlásként mindenki számára hozzáférhetőek, s mely mutatókat kétféle helyzetben alkalmazzák:

21



Az egyik az egyes klaszter-tagok direkt gazdasági mutatói, melyek akkor kerülnek előtérbe, amikor olyan jelentős, a klaszter egészére vonatkozó stratégiai döntéseket kell hozni, mint például a tagi befizetések kérdésköre vagy a rendelkezésre álló pályázati források felhasználásának egyedi szabályozása



A

második

megközelítés

klaszter-szintű

együttműködések

mutatóinak

számszerűsítésére, a közös működés monitoringjára, valamint az elért hatások becslésére vonatkozik. Ezek a mutatók a Bakony-Balaton Mechatronikai és Járműipari Klaszter közösségének egészét vagy egy-egy integrált projekt által érintett részközösségét érintik. Ezek a mutatók megpróbálják figyelemmel kísérni, amennyire lehetséges, a klaszter működésének közvetlen és közvetett hatásait. A monitoring és értékelés keretében egy-egy mutató képes megmutatni, hogy egy adott – a közösség egészét vagy több tagját érintő projekt sikeres volt-e, vagy kudarcot vallott.

A vállalatokat és háttérintézményeket magába foglaló klaszter közösség integrált projektkezdeményezéseinek mindenekelőtt be kell mutatni az érintett tagokat és azok kumulált adatait, valamint környezetét. Mindez oly módon történjék, hogy mindezek alapján feltárható legyen a klaszterközösség (vagy annak egy része) stratégiai helyzete, s módot adjon az időbeli változások vizsgálatára, az integrált projektek általános hatásainak mérésére. Az integrált projektek végrehajtásától remélt célkitűzések számszerűsítése érdekében – meg kell határozni olyan, általános jellemzőket is, melyek a külső környezet vizsgálatakor három fő területre terjednek ki: 

Alap infrastruktúra: telephelyi jellemzők (épületek, közlekedés, logisztika)



Humán erőforrások: oktatás, szakképzés, kutatás és technológiafejlesztés



Termelő infrastruktúra: a termeléshez kötődő, esetenként speciális iparági (mechatronikai, autóipari) jellemzők

Az egyes projektek, projektötletek kezdeményezése során felmerülő egyedi 22

adatkategóriákat tehát 

egyfelől a klasztertagok saját adatgyűjtésben kell, hogy meghatározzák,



másfelől döntően egy - a meglévő kumulált adatgyűjtési rendszerekre, klaszterszintű információs rendszerekre támaszkodó – adatgyűjtő rendszert kell kiépíteni és működtetni.

1.3.1.2 Indikátortípusok és célrendszer A Bakony-Balaton Mechatronikai és Járműipari Klaszter leírásához, jellemzéséhez szükség van statisztikai adatokra és mutatókra. Ezen mutatók egy része rendelkezésre áll, más része azonban egyedi (számos esetben folyamatos) adatgyűjtést igényel. Az alábbi táblázatban összefoglaljuk azokat a fontosabb mérőszámokat, melyek a Bakony-Balaton Mechatronikai és Járműipari klaszterszintű mutatóit számszerűsítik, s lehetőséget adnak a közös működés monitoringjára, valamint az elért hatások becslésére.

23

2008

2009

Terv - 2013

Terv - 2018

2009 - 2013

2009 - 2018

(Terv)

(Terv)

növekmény %

növekmény %

Árbevétel - e Ft

115 171 173

97 032 359

101 883 977

106 735 595

5,00%

10,00%

Ebből kkv - e Ft

42 353 018

38 395 692

38 779 649

39 167 445

1,00%

1,00%

36,77%

39,57%

38,06%

36,70%

81 557 629

70 943 037

71 443 036

71 693 036

0,70%

1,06%

38 188 905

35 703 954

36 060 993

36 421 603

1,00%

1,00%

46,82%

50,33%

50,48%

50,80%

Közös projektek száma

0

3

9

14

200,00%

366,67%

Közös projektek ráfordításai - eFt

0

120 000

180 000

300 000

50,00%

150,00%

4 839

4 293

4 293

5 108

0,00%

18,98%

1 004

1 017

1 017

1114

0,00%

9,54%

20,75%

23,69%

23,69%

21,81%

Ebből kkv - % Export

árbevétel

az

össz-

árbevételből - e Ft Ebből kkv - e Ft Ebből kkv - %

Átlagos

statisztikai

létszám - fő Ebből kkv - e Ft Ebből kkv - %

állományi

24

Nem ennyire egyértelmű azonban a helyzet minden esetben. Nehézséget okozhat, hogy a fejlesztési célkitűzések, illetve a célok elérése érdekében megvalósított projektek (pl. egy beruházás) összetettek, komplex hatásúak, ezért lehet, hogy ami egyfelől nem tűnik hatékonynak (pl. túl költséges), az egy másik paramétert (pl. piacszerzés termékrésekben) kedvezően befolyásol. Ugyancsak tipikus probléma az eredmények nehéz mérhetősége, különösen, ha valamilyen minőségi hatás (pl. egy képzési programban szerzett ismeretek hasznosulása) elérése a cél. Azonban ha nincsenek világosan és számszerűsíthetően megfogalmazott célok, akkor azok elérése, megvalósulása sem ellenőrizhető egyértelműen, nem tudható, hogy sikerült-e a kívánatos irányba befolyásolni a folyamatokat. Az ellenőrizhetőség alapja tehát az, hogy jól megválasztott, megbízhatóan mérhető adatokkal, számszerű mutatókkal – indikátorokkal – jellemezzük a célokat, a programokat, az elérni kívánt eredményeket. Az indikátoroknak természetesen

megalapozottnak,

a

helyzetértékelésben

megállapítottakkal

összhangban állónak kell lenniük. A jó indikátor emellett egyszerűen (számviteli, vagy statisztikai úton) mérhető, objektív, legalább a szakemberek számára általánosan elfogadott és könnyen érthető. A Bakony-Balaton Mechatronikai és Járműipari Klaszter integrált projektjeinek mérése, monitoringja során az indikátorok négy típusa javasolt: 

Az input indikátorok a felhasznált erőforrásokat (pénz, emberi erőforrások, technika) mérik, vagyis azt hogy milyen ráfordításokat igényel egy program, projekt. Az erőforrásigény mindig finanszírozási igényt is jelent, tehát végső soron arról a program végrehajtásának pénzügyi igényét jelzi változatlan áras 25

értékekkel. 

Az output indikátorok a projekt közvetlen eredményét, fizikai kibocsátását (a megvalósított terméket, szolgáltatást, fizikai kibocsátását méri, általában valamilyen természetes mértékegységben, nominális skálán (pl. hány fő vett részt a tanfolyamon, hány kisvállalkozás fejlesztett ki új piaci terméket és milyen értékben stb.). Az output indikátor tehát a projekt mérőszáma, ezen alapul a projektkiválasztás (a hatékonyságmérés) és a teljesítésigazolás (ellenőrzés). Tipikusan számviteli vagy közvetlen adatfelvételes úton kerül mérésre.



Az eredményindikátor egy általánosabb szintet jelent, egy alcél teljesülését, a projektek közvetlen hatását, hatásosságát, a projektek eredményeként bekövetkezett változást méri. Pl. egy tematikus stratégiai együttműködés keretein belül kialakított termelési lánc létrejöttét követő hatás lehet, hogy lerövidülnek a gyártási idők, csökkennek a gyártási költségek stb.



A hatásindikátor már az átfogó, hosszú távú célokhoz kapcsolódik. Ez az előzőnél is elvontabb, általánosabb, és általában összetett elemzést, hatásmechanizmus vizsgálatot, idősorok elemzését igényli. Például a stratégiai termelési láncok munkahelyteremtéshez is hozzájárulhatnak, eredményezhetik a környezetszennyezés csökkenését stb. A példák egyúttal jelzik, hogy e kategórián belül megkülönböztethetők a rövidebb időtávú, közvetlen vagy specifikus

hatások,

és a

hosszabb

távú,

szélesebb

célcsoportra,

a

klaszterközösség egészére vagy még kiterjesztettebb körre vonatkoztatott globális hatás. A tervezés fontos eleme tehát, hogy a különböző szinten megfogalmazott célokhoz olyan mutatókat, indikátorokat rendeljünk hozzá, amivel a közvetlen eredmények és a hosszabb távú célok (hatások) egyaránt ellenőrizhetők 2. A céloknak és az indikátoroknak ezt az egymásra épülő hierarchikus struktúráját szemlélteti az alábbi ábra: 2

Az indikátoroknak bármelyik típusának – tartalmát tekintve – öt alapvető kérdésre kell választ adniuk: kik az

output használói, a hatás haszonélvezői (célcsoport); mennyi az adott idő alatt elérendő cél-érték, minőségi jellemzők, hol és mikor realizálódik az output/hatás.

26

Input (források, ráfordítások)

Hatás (hosszú távú, átfogó)

Hosszú távú, átfogó cél

Eredmény (közvetlen és azonnali hatás)

Közvetlen célok, alcélok

Output (előállított termék, szolgáltatás)

Operatív célok

Célhierarchia

Projektvégrehajtás

Ez a rendszerezés és rendszerezettség lehetőséget nyújt például a mindenkor rendelkezésre álló források alapos áttekintésére, koordinálására, azok időbeli ütemezésére s a felhasználási szakaszokhoz kapcsolódó ellenőrzésekre.

1.3.2 Ellenőrzés, értékelés, monitoring A célok és indikátorok előzőekben jelzett hierarchikus struktúrája szükségessé teszi az „ellenőrzés-értékelés-monitoring” fogalmi pontosítását is. A hétköznapi szóhasználatban ugyanis a monitoring, értékelés, ellenőrzés kifejezések gyakran összemosódnak és azonos, vagy nagyon hasonló jelentésben használják azokat. A

Bakony-Balaton

Mechatronikai

és

Járműipari

Klaszter

projektjeinek

végrehajtása során szükséges annak figyelemmel kísérése, a végrehajtás tapasztalatai alapján korrekciós lépések megtétele, hatásainak elemzése, amit összefoglaló

néven

kontrollingnak

nevezünk.

Ennek

három

elemét

kell

megkülönböztetni: 

Az ellenőrzés tárgya a kitűzött végeredmény teljesítése, azaz a program „végtermékének” megléte vagy nemléte. Az ellenőrzés lehet a folyamatba épített, vagy történhet utólagosan (az előbbi esetben akár a végrehajtás 27

felfüggesztését is eredményezheti). Jellemző, hogy az ellenőrzés kulcselemeik előre rögzítik, és minden esetben a végeredményből indulnak ki. 

A monitoring esetében a vizsgálat tárgya a teljesítés előrehaladása, azaz annak megállapítása, hogy egy folyamat hol tart a kitűzött elvárásokhoz képest. A végrehajtással párhuzamos, annak részét képezi, helyzetjelentések alapján

lehetőséget

ad

a

továbbhaladással

kapcsolatos

döntések

meghozatalára, a szükséges visszacsatolások elvégzésére. 

Az értékelés nincs közvetlen kapcsolatban a végrehajtással, ebből fakadóan nincsenek visszacsatolások. Célja, hogy megvizsgálja a specifikus és globális célok

teljesülését,

illetve

általánosítható,

máskor

is

hasznosítható

tapasztalatokat mondjon ki. Az előzőek alapján nyilvánvaló, hogy az ellenőrzés alapja az output indikátor, a monitoringé az eredményindikátor, az értékelés pedig a hatásindikátorok alapján történik, ahogy ezt az alábbi ábra is szemlélteti.

Input

Output

Eredmény

Hatás

Ellenőrzés Monitoring Értékelés

Az egyes elemek közötti összefüggések oldaláról vizsgálva a kérdést, a kontrollingnak az alábbi alapvető kérdésekkel kell foglalkoznia: 

Relevancia: A projekt céljai mennyire relevánsak a feltárt igények, prioritások szempontjából (a klasztertagság egésze vagy egyes tagjai számára)



Hatékonyság: A hatékonyság az input/output arányt jelenti, vagyis azt, hogy egységnyi eredmény milyen ráfordítást igényel, pl. mennyibe kerül egy munkahely létrehozása, illetve egy új termék egy darabjának legyártása.



Hatásosság: A hatékonyságot meg kell különböztetni a hatásosságtól. Utóbbi

28

azt mutatja meg, hogy a projekt milyen mértékben járul hozzá egy cél vagy alcél teljesüléséhez, ami a tényleges és a tervezett eredmény vagy hatás összevetésén alapul. 

Hasznosság: Egy projekt hasznossága azzal jellemezhető, hogy milyen hatással van a célcsoportra, az igényeik vonatkozásában.



Fenntarthatóság: Milyen további változások, hasznok várhatóak a projekt befejezése után.

A Klaszter gazdasági, szervezeti fejlesztési igényei

Hatás

Igények Eredmény Projekt Célok Relevancia

Projekt végrehajtás

Input

Kiértékelés Hatékonyság Hatásosság Hasznosság és fenntarthatóság

29

Output

1.4 A projektfejlesztés sajátosságai 1.4.1 A projektek komplex fejlődési rendszerbe illeszkedése Az előzőekben leírtak a gyakorlatilag az integrált és egyedi projektek végrehajtásának bármely szintjére alkalmazhatók. Könnyen belátható, hogy minden egyes egyedi projekt esetében is szükséges az output-, eredmény- és hatásindikátorok előzetes azonosítása, az előzetes és utólagos értékelés, a végrehajtás figyelemmel kísérése. Mindez különösen fontos akkor, amikor a projekt végrehajtásához külső finanszírozásra: pénz- és tőkepiaci eszközökre, pályázatok útján elérhető uniós-, állami vagy regionális támogatásokra van szükség. Ennek ellenére szükséges a klaszterszintű és a klasztertag-szintű fejlődés fogalmának elhatárolása, mert a tervezés, a megvalósítás, a menedzselés szempontjából is vannak köztük módszertani különbségek. Az elhatárolás azonban nem jelent függetlenséget; érvényesülnie kell a szintek egymásra épülésnek. A klaszter számára jelentőséggel bíró, a tagság által támogatott projekt ugyanis a klaszter egészének fejlődését kell, hogy szolgálja – legalábbis a közös fejlődéshez való, minimális hozzájárulás mértékéig. A három szint egymásra épülése az alábbiakban foglalható össze: 

„A fejlesztések alapvető egysége az egyedi klasztertagra vonatkozó, egyedi projekt, ami egymással fizikai vagy közvetlen logikai kapcsolatban lévő fejlesztési szakaszok eredményeképpen önmagában működőképes eszközt vagy szolgáltatást hoz létre. Egy projekt szakaszokra, részprojektekre oszlik, amelyek

végrehajtás

vagy

kivitelezés

tekintetében

önálló

egységet

jelenthetnek, de nem eredményeznek a fejlesztés célját szolgáló önmagában működőképes struktúrát. 

A stratégiai eszközök azonos cél (prioritás) érdekében történő alkalmazása a szervezetileg integrált projekt. A szervezetileg integrált projekt működtetője az azért felelős projekt-menedzsment szervezet, számszerűsíthető komplex indikátor (eredményindikátor) és előre szabott pénzügyi lebonyolítási és

30

ellenőrzési rend jellemzi. Egy szervezetileg integrált projekt az egyértelműen definiált céljával (indikátoraival), maximum kétéves időkeretével és eszközeivel (pénzügyi keretével) jellemezhető. 

Egy komplex fejlesztési program projektek együttese, többéves fejlesztési költségvetéssel; olyan projekteké, amelyeket a komplex program elfogadását követően végrehajthatóvá lehet tenni. Egy ilyen program akkor válik végrehajthatóvá, ha egyértelműen tartalmazza a menedzselő szervezet megjelölését, a pénzügyi lebonyolítás és ellenőrzés kereteit csakúgy, mint a célokat, indikátorokat és a programköltségvetést.”

Komplex fejlesztési program

Szervezetileg integrált projekt

Egyedi projekt

Ez az egymásra épülés a célok – és az azokat számszerűsítő indikátorok – kapcsolatában is megmutatkozik: általánosságban elmondható, hogy valamely szint általános célja egy magasabb szint konkrét céljához segít hozzá. Ebből adódóan ugyanazon információs rendszer elvileg alkalmas lehet minden egyes szint értékelésének, monitoringjának kiszolgálására. Az

adatszolgáltató

általában

esetben

maga

a

projektet

végrehajtó

szervezet/közösség, és maguk az adatok is csak az adott projekttel kapcsolatban értelmezhetőek. Emiatt a projekt-monitoring konkrét tartalmi elemeit nem lehet 31

minden projektre érvényes módon egy általános információs rendszer keretében megtervezni, helyette minden egyes projektre egyedileg kell az előkészítés és tervezés fázisában a projekt monitoringját is megtervezni. Ehhez megfelelő alapot szolgálhat a logframe (logikai keret) mátrix, ami projekttervezéshez és programtervezéshez egyaránt használható. A logframe táblázat az általános (hosszú távú) cél, a közvetlen cél (alcél) és a tevékenységek szintjén adja meg azokat az indikátorokat (output-, eredmény- és hatásindikátor), amelyek egyrészt célokat tűznek ki a program/projekt különböző szintjeire, másrészt referenciaként szolgálnak a monitoring számára. A módszer emellett arra is válaszol, hogy ki milyen gyakorisággal és milyen forrásból szerzi be (vagy állítja elő) ezen indikátorokat.

1.4.2 A projektcsatorna koncepció

A projektcsatorna-koncepció elsődleges célja a Bakony-Balaton Mechatronikai és Járműipari

Klaszter

projektgenerálási

tevékenységének

jogosultságát

alátámasztani. A projektcsatorna felállítása és működtetése kapcsán a következő alapvetések, kulcskifejezések említhetők: 

mechatronika- és autóipari orientációjú projektek a klaszter versenyképessége érdekében



szakpolitikák, tervek és projektek összhangja a regionális klaszter forrásabszorpciója tükrében



Hiteleszközök

és

befektetés-ösztönzés

az

EU-s

és

hazai

klasszikus

támogatások kiegészítéseként, 

Stratégiai Szövetségek - a klasztertagok együttműködő konzorciumai -, mint Projektgazdák, Végső Kedvezményezettek



vertikális és horizontális regionális kapcsolatrendszer és a klasztertagok piaci pozícióinak erősödése



a partnerség biztosítása és hatékony alkalmazása a rendszer hálózatszerű 32

működtetésekor, regionális információs centrummá válás. A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektgenerálási tevékenysége során tervezett szolgáltatások köre az alábbiakban foglalható össze: 

Innovációs

projektötletek

feltérképezése,

workshopok,

egyeztetések

előkészítése, moderálása 

A kiválasztott ötletek szelekciójában való közreműködés, ehhez kapcsolódó szakmai tanácsadás



Az ötletek ún. „Project Fiche” formátumú leképezése, mely a javaslatok nagyvonalú leírása, szakmai-tervezési tanácsadás



Komplex projektdokumentációk (részdokumentációk) összeállítása, ennek részeként a Project Fiche formátumhoz csatolható

háttértanulmányok

(gazdaságossági, környezeti hatástanulmányok, stb.) készítése 

Konkrét projektdokumentációk, befektetői ajánlatok, összeállítása, az ehhez szükséges szervezeti és folyamatszervezési teendők ellátása



Az elindított projektek végrehajtásában, elsősorban azok menedzselésében való közreműködés

A

Bakony-Balaton

Mechatronikai

és

Járműipari

Klaszter

projektcsatorna

rendszerének keretein belül fenti lépések támogatása elsősorban a projektötletek feltérképezésén

és

a

projektek

megítélését

megalapozó

Project

Fiche

formátumokon keresztül történik. Az egyes projektek fejlődési fokozatai a Project Fiche formátumig az alábbi lépésekkel jellemezhetők:

Projekt csatorna fázis 1. lépés: Összes projekt ötlet 2. lépés: A klaszter stratégiájának

-

SABLON, FORMADOKUMENTUM a projekt kitöltésére felszólító e-levél projektötlet adatlapok e-befogadása e-értesítés a projektötlet befogadásáról

-

e-értesítés a projekt klaszter stratégiához való megfelelőségéről Project Fiche adatlap e-befogadása e-értesítés a Project Fiche adatlap befogadásáról a klaszter-stratégiához nem illeszkedő projektek ötletgazdáinak

33

Projekt csatorna fázis megfelelő projektek

SABLON, FORMADOKUMENTUM

kiválasztása

3. lépés:

-

Támogatásvizsgálat: EU Alapokból, hazai

-

kormányzati programokból, hitelezők/befektetők által támogatható projektek kiválasztása

4. lépés: Támogatásjavaslat:

-

Konkrét pályázati rendszerből támogatható projektek kiválasztása

5. lépés: Életképességi, megvalósíthatósági vizsgálat

-

értesítése  a lehetséges korrekcióról, szükséges teendőkről,  az esetleges további vizsgálatokról,  az értékelési eljárás megszüntetéséről értesítés a Project Fiche adatlapon közöltek EU Alapok forrásaiból vagy kormányzati programokból történő támogathatóságról EU vagy kormányzati programokból nem támogatható projektek gazdáinak értesítése  a lehetséges Project Fiche adatlap korrekcióról, szükséges teendőkről,  az esetleges további vizsgálatokról,  üzleti ajánlatként történő kezelésről (hitel- vagy befektetési ajánlat)  más finanszírozási ajánlatról  az értékelési eljárás megszüntetéséről értesítés konkrét pályázati rendszeren át való támogathatóságról konkrét pályázat révén nem támogatható projektek gazdáinak értesítése  a lehetséges korrekcióról, szükséges teendőkről,  az esetleges további vizsgálatokról,  üzleti ajánlatként történő kezelésről (konkrét hitel- vagy befektetési ajánlat)  más finanszírozási ajánlatról  az értékelési eljárás megszüntetéséről a Project Fiche adatlap további kiegészítésére, korrekciójára felszólító levél értesítés a Project Fiche adatlap kitöltésének, benyújtásának megfelelőségéről, projektgazdák értesítése  a projekt életképességi vizsgálatának eredményéről,  a lehetséges korrekcióról, szükséges teendőkről.

1.4.3 A projektek értékelése A projektek előbb említett egyedisége és sokfélesége miatt a Bakony-Balaton Mechatronikai és Járműipari Klaszter komplex projektcsatorna rendszerével szembeni alapelvárás, azonban információs rendszerének nem lehet feladata, hogy minden egyes projekt részletes értékelését is automatikusan kiszolgálja. Így egy olyan általánosítható projekt-értékelési eljárásból célszerű kiindulni, amely során csak a projekt legfontosabb paraméterei kerülnek be a Bakony-Balaton Mechatronikai és Járműipari Klaszter nyilvános projektcsatorna adatbázisába, a projekt részletes információhalmaza megmarad a projektet menedzselő szervezet 34

hatáskörében. Mindezeket figyelembe véve a projektekkel kapcsolatban bizonyos ellenőrzési és az alábbi jellegzetes értékelési feladatok jelentkeznek: 

A projekt előzetes értékelése azt vizsgálja, hogy a projekt érdemes-e kivitelezésre, megéri-e megvalósítani, biztosított-e annak hosszú távú fenntarthatósága stb.. Az értékelés leggyakrabban alkalmazott szempontjai: − Az egyik legalapvetőbb feltétel, hogy a projekt célrendszere illeszkedjen a tágabb program, a klaszterszintű stratégia célrendszeréhez. − A gazdasági értékelés során elsősorban rentabilitási kérdéseket, a ráfordítások és az eredmények viszonyát vizsgálják (költség/haszon elemzés, költséghatékonyság, megtérülés stb.). − A pénzügyi (financiális) értékelés a költségterv megalapozottságának vizsgálatát jelenti: reálisak-e a projekt-tervben feltüntetett költségek, rendelkezésére áll-e a kellő időben a szükséges pénzalap, az ténylegesen fedezi-e a kivitelezési költségeket stb. − A technikai (szakmai) értékelés során a projekttel megoldani kívánt probléma elvi aspektusait vizsgálják: a megoldandó probléma természete és kiterjedése, a lehetséges megoldási alternatívák és a megoldásként kiválasztott alternatíva megfelelősége, a célok és az alkalmazni kívánt módszerek összhangja, a tervezés módszerének és a kiválasztott megvalósítási technikák helyessége, a projektterv (pl. ütemezés) realitása stb. − A szervezeti kérdések a megvalósító szervezet (és a közreműködő szakemberek)

tapasztalatait,

referenciáit,

felkészültségét

foglalják

magukban, beleértve azokat a szervezeti, intézményi kereteket is, amelyek a projekt befejezése után annak működtetését biztosítják. − Esetenként értékelési szempont lehet a projekt eredményeinek és tapasztalatainak szélesebb körű hasznosítása, disszeminációja, illetve ezek biztosítása. − Az értékelés során számos esetben külön figyelmet fordítanak arra, hogy a projekttulajdonos (klaszter egésze, klasztertagok konzorciuma vagy egyedi 35

klasztertag)

megfelelően

megtervezte-e

a

projekt

előrehaladásának

ellenőrzését, azaz a projekt értékelését, ellenőrzését, monitoringját. 

A projekt-megvalósítás közben

is sor kerülhet

értékelésekre.

Ezeket

rendszerint beszámolók (Progress Report) a projekt megvalósítója végezheti. 

Ha a megvalósítás során a monitoring lényeges eltérést jelez a tervekhez képest, rendkívüli értékelésre kerül sor. Ennek eredménye lehet a projekt módosítása, szüneteltetése, de akár az idő előtti leállítása is.



A projekt lezárásának fontos elme a projekt záró értékelése, ami a tervezett eredmények megvalósulására irányul. A projekt sikerét azonban nem csupán az minősíti, hogy annak „végtermékét” a megrendelő (támogató, befektető, hitelező) elfogadta-e, vagy sem. Fontos az időtartam, a költségek, a specifikációnak

való

megfelelés,

továbbá

az

alkalmazott

módszerek,

technikák, a szervezeti és együttműködési kérdések átfogó értékelése, és minden olyan lényeges szempont elemzése, amelyet a projekt definíciós szakaszában előre meghatároztak. 

Az értékelés speciális esetének tekinthető hatásvizsgálat azokat a várható változásokat (mellékhatásokat) méri fel, amelyek nem közvetlenül a projekt fő célkitűzéseiből fakadnak. Elsősorban a nem tervezett környezeti hatások felméréséről van szó, de ezen kívül vonatkozhat a társadalmi-gazdasági környezet egyéb aspektusaira is.

36

Projekt-értékelő Lap Projekt azonosító:

Projektgazda:

Projekt címe:

Értékelő:

Téma I. A

Kategória (A-C) projekt

stratégiai

fontossága

a

klaszterstratégia tükrében II. A projekt területi hatása

Téma I. A projekt célja II. A projekt szakmai megalapozottsága III: A projekt megvalósíthatósága IV. Pénzügyi értékelés Összesen

Pontszámok

A PROJEKTJAVASLAT ÉRTÉKELÉSI SZEMPONTJAI I. A projekt szakpolitikai illeszkedése

Max. pontszám 5 pont

Indoklás:

37

Elért pontszám

A PROJEKTJAVASLAT ÉRTÉKELÉSI SZEMPONTJAI

Max. pontszám

I. összesen

Max: 5 pont

II. A projekt szakmai megalapozottsága -

a projekt hozzájárulása a klaszter általános fejlődéséhez

-

a projekt közvetlenül hozzájárul a klaszter vállalkozásai versenyképességének növeléséhez

0-10

-

a projekt technológia, szakmai színvonala

0-10

-

a projekt kiterjesztett hozzáadott értéke, várható társadalmi gazdasági, foglalkoztatottsági hozadéka

0-5

-

a projekt előkészítettsége

0-10

0-10

Indoklás:

II. összesen III. A projekt megvalósíthatósága

Max: 45 pont

-

a felvázolt szakmai, szervezeti háttér megfelelő-e a projekt végrehajtására

-

a projekt megvalósításának programja/ütemterve reális-e

-

a projekt fenntarthatósága

0-10

0-10 0-10

Indoklás:

38

Elért pontszám

A PROJEKTJAVASLAT ÉRTÉKELÉSI SZEMPONTJAI

Max. pontszám

III. összesen: IV. Pénzügyi értékelés

Max: 30 pont

-

a projekt-költségvetés költséghatékonyság

-

a projekt externáliái

-

pénzügyi / gazdasági megtérülés-vizsgálat

gazdasági-

realitása,

pénzügyi

megalapozottsága,

hozadékai,

kiterjesztett

Elért pontszám

0-10

0-10 0-20

Indoklás:

IV. összesen:

40 pont

Összesített pontszám:

120 pont

1.4.4 A projekt-monitoring Bár fentebb bemutatott, hogy az egyedi projektek részletes monitorozására – a végrehajtás nyomon követésére – nem a Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének információs háttere hivatott, mégis érdemesnek tartjuk e problémakör néhány sajátosságát kiemelni. Mindenekelőtt azért, mert olyan általánosítható elvekről és módszerekről van szó, amelyek nemcsak a fejlesztési programokhoz kapcsolódva, hanem minden projektjellegű3 tevékenység esetén hasznosítható. 3

Ebből a megközelítésből projektnek tekinthető minden nem rutinszerű tevékenység. A projektek

általánosítható jellemzői: egyedi, tervezett, meghatározott cél elérésére irányul, sokféle résztevékenységet foglal magában, véges időtartamú, korlátozott erőforrások (pénz, technika, ember) állnak rendelkezésre a megvalósításhoz.

39

Amikor egy projekt előrehaladásáról akarunk képet kapni, akkor néhány alapkérdésre kell választ keresni: 

Hol tartunk? A projekt aktuális állapotának megállapítása.



Hol kellene járnunk? Az aktuális állapot összevetése a tervvel.



Hogy jutunk oda? A lehetséges korrekciós lépések mérlegelése, amelyek segítenek a projektet újból „sínre tenni” (ha szükséges) vagy rajta tartani.



Jó irányba haladunk-e? A korrekciós lépések projektre gyakorolt hatásának elemzése.

Az esetleg szükségessé váló korrekciók nemcsak a végrehajtás, hanem adott esetben a tervek kiigazítását is igényelhetik. Különösen igaz ez a hosszú távú projekteknél, mely azt jelenti, hogy az irányítás nem egy lineáris, hanem sokkal inkább ciklikus folyamat. A ciklus a tervkészítéssel és annak jóváhagyásával kezdődik, amit a megvalósítás követ. A megvalósítás során elért eredményeket folyamatosan figyelemmel kísérve és a tervekkel összevetve kiértékelik az előrehaladást (határidők, költségek, minőség); ha szükséges, a terveket módosítják stb.. Ezt az ún. projektirányítási ciklust szemlélteti az alábbi ábra:

40

Ahogy az ábrán is látható, a projekt ellenőrzésével, nyomon követésével kapcsolatos feladatok két fő csomópont köré csoportosíthatók: 

Mindenekelőtt információkat kell gyűjteni a tervezett és a tényleges előrehaladásról, a költségekről, a minőségről, az emberi erőforrásokról, készletekről, anyagokról stb. Ez a passzív, csupán megfigyelő jellegű adatgyűjtési fázis a szűkebb értelemben vett monitoring.



Az információk, adatok lehetővé teszik, vagyis a terv összevetését a tényleges előrehaladással. Míg az előző lépésben a tények összegyűjtése és rendszerezése dominál, addig itt már azok elemzésére, kiértékelésére is sor kerül. Ennek alapján tárhatók fel a tervektől való eltérések, az esetleges problémák. Ha korrekcióra van szükség, azt meg kell tervezni, és elemezni kell annak várható hatását is.

A monitorozáson belül a projektgazdák számára a pénzügyi-financiális monitoring, az alapvető folyamatok és outputok egyaránt fontosak. A projekt kézben tartásának alapja, hogy szisztematikusan információkat gyűjtsünk három alapvető paraméterére vonatkozóan: 

Az időtartam, azaz a projekt ütemterve a résztevékenységek előrehaladásának folyamatos figyelemmel kísérésével ellenőrizhető. Ehhez többféle technika használható: a személyes tájékozódástól, konzultációktól kezdve a rendszeres munkaértekezleteken keresztül a külső szakemberek megbízásával elvégzett auditálásig.

Az

ellenőrzés

alapját

a

teljesítésről

készített

rendszeres

felmérések képezik. Ezek arra adnak választ, hogy a projekt egy-egy résztevékenysége milyen mértékben haladt előre (pl. hány mérnökórát töltöttek a tervezéssel stb.). A monitoringnak kiemelt figyelmet kell fordítania a következőkre: − A kritikus tevékenységekre, hiszen ezek bármilyen csúszása a projekt egészének határidejét veszélyezteti. − A hosszú átfutási idejű tevékenységekre, amelyek esetleg lerövidíthetők a teljesítmény fokozásával, amivel időt lehet nyerni. 41

− Az átlagnál több és költségesebb erőforrást igénylő tevékenységekre. 

A költségek a végrehajtás során felmerült kiadások összesítésével közvetlenül számon tarthatók. A költségekre (és a bevételekre) vonatkozó információk forrása alapvetően a szervezet pénzügyi, számviteli rendszere lehet, bár ennek szerkezete és logikája sok esetben nem áll összhangban a projekttervvel, és gyakran az információk átfutási ideje is hosszadalmas. Ezért célszerű

a

monitoring-rendszer

keretében

a

pénzügyi

információkra

vonatkozóan külön adatszolgáltatási rendszert felállítani. A cél a tervezett és a tényleges költségek (és bevételek) nyomon követése és összehasonlítása, amihez elegendő egyszerűen regisztrálni az egyes tevékenységek során felvetődött pénzmozgásokat. Ezek az adatok az esetek legnagyobb részében a megbízási és vállalkozói szerződések, illetve a kiállított számlák alapján könnyen elvégezhető. A költségek nagyrészt az erőforrások (emberek, technika, gép) felhasználásához kötődnek, a költségellenőrzés ezért szorosan kapcsolódik az erőforrás-monitoringhoz. Az erőforrás-monitoring emellett a túlterhelések elkerülése és az egyenletes kihasználtság érdekében is fontos. Forrása a létszámjelentések, a gépidő kihasználtságra vonatkozó jelentések lehetnek. 

A projekt harmadik alapvető paramétere a minőség. Az ellenőrzésnek tehát arra is ki kell térni, hogy a tevékenységek színvonala és a végtermék minősége megfelel-e az elvárásoknak. A minőség nem valami szubjektíven értelmezett, és ezért ellenőrizhetetlen jellemzője a projektnek. Ha ugyanis pontosan és szabatosan megfogalmazott kritériumokat írunk elő az output minden lényeges tulajdonságára, akkor a minőség ellenőrzése egyet jelent e kritériumok teljesülésének ellenőrzésével. A monitoring-rendszernek tehát arról kell információkat szolgáltatni, hogy a termék megfelel-e az előírt paramétereknek, specifikációknak.

Az értékelés – vagyis a projekt-tervek és a tényleges előrehaladás összevetése – során a projektmenedzsernek gyakran kell azzal szembenéznie, hogy a tervhez képes eltérések jelentkeznek. Ez természetes is, különösen a hosszú időtávú projektek esetében (sokszor már a tervezés során is csupán valószínűségi 42

becsléseket használnak, pl. az időbeli ütemezésre, vagy a költségekre). A tervtől való eltérés tehát nem feltétlenül a hibás végrehajtás vagy a rossz tervezés következménye. Eredményezheti egy új technológia vagy termék megjelenése, egy új befektető megjelenése a térségben, a szabályzók változása stb. Ha nem túl számottevő a tervtől való lemaradás (vagy éppen a túlteljesítés), akkor az a jól megtervezett és kézben tartott projektek esetében egyfajta önkorrekciós folyamatot indukál. Ha azonban az eltérés vagy probléma tartósnak bizonyul, beavatkozásra van szükség (pl. a költségek, a munkaidő, a határidő átütemezése, pótlólagos erőforrások bevonása stb.). Mindezek fontos következménye, hogy a projektek monitoring-rendszerének megtervezésekor nem elegendő az alkalmazni kívánt indikátorok rendszerének meghatározása; a monitorozás lényeges része a jelzőrendszer érzékenysége is, vagyis annak meghatározása, hogy milyen mértékű eltérés esetén riasszon. Meg kell jegyezni, hogy nem tartjuk célszerűnek a fenti feladatokat részleteiben ellátó információs rendszer létrehozását sem a Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének informatikai keretében, sem attól elkülönülten. Egyfelől több olyan szoftver létezik és kapható kereskedelmi forgalomban, amelyet kifejezetten projektek menedzselésére fejlesztettek ki, s amely a tervezés (ütemezés, erőforrások, részletes költségek stb.) mellett támogatja a projektek nyomon követését, a kapcsolódó kommunikációs feladatokat (pl. különböző jelentések generálása), s lehetőséget nyújt a csoportmunka szervezésére is. Ilyen igények esetén tehát e szoftverek valamelyikének alkalmazását javasoljuk az egyedi projektek esetében. Másfelől a támogatással megvalósuló projektek a támogató által meghatározott nyomkövető rendszer alkalmazását írják elő – ezek használata ki- és megkerülhetetlen, más rendszer alkalmazása pedig párhuzamosságot, felesleges duplikációt okozna.

43

2 A PROJEKTNYILVÁNTARTÁS ÉS KÖVETÉS

44

A projektek megvalósulása több osztatú finanszírozási konstrukcióban lehetséges: 

EU-s és hazai tervdokumentumokhoz illeszkedő pályázati rendszerek keretein belül, a 2007-13, majd 2014-20 közötti tervezési, programozási időszakra



Hitelezési és befektetői lehetőségek bevonásával, melyhez eredményes befektetés-ösztönzés tevékenység társul.

A projektek feltérképezéséhez és fejlesztéséhez ún. Projektcsatorna rendszer (szakmai terminológiával: Project Pipeline System) társul, melynek főbb elemei a következők: 

A Bakony-Balaton Mechatronikai és Járműipari Klaszter stratégiájához, adottságaihoz illeszkedő, támogatható, befektetéseket vonzó projektötletek feltérképezése



A kiválasztott ötletek szelekciójában való közreműködés, ehhez kapcsolódó szakmai tanácsadás



Az ötletek ún. „Project Fiche” formátumú leképezése, mely a javaslatok nagyvonalú leírása, szakmai-tervezési tanácsadás



Komplex projektdokumentációk (részdokumentációk) összeállítása, ennek részeként a Project Fiche formátumhoz csatolható

háttértanulmányok

(gazdaságossági, környezeti hatástanulmányok, stb.) készítése 

Konkrét

pályázati

összeállítása,

dokumentációk,

benyújtása,

az

befektetői ehhez

ajánlatok,

szükséges

hitelkérelmek

szervezeti

és

folyamatszervezési teendők ellátása 

Támogatott,

befektetői

végrehajtásában,

hozzájárulással,

elsősorban

azok

hitellel

megvalósuló

menedzselésében

való

projektek szakértői

tanácsadás, közreműködés

Az alábbiakban az egyes szolgáltatásokhoz kötődő folyamat kerül bemutatásra: 1.

A

Megrendelő

elvárásaihoz

illeszkedő,

támogatható

projektötletek

feltérképezése a)

A projektgyűjtő kérdőív, tájékoztató és a kitöltési útmutató összeállítása. 45

Javasolt formátum csatoltan. b)

Célzott lista összeállítása a lekérdezendő szervezetekről

c)

A kérdőívek és tájékoztatók eljuttatása lekérdezendő szervezetekhez

d)

A kérdőívek kitöltése

e)

A kérdőívek érkeztetése, regisztráció

f)

Összefoglaló jelentés a kérdőívek tapasztalatairól

2.

A kiválasztott ötletek szelekciójában való közreműködés, ehhez kapcsolódó

szakmai tanácsadás a)

A projekteket minősítő rendszer összeállítása.

b)

Minősítő bizottság felállítása és esetleges képzése

c)

Értékelő ülések a projekt-ötletek minősítéséről

d)

Jelentés a minősítés tapasztalatairól

3.

Az ötletek ún. „Project Fiche” formátumú leképezése, mely a javaslatok

nagyvonalú leírása, szakmai-tervezési tanácsadás a)

A projekteket leíró „Project Fiche” formátum összeállítása. Javasolt formátum csatoltan.

b)

A

projekt-ötleteket

leíró,

„Project

Fiche”

formátumú

dokumentáció

elkészítése c)

Jelentés a leképezés tapasztalatairól

4.

Komplex projektdokumentációk (részdokumentációk) összeállítása, ennek

részeként

a

Project

Fiche

formátumhoz

csatolható

háttértanulmányok

(gazdaságossági, környezeti hatástanulmányok, stb.) készítése a)

A projektek minősítése, előkészítettségük feltérképezése.

b)

A hiányzó részanyagok elkészítése, a komplex projekt-dokumentáció

összeállítása c)

Jelentés a projektdokumentációk állapotáról

5.

Konkrét pályázati dokumentációk, finanszírozási-üzleti tervek összeállítása,

benyújtása, az ehhez szükséges szervezeti és folyamatszervezési teendők

46

ellátása. a)

A komplex projekt-javaslatok minősítése, előkészítettségük, illeszkedésük

feltérképezése. b)

A

hiányzó

részanyagok

elkészítése,

a

pályázat/ajánlat/kérelem

készítésének megszervezése, a komplex pályázati dokumentáció vagy üzleti ajánlat összeállítása c)

Jelentés a javaslat összeállításának és benyújtásának tapasztalatairól

6.

Finanszírozott és támogatott projektek végrehajtásában, elsősorban azok

menedzselésében való közreműködés, kapcsolattartás a befektetőkkel, esetleges társbefektetések illetve együttes finanszírozás végrehajtása. . a)

A közreműködés minőségének és teendőinek tisztázása

b)

A vállalt feladatok végrehajtása a projekt sikeressége érdekében

c)

Jelentés a projekt végrehajtásának tapasztalatairól

47

3 JAVASLAT A MEGVALÓSÍTÁSRA

48

3.1 A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének alapkövetelményei Alapvetésként el kell mondani, hogy a projektek belső információit tartalmazó és külső környezet információit szolgáltató, különböző adatgazdák kapcsolódási felületei nem kellően kimunkáltak, az inhomogén, különböző szoftver és hardver platformokon futó, megjelenésében és korszerűségében egyaránt különböző alkalmazások

és

adatok

sokasága

nagymértékben

nehezítheti

az

információáramlást. Az egyes, individuumként értelmezhető rendszerek mindenkori fejlesztése, korszerűsítése tovább nehezíti az integrációt, felületek változhatnak meg, mely, adatkonverziós problémákat vethet fel, a fogadófelület fejlesztését, telepítését hozhatja magával. Ebből adódóan a projektcsatorna rendszer működtetését egy informatikai

támogatással

megvalósuló,

a

projektinformációkat

tekintve

dinamikusan változó, a környezet információit tekintve statikus állapotok egymásutániságát feltételező keretben javasoljuk megvalósítani. Már a bevezető fejezetben is kifejtettük, hogy a fenti problémákra megoldásként kínálkozik

a

klaszter

web-siteján

kialakítandó,

integrált

információs

projektcsatorna szegmens. Az integrált projektcsatorna szegmens a klaszterközösség életében potenciális értéket képviselhet. Elsősorban elősegíti a döntéshozatal figyelemfelkeltő,

folyamatait, projektalapú

a

klaszter-közösség

információk

gyors,

szereplőinek

hatékony

szánt,

közzétételének

eszköze, elengedhetetlen feltétele a sikeres kapcsolatépítésnek, a bizalom megszerzésének, és megtartásának. A jól szervezett informatikai háttér legnagyobb erénye tán abban rejlik, hogy különböző felhasználói csoportok számára testre szabott információt képes szolgáltatni úgy, hogy a teljes információs rendszer transzparens módon érhető el egy egységes platformon – praktikusan böngészőn – keresztül, ahelyett hogy különböző alkalmazások kezelőfelületeinek telepítése, megtanulása és használata szükséges lenne.

49

3.1.1 A

Bakony-Balaton

Mechatronikai

és

Járműipari

Klaszter

projektcsatorna rendszerének informatikai fogalmi alapvetései A konkrét megvalósítási javaslaton egy olyan Internet alapú szolgáltatást értünk, amely hatékony, célorientált adatmenedzselést és keresést tesz lehetővé, testre szabott információkat tartalmaz projektek előkészítésében és megvalósításában érdekelt klasztertagoknak. A jól felépített projektcsatorna rendszer informatikai támogatása olyan, informatikai eszközökkel megvalósult termék, mely interaktív módon integrálja a klaszter-környezet projektalapú érdekeltségeit, továbbá kiterjeszti, illetve megjeleníti azt a Weben keresztül. Az alkalmazás megvalósításához szükséges komponensek és kritériumok: 

Könnyen kezelhető, megbízható adatbázis-kezelő háttér



Skálázhatóság, azaz a növekvő igénybevételhez igazodni képes hardver, szoftver konfiguráció



Nagyfokú

rendelkezésre

állás,

azaz

folyamatos

működést

biztosító

konfiguráció 

Tartalomkezelés, azaz az információs rendszer által felügyelt tartalom strukturálása, kategorizálása



Hatékony keresési lehetőség a kiajánlott tartalomban, alkalmazás-szerver felépítés



Biztonság, azaz az elérhető tartalom és szolgáltatás jogosultságkezelése és védelme

Az alkalmazás fejlesztésének kulcselemei: 

az alapadatok egyedi tulajdonságainak és egymáshoz való viszonyának elméleti meghatározása, minőségi jellemzése, rendszerezése



fentiekre támaszkodva, a háttér adatbázis adataiból dolgozó, Web-alapú, kereső alkalmazás készítése

50

3.1.2 A rendszer főbb integrációs elemei Az alkalmazással szembeni legfontosabb elvárás, hogy lehetőséget teremtsen a heterogén információs környezet integrálására az ún. integrációs adapterei segítségével. A komplex integrációs eszköz legfontosabb eleme az adatintegráció.

3.1.2.1 Az adatintegráció Korszerű megoldásként egy adatintegrációs modul segítségével bármilyen szabványos

relációs

adatbázis

alkalmas

a

projektadatok

tárolására

és

előhívására. Mivel a projektcsatorna rendszer esetében egy adat csak egyetlen helyen tárolódik, de több felhasználó számára is elérhetővé kell tenni, a portálfelület révén transzparensé tehető az eredeti adat, azaz olvasható – és jogosultság esetén módosítható – az eredeti helyén. Az adatok bármilyen fizikai elhelyezkedésű adatgazda által előállhatnak úgy, hogy minden adat csak egyetlen fizikai adatbázisban tárolódik és köztük relációk definiálhatók. A rendelkezésre álló erőforrások szűkösségéből adódóan minden adatot egy fizikai terület, a klaszter-menedzsment által bérelt diszkterülete alá importálunk, mely a költségek kímélésének feltehetően legkézenfekvőbb útja. A projektadatbázis esetében – biztonsági, terhelhetőségi szempontok miatt – mindenképpen szükség van az adatok többszörözésére. Mivel a költségkímélő esetben az információk több, különböző platformon – elsődleges adatgazdánál és portálgazdánál – is előfordulnak, adatreplikációról beszélhetünk. Az adatok egy részének létezik egy elsődleges keletkezési és módosulási helye, ugyanakkor a Bakony-Balaton Mechatronikai és Járműipari Klaszter portáljának diszkterületén is tárolódhat. A primer adat a megfelelő logikai (megállapodások, személyi és időzítési feltételek) és fizikai (keretrendszer, hardware feltételek) feltételek mellett, adatrögzítéssel vagy másolással kerül a központi területre, az adatrögzítés folyamata on-line történik, az átmásolás pedig off-line üzemmódú. 

A projektgazdák által birtokolt elsődleges adat módosulásának rögzítése után on-line módon, gyakorlatilag azonnal megtörténik a központi rögzítés.

51



Off-line adatbevitel során a fogadó adatbázis egyes projektadatainak aktualizálása

mobil

számítógépeken,

internetes

letöltésen,

CD-n,

stb.

keresztüli transzferrel valósítható meg.

3.1.2.2 Partnerség A komplex projektcsatorna háttér kapcsán együttműködő főbb adatszolgáltatók, partnerek, a teljesség igénye nélkül a következők lehetnek: 

Teljes körű klasztertagok



Támogató tagok



Partner klaszter-szervezetek



Pályázatkezelő szervezetek



Befektetők



Hitel nyújtására alkalmas szervezetek

52

A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének klasszikus blokksémája:

Projekt-ötlet - 1

Támogatási háttérinformációk

Projekt-ötlet - 2

PROJEKTCSATORNAPORTÁLSZEGMENS

Project-Fiche - 2

Projekt-ötlet - n

Befektetői- és hitelinformációk

Project-Fiche - n

Konzorcium

Konzorcium

Konzorcium

Project-Fiche - 1

Konzorcium

Konzorcium

Konzorcium

Klaszterközösségi szint

Projektek szintje

Projektkonzorcoiumok

Klasztertagok Egyedi szervezetek

A jelenlegi helyzethez kapcsolódó szükséges és elégséges feltételezés az együttműködők rendelkezésre állása, érdekeltsége. Fontos követelmény a rendszer működtetésében az egyes klasztertagok érdekeltsége, működési és üzleti

érdekeinek,

valamint

a

megvalósítandó

rendszerek

napi

használhatóságának összhangja, mely az érintett felek pontos és rendszeres tájékoztatásával, az együttműködési formák átlátható kidolgozásával tartható fenn.

53

3.1.3 Tartalomkezelés A tranzakciók és kapcsolatok egyesítése a tartalom, melyet tudni kell 

kezelni,



testre szabni,



a felhasználók számára könnyen hozzáférhetővé tenni.

A kategorizálás az előállított tartalomban segít eligazodni. A heterogén információs

környezet

integrálására

alkalmas

alkalmazás

automatikus

kategorizálást tesz lehetővé minden, általa felügyelt tartalomban. A hozzáférhető információk testre szabása tekintetében a jellemző módszerek és eljárások: 

Szerepkör-alapú, amikor is a felhasználó előre definiált, konkrét szerepkörrel rendelkezik. Ebben az esetben az alkalmazás üzemeltetője, - praktikusan a klasztermenedzsment szervezet - határozza meg azt, hogy mely tartalomhoz, mikor és milyen módon fér hozzá a felhasználó.



Felhasználó által konfigurált, mely esetben a felhasználó alakítja ki az önmaga számára megfelelő hozzáféréseket, természetesen a szerepkör alapján behatárolt kereteken belül.

A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszere lehetőséget kell, hogy adjon a konkrét felhasználói réteget közvetlenül érintő tartalmak

publikálására.

A

felhasználói

„célállomás”

lehet

a

klasztertag

környezetében elért fix számítógép vagy mobil eszköz (telefon, notebook) stb. A tartalomban való eligazodás alapja a hatékony keresőmotor, amely képes kell, hogy legyen a strukturált adatok indexelésére, a tartalmak keresésére. A kezelendő tartalom jellegét tekintve a Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének

esetében markánsan két

terület jelenik meg: 

Projektfejlesztés – projektötletek és Project Fiche-ek adatainak komplex

54

kezelése 

Rendszerértékelés

A kapcsolódó alkalmazói kör három csoportba osztható: 

Bakony-Balaton

Mechatronikai

és

Járműipari

Klaszter

szervezete; 

Klasztertagok;



Egyéb felhasználók:

A testre-szabás szerinti hozzáférésben megkülönböztethetők 

Megállapodáson alapuló kötelező alkalmazások



Javasolt alkalmazások



Szabadon választott alkalmazások

Az ellenszolgáltatás módja szerint a hozzáférés lehet 

Térítésmentes szolgáltatás



Kölcsönösségi alapon történő szolgáltatás



Térítéses szolgáltatás

Megoldási javaslat:

55

menedzsment

Adat-szolgáltatói oldal

Adat-igénylői oldal

Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszere WEB SZERVER

KLIENS

Alkalmazások

− Klasztertagok − Befektetők, hitelintézetek − Támogatáske zelők

− − − −

Adatbázisok Adatbázisok Adatbázisok

Klasztertagok Válalkozások Partnerek stb.

3.1.4 Biztonság A

Bakony-Balaton

rendszerének

Mechatronikai

és

Járműipari

Klaszter

projektcsatorna

kialakításakor rendkívül fontos szempont a biztonság. Az

alkalmazáson keresztül a klaszter projektalapú információs háttere elérhető – számos, adattartalom kinyerésen, változtatáson alapuló, visszaélés-vonzatú fenyegetéssel egyetemben -, így szükséges, hogy csakis a portálhoz illeszkedő, racionálisan

hierarchizált

felhasználói

struktúra

szereplői

nyerhessenek

hozzáférést, csakis jogosultságuknak megfelelő tartalmakhoz. A biztonság-érzékenységet meghatározó, jellemző kockázati elemek az alábbiak: 

Illetéktelen hozzáférés tartalmakhoz − Kommunikációs alapú – a hálózaton keresztül, védelmek megkerülésével transzferált információk − Hozzáférés alapú – védelmeken keresztüli, jogosultnak tűnő, ám valójában jogosulatlan

bejelentkezés,

illetéktelen

transzferált információk 56

azonosító-használat

révén



Illetéktelen hozzáférésen alapuló tartalomvesztés − Kommunikációs alapú – a hálózaton keresztül, védelmek megkerülésével eltávolított információk − Hozzáférés alapú – védelmeken keresztüli, jogosultnak tűnő, ám valójában jogosulatlan

bejelentkezés,

illetéktelen

azonosító-használat

révén

eltávolított információk Ebből fakadóan a portál-adminisztráció kritikus kérdései 

az illetéktelen névhasználat elleni védekezés, azaz az autentikálás és autorizáció metódusai



és a túlbiztosítás problémaköre, azaz a létező jogosultságok konzekvens kezelése.

A

tartalom

jogosulatlan

módosításának

és

elvesztésének

lehetséges

kezdeményezői a „külső” behatolók, és a „belső” szereplők, azaz az alkalmazások fejlesztői és a legitim felhasználók. A

felhasználók

autentikálása,

azaz

a

bejelentkező

felhasználó

diszkrét

azonosítása a portál részét képező „Security Manager” modul feladata, mely korszerű rendszerek esetében nem csupán a portál egészére, hanem a portál alatt lévő alrendszerekre is érvényes azonosítást kell, hogy jelentsen. A felhasználó autorizáció folyamán a felügyeleti rendszer a bejelentkezés után eldönti, hogy a felhasználó – alapvetően a szerepkörből fakadó – tartalomhozzáférési jogait. A tartalom-hozzáférés szabályozása nemcsak a biztonsági szempontból érdemi hozzáféréseket szabályozza, hanem alkalmasnak kell lennie a tartalom kereshetőségének szabályozására is.

3.1.5 Elérhetőség, rendelkezésre állás Az elérhetőség biztosítása két tényezőt foglal magában. Egyrészt jelenti az alkalmazás

állandó

működőképességét

57

(nagyfokú

rendelkezésre

állását),

másrészt elfogadható válaszidőket (skálázhatóságot). 

Az alkalmazás elérhetősége függ a beintegrált alrendszerek, alkalmazások és adatforrások elérhetőségétől, figyelembe véve a „legszűkebb keresztmetszet” elvét. Ugyanakkor nyilvánvaló, hogy sikeressége és hatékonysága a felhasználók elégedettségével arányos, hiszen a gyenge elérhetőségi, rendelkezésre

állási

jellemzők

megkérdőjelezhetik

az

értelmét

és

létjogosultságát. A probléma megoldásának kulcseleme, hogy a valamely komponensének – a hardverelemek váratlan meghibásodásából, vagy az eleve betervezett időszakos karbantartási, konfigurálási feladatokból adódó – kiesése esetén egy másik hasonló egység átvegye és kezelje a folyamatokat úgy, hogy az a felhasználó számára nem vagy kevéssé zavaróan módon menjen végbe. 

Az alkalmazás célorientált, hatékony tartalomszolgáltatása következtében növekvő érdeklődés hatására előfordulhat, hogy valamennyi komponens működik, elérhető, azonban a terheltségből fakadó válaszidő-növekedés a felhasználók számára elfogadhatatlanná válik. A probléma megoldása a skálázhatóság, azaz a leterheltség-függő erőforrások allokáció, mely révén szükség szerint újabb kisegítő hardver-elemek élednek fel, integrálódnak a rendszerbe, miközben a szoft-elemek változatlanok.

A fenti két tényezőből fakadó problémák együttes megoldása a tartalmakkal, feladatokkal felruházott, készenléti hardver-eszközökből álló ún. szerver-farm, mely a skálázhatóság és a folyamatos elérhetőség biztosítását egyaránt támogatja, hiszen egy kieső vagy túlterhelt eszköz szerepét ekvivalens elemek automatikusan kisegítik, átveszik. Az elérhetőség további tényezője a nyíltság, azaz a szabványos eszközök, protokollok alkalmazhatóságának elve. A nyíltság mellett figyelmet kell szentelni a portál globalizáltságának, bi- és multilaterális funkcióinak, azaz a lehetséges alkalmazói réteg lokális attribútumainak beállíthatóságára és kezelésére (pl. nyelv, szám- és dátumforma stb.).

58

3.1.6 Fejlesztő és integrációs eszközök, platformok AZ alkalmazás kialakításához napjainkban számos hatékony és megbízható fejlesztő és integrációs eszköz használható. Az eszközök palettájára jellemző, hogy alapvető kategóriákban többféle gyártóhoz köthető, hasonló funkciójú, tudásban és árban különböző termékek jöhetnek számításba. Az alapvető kategóriák az alábbiakban foglalhatóak össze: 

adatbázisok, adattárházak objektum alapú logikai, fizikai modellezésére, tervezésére

alkalmas,

javasoltan

CASE

(Computer

Aided

Software

Engineering) eszköz, 

Az

SQL

elterjedtsége

és

az

ad-hoc

jellegű

információs

igények

kielégíthetősége miatt az adatbázis-kezelővel szembeni követelménye, hogy SQL interfésszel rendelkezzék 

WEB

alapú

alkalmazások

készítésére

alkalmas,

objektum

orientált

alkalmazásfejlesztő eszköz, 

a kapcsolati koordináció Java-alapú fejlesztő eszköze

Az előző fejezetekben említett integrációs követelményeknek eleget tévő, homogenizált információs háttér szinte bármilyen platformon futhat. Jellemzőek lehetnek az alábbiak, amelyek közüli választás egyik legfontosabb szempontja a biztonság: 

UNIX



Windows NT



Linux



SUN Solaris



IBM AIX

3.1.7 A megbízható üzemeltetés alapja A

Bakony-Balaton

Mechatronikai

és

Járműipari

Klaszter

projektcsatorna

rendszerének üzemeltetése során, a megbízható üzemeltetés és az események 59

nyomon követhetősége két lényegi szempontot kell, hogy figyelembe vegyen 

A heterogén információs környezet integrálására alkalmas alkalmazásszegmensnél – tartalomkezelési, elérhetőségi és biztonsági szempontból egyaránt

–

rendkívül

fontos

az

események

megbízható

és

pontos

adminisztrálása. Az alkalmazás valamennyi komponense (alrendszerei, tartalma, kapcsolódásai) nyilvántartandó, paraméterezendő, indítható, illetve leállítható kell, hogy legyen, beleértve a bejelentkezések, kezdeményezések és kijelentkezések teljes körét. A naplózás jelentős processzor és háttértároló kapacitást igényel, amit a hardver megválasztásánál figyelembe kell venni. 

A megfelelően képzett humán-erőforrás háttér (alkalmazók és üzemeltetők) tanfolyamok, tréningek keretében sajátíthatja el a szükséges ismereteket. Ennek két kiemelt területre kell vonatkoznia: az alkalmazók/üzemeltetők egyrészt legyenek felkészültek a rendszer üzemszerű használatára, másrészt sajátítsák el az ad-hoc jellegű problémák megoldásának képességét. A képzések szükségszerűen illeszkedjenek az általános informatikai készség és képesség megszerzésének, továbbá a konkrét alkalmazás feladat-orientált, könnyű és hatékony használatának követelményeihez.

60

3.2 Az információs rendszerhez illeszkedő adatmigrációs javaslat Amint az a korábbi fejezetekben olvasható, a rendszerrel szembeni elvárás a heterogén információs környezet integrálása adatintegrációs adapterei révén. Ahogy a korábbiakban az adatintegráció kapcsán már szó volt róla, alapvetően egy rendszerszervezési alternatíva jöhet szóba: 

Központosított rendszer: Az ismert problémákból adódóan – erőforrások szűkössége, formális és informális kapcsolatok kiforratlansága stb. – adódóan az integráció célszerűen azt kell, hogy jelentse, hogy az adatokat egy fizikai terület, a Bakony-Balaton Mechatronikai és Járműipari Klaszter menedzsment szervezetének

diszkterülete alá importálunk. Természetesen ez is jelentős

odafigyelést, munkát és kapacitást igényel, azonban a költségek kímélésének járható útját jelenti. A költséghatékonyság mellett ennek az alternatívának további előnye a magasabb szintű adatbiztonság és az üzemeltetés biztonsága, a könnyebb karbantarthatóság. Ez adja továbbá a legtöbb lehetőséget a funkciók gazdagságára, és ez esetben a legegyszerűbb az Internet lehetőségeinek a kihasználása is. Az adatok biztonsági, terhelhetőségi szempontjait figyelembe véve fontos teendő az adatrögzítés és karbantartás, melynek folyamata – a korábban ismertetettek alapján – lehet on-line és off-line egyaránt. A korszerű, rendszerekben az elsődleges adat

módosulása

után

on-line

módon,

gyakorlatilag azonnal

megtörténik a replikáció, mely az elérhetőség és a terhelhetőség szempontjából egyaránt jelentős előnyökkel jár. Az off-line replikáció akkor előnyös, ha a fogadó, integrált adatbázisnál nem elsődleges szempont az elsődleges és replikált adatok állandó korrelációja. A javasolt költségkímélő megoldás esetében a kevert változat a követendő megoldás, mely esetben az azonnali adatrögzítés on-line alapon valósul meg, de ugyanakkor

lehetőség

biztosítása

javasolt

a

projekt-adatlapok

számítógépeken, internetes letöltésen, CD-n stb. keresztüli transzferére is.

61

mobil

A rendszer működésének eredménye egy olyan hiteles, redundancia mentes adatállomány, mely az információk kinyerésének kiindulási törzsállományaként szolgálhat.

3.2.1 A rendszer elemei 3.2.1.1 Adatmigrációs rendszer adatbázis struktúrája A rendszer struktúráját tekintve két fő elemre tagolható: 

Az adatmigrációs rétegre feladata lehetővé tenni a forrásadatok gyűjtését, puffer

területet

biztosítani

a

különböző

adatgazdáktól

érkező

adatok

bevárásához, tárolni a verifikáló és konvertáló eljárásokat. 

A törzsadat struktúrára, más néven adattárház egy egységes, normalizált adatmodellre épülő adatbázis, egyfajta operatív adattár, melyben

az

információs rendszer valamennyi adata egységesített formátumban elérhető.

3.2.1.2 A rendszer funkciói 3.2.1.2.1 Forrásadatok kinyerése Az

off-line

adatkonverzió

esetében

az

adatokat

valamennyi

adatgazda

rendszeréből előre átmásoljuk az átmeneti központi, ún. puffer tárolóba. A másolás többféle platformról, az operációs rendszer által biztosított technikák alkalmazásával történik. A másolás folyamán az adatok át kell, hogy essenek egy elsődleges fizikai és biztonsági ellenőrzésen – és szükség szerint adattípuskonverzión –, így a központi tárolóban már ellenőrzött, az adattárház által befogadható adattípusok állnak rendelkezésre.

3.2.1.2.2 Adatfeldolgozás Ezen funkció biztosítja az adatgazdáktól érkező adatok tisztítását, egységesítését, szűrését és beintegrálását az adattárház „elő-adatbázisába”, szakszóval a

62

konszolidált migrációs adatcentrumba. A feldolgozás végére előálló adathalmaz kiindulási adathalmazt jelent az adatgyűjtéshez és ellenőrzéshez. A migrációs adatcentrum kialakításához szükség van egy egységes és jól definiált fogalomtár kialakítására, amely az adatgazdáktól érkező rendszerekben használt összes fogalmat tartalmazza, természetesen magában foglalva a korábbi fejezetekben

javasolt

mutatókra

vonatkozó

jellemzőket.

A

fogalmakhoz

hozzárendeltek azok attribútumai – különös tekintettel az adott fogalom részletes magyarázatára. A kialakított fogalomtár tartalmazza a gazdarendszerek és folyamatok elemeinek és – kiemelten fontos szempontként – az adatok tartalmának egységes értelmező szótárát. A fogalomtár létrehozásával párhuzamosan – a fogalomtár véglegesített elemeire alapozva – ki kell, hogy alakuljanak az ún. kódszótárak. A kódszótárként értelmezhető táblázatok sorai egy-egy fogalomnak – illetve konkrét értékkel feltöltött attribútumainak – felelnek meg, míg az oszlopai megadják azt, hogy a különböző gazdarendszerekben milyen típusú, méretű és értékű a szóban forgó fogalom. A kódszótárak felhasználásával érjük el az adatok fogalmi tisztítását és konvertálását. Az adatgyűjtés és feldolgozás végeredményeként előálló, átadásra alkalmas migrációs tárat személyes és technikai ellenőrzéssel hitelesíteni kell. Mindez lehetőség szerint bizonylatolt formában kell, hogy történjen. A bizonylatolás egyrészt automatikusan generált riportok, másrészt személyesen kitöltött hitelesítő lapok formájában testesül meg, melyeket feladatra – esetlegesen személyre is – szólóan kapják meg a hitelesítő szakemberek. A visszaellenőrizhetőség, a nyomon követhetőség végett a rendszernek támogatnia kell mind az egyes adatok, mind az egyes adatlapok életciklusának figyelését, állapotváltozásainak követését. Az ellenőrzési ciklus végén feláll az a hiteles adatállomány, melyet a tényleges, „éles” tárterületen lévő, aktuális központi adattárház számára át lehet adni.

63

3.2.1.2.3 Adatátadás A migrációs rendszernek biztosítania kell egy olyan felületet a komplex információs rendszert vezérlő modul felé, melyen keresztül az elérheti, és saját adatterébe áttöltheti a hitelesített adatokat. Az átadások a nyomon követhetőség és biztonságosság végett egyrészt kötelezően, automatikusan generált módon naplózásra kell, hogy kerüljenek, másfelől kötelező a korábbi állapotok visszaállításának és a bármikor újratölthetőségnek a biztosítása. Adatmigrációs rendszer üzemeltetése során a rendszergazdai teendők – mentések, archiválások, verziókezelés, felhasználó menedzselés – támogatására a rendszer külön modullal kell, hogy rendelkezzék, melyet csak minősített jogosultsággal rendelkező személyek érhetnek el. Az időkorlátok betartására, a folyamatok állapotának figyelésére – kiemelten az adatok aktualitásának kérdéseire – ki kell alakítani egy elemző rendszert, mely alkalmas kell, hogy legyen a sajátosan informatikai és a tartalom-felügyeleti vezetői információs igények kielégítésére. A modul magába foglalja mindazon lekérdezési felületeket, melyek a rendszer működéséről, a feldolgozottság százalékáról valamint az adatminőségről nyújtanak információt.

3.2.1.3 A rendszer architektúrája Az adattárház adatait egyrészt belső operatív rendszerekből, adatrögzítéssel előállítva (pl. a projektek esetében), másrészt külső adatgazdák forrásaiból kell kinyerni. Az adatkészletet kezelését az előzőek alapján tehát egyetlen központi szerver végzi. Ez az adatkészlet minden további döntéstámogatási – lekérdező, exportáló – rendszer adatszolgáltatója. Az eltérő tartalmak alapján szükség lesz arra, hogy az adatokat valamennyi inputként értelmezhető rendszerből átalakítsák és az említett központi adattárházba áthelyezzék, mely átalakítás lehetőség szerinti automatizálása rendkívül fontos, folyamata az input adatstruktúrák pontos ismeretében definiálható. Elvárás, hogy az integrálandó adatokat backup jelleggel migrálják, majd folyamatosan frissítve tárolják az adattárház által képviselt adatbázis technológiába. 64

A rendszer kiépítésekor elegendő arra figyelemmel lenni, hogy egy statikus adatmigrálást kell végrehajtani, azaz a folyamatok viszonylag egyszerűek, nem szükséges

a

beintegrálandó

rendszerekben

dinamikusan

változó

adatok

átvételének azonnali megoldása. A migrációs réteg átvételi interface-szel nem kell, hogy rendelkezzék az adattárházat kezelő felület felé, hiszen az egyes szakterületi adatok visszirányú frissítését a rendszer nem kell, hogy magára vállalja. Nincsen szükség olyan központi

adatforgalmi

rétegre,

mely

hiteles

adatokat

oszt

szét

a

„gazdarendszerek” részére. Ugyanakkor a célorientált adatállományok generálása – a tervezés, a monitoring stb. megfelelő alterületeire – megfelelő leválogató eszközök segítségével célszerűen megoldandó, kialakítható egy intranet alapon működő komplex elemzési, statisztikai adatszolgáltató rendszer.

3.2.1.3.1 Fogalmi tisztázás 

Importálás a belső operatív rendszerekből, illetve külső adatgazdák forrásaiból érkező adatok átmásolása egy központi tárolóba. A terhelés optimalizálása végett, az egyes áttöltési ciklusokban – amennyiben ez lehetséges – csak új adatok töltődnek át.



Pufferterület lehetővé teszi a forrásadatok gyűjtését, a különböző rendszerekből és helyekről érkező adatok bevárásának eszköze. Az adatok formátuma megegyezik az adatgazdáktól érkezővel, így kerülnek biztonsági lementésre, ezáltal az eredeti fájlok szükség esetén visszaállíthatóak.



Szűrés, integrálás a forrásrendszerekből feltöltött nyers adatok tisztítása, egységesítése és szűrése, majd beintegrálása a Migrációs Adat Centrumba.



Migrációs Adat Centrum Normalizált

adatmodellre

épülő

adatbázis, 65

felépítése

az

adattárház

adatállományának struktúrájával megegyezik, konszolidált forrásként szolgál az Adattárháznak. 

Összegzés az adatok betöltése az Adattárházba.



Adattárház az Adattárház egy relációs adatbázis, struktúrája megegyezik a Migrációs Adat Centruméval. A lekérdezések, keresések, gyűjtések és exportok tára.



Egységes fogalomtár (metaadat tár) integrált metaadat kezelő alrendszerre, mely együttműködik valamennyi rendszerelemmel, a felhasználók számára elérhetővé teszi a technikai és információs metaadatokat is.



Lekérdezés, elemzés, adatelérési eszközök a felhasználók egyrészt előre definiált adatelérési eszközökön keresztül érik el az Adattárház adatait, másrészt lehetőséget kell biztosítani – természetesen megfelelő jogosultságokhoz kötötten – az Adattárházból való közvetlen, „adhoc” adatelérést is, eseti, előre nem definiált lekérdezésekhez.



Biztonsági másolat, archívum az archívum a biztonsági okokból mentett adatokat tartalmazza, melyeket nem tartunk on-line. Segítségével megoldhatóvá válik az „éles” adatok közvetlen elérhetőségének visszaállítása.

66

Projektcsatorna migrációs rendszer architektúrája Egységes fogalomtár

Input adattár1

Input adattár2

.. .

Input adattár3

Szűrés Integrálás

Importálás

Migrációs Adat Centrum

Összegzés

Adattárház

Felhasználó

Pufferterület

Input adattárn

Biztonsági másolat

Biztonsági másolat

Lekérdezés, elemzés

Biztonsági másolat

3.2.2 A rendszerelemek értelmezése 3.2.2.1 A fogalomtár Egységes és jól definiált fogalomtár kialakítása a rendszerek működésnek, a folyamatok elemeinek, az adatok tartalmának egységes értelmezésére szolgál. Az eredeti adatforrásokat jellemző lényeges információkat, mint szöveges leírásokat – szemantikai metaadatokként – a felhasználók egy központi tárból, a metaadattárból érhetik el. A szöveges leírások egységes és helyes értelmezését az ugyancsak a metaadattárból publikált fogalomtár segíti, ez biztosítja, hogy az eredeti adatforrások tartalmát a központi adattárban a felhasználók logikailag helyesen és egységesen értelmezzék. A rendszerben használt fogalmak egyértelmű jelentést kapnak, a rendszerben használt fontosabb fogalmak definiálandók, a fogalmak egyértelmű jelentést hordozó értelmezése rögzítésre kerül, amely mint leíró, magyarázó rész metaadatként a felhasználók számára elérhető.

3.2.2.2 A kódszótár A kódszótár a

fogalomtáron

alapuló szótárat,

mely egy-egy fogalomra

vonatkozóan az egyes alkalmazásokban alkalmazott kódok értékeit felelteti meg a központi Adattárházban használt értéknek. A kódszótár kódjai hozzá vannak rendelve konkrét fogalmakhoz – pl. mutatókhoz. Az adattárházba betöltés során a kódszótár segítségével azonosítjuk, hogy adott forrásrendszerbeli kódnak milyen kódot kell az Adattárházban megfeleltetni, ezáltal garantálva, hogy egy fogalomnak az adattárházban csak egy és csakis egy konkrét kódja lehessen.

3.2.2.3 Logikai adatmodell A forrás rendszerekben lévő adatokat az adatgazdákkal való megállapodásokat követően részletesen és pontosan kell definiálni. A feltérképezés alapján el kell készíteni egy olyan logikai adatmodellt, mely redundancia nélkül tükrözi a forrás

rendszerekben lévő adatokat, és alapját képezi az Adattárházba történő áttöltésnek. Mivel valószínűleg valamennyi forrásrendszer relációs, belőlük a relációs sémákra vonatkozó adatok – táblák, attribútumok, adattípusok, kulcsok stb. – egyaránt meghatározandók. Cél az átfogó relációs séma normalizált kialakítása, mely biztosítja a redundancia minimális értéken tartását a Migrációs Adat Centrumnak nevezett adatterületen. A fentiekben kifejtettek alapján a logikai adatmodell felállítása az alábbi főbb lépéseken keresztül valósul meg: 

forrásrendszerek részletes felmérése



fogalomtár elkészítése



forrásrendszerek logikai modelljeinek definiálása



forrásrendszerek koncepcionális modelljeinek definiálása



átfogó koncepcionális modell előállítása



átfogó normalizált logikai modell származtatása.

3.2.2.4 Fizikai adatmodell A logikai adatbázis tervezés során első lépésben kialakul a nyers adatmodell, majd a normalizálás során a tényleges logikai modell. Ahhoz, hogy a modellben adatokat helyezhessünk el, társítani kell egy adatbázis-kezelőhöz és felruházni specifikus fizikai jellemzőkkel – adatok fizikai tárolási módja, helye, indexek tulajdonságai, stb. E téren javasolt egy olyan integrált eszköz alkalmazása, mely támogatja a munkát a végső adatbáziskép kialakításáig, a logikai modellből generálja az adatbázis-kezelő számára annak első megközelítésben javasolt fizikai struktúráját. A tervezés fontos lépése a fizikai adatmodell további fejlesztése. Az adatbázis integritásának

és

konzisztenciájának

a

megtartása

érdekében

kulcsokat

(elsődleges jellemzőket), indexeket (egyedi vagy összetett rendezettségeket) és nézeteket (felhasználóra szabott vizuális tartalmakat) szükséges létrehozni, olyan

objektumokat – triggereket, tárolt eljárásokat – definiálni és beépíteni, amelyekkel befolyásoljuk az adatbázis viselkedését pl. egy-egy adattöltés során.

3.2.2.5 Metaadat struktúra kiépítése Az adatok, adatmozgások minden részletre kiterjedő adminisztrálása a folyamatok kézben tartásának célszerű – talán egyetlen – módszere. A felhasználók „kereséseik” során az adattárházban tárolt adatok elsődleges forrását és struktúráját nem kell, hogy ismerjék. A megoldást a metaadattár létrehozása és folyamatos karbantartása jelenti. A metaadatokat minden, az Adattárházban lévő adatról rendelkezésre állnak a következő csoportokban: 

A szemantikus metaadatok magukban hordozzák az adattárházban tárolt információk helyét, megmagyarázzák jelentésüket. Az adattárház egyes elemei szemantikus definíciójánál nem szabad, hogy a definíció hossza, a lemezterület-felhasználás, a karakterhasználati konvenciók a közérthetőség rovására menjenek. A szemantikus metaadatok között szerepelnek azok a „felhasználási” – kvázi üzleti – szabályok, amelyek az adattárházban nyilvántartott információkra vonatkoznak. Ideális esetben minden egyes technikai metaadat-elemnek megfelel egy – a szemantikus metaadatok között szereplő – „felhasználási” definíció.



A technikai metaadatok az adattárházat megvalósító szoftverelemek, illetve az adattárház

fejlesztői

számára

szolgálnak

útmutatásul.

Alapvetően

az

Adattárház adatbázissémáját jelentik, beleértve logikai adatmodellnél jelzett speciális

definíciókat,

továbbá

az

adatkinyerési

folyamathoz

definiált

feldolgozások név-(hivatkozási) deklarációit is 

Az

adminisztratív

szükséges

metaadatok

információk,

az

az

adattárház-adminisztrátorok

adattárház

minőségi

számára

színvonalának

és

teljesítőképességének megőrzéséhez szükséges információkat tartalmazzák. Ilyenek a használati szokások és válaszidők – amelyek alapján a rendszer továbbfejleszthető, pl. összegzési szintek, indexek vagy particionálás stb. – az

adattárház teljesítményének maximalizálását leginkább befolyásoló tényezők. E metaadatok között szerepelnek a biztonsági és hozzáférési szabályok, mint az adattárház elérésének kezelésében és felügyeletének eszközei. A metaadatok folyamatos aktualizálása az egész rendszer szempontjából meghatározó

jelentőségű.

Hatékony

metaadat

kezeléshez

központi

adatadminisztráció és adatbázis adminisztráció kialakítása elengedhetetlen, megvalósításához definiáljuk az adatadminisztrációs feladatköröket, a felelősségi körök elhatárolását, az automatizált adatadminisztrációs eszközök használatát. A metaadatok előállítása a következő tevékenységeket foglalja magában: 

Logikai metaadat tervezés, mely során támaszkodni kell a meglévő adatdefiníciós

eredményekre,

adatszabványokra,

a

fogalmi

adat

meghatározása, az adat attribútumok meghatározása, az adatmodellezés és a konzisztencia vizsgálat terén egyaránt. 

Fizikai metaadat tervezés, mely a logikai metaadat tervezésre alapozva az adatbekerülési módszerválasztás, a hitelesítési módszerválasztás, a fizikai tárolási forma meghatározása, az adat illesztése az adatbázis szerkezetébe, az

indexek,

kulcsok,

struktúrák,

hierarchiák

meghatározása

résztevékenységekből áll.

3.2.2.6 Az importálás, azaz az adatok kinyerése E téren két alapvető teendőt kell definiálni, egyfelől az adatok kezdeti kinyerésének, másfelől a rendszeres üzemeltetés során történő kinyerésének a fázisát. A kezdeti fázisban az adatok mozgatása a forrásrendszerektől, adatgazdáktól az adattárház felé viszonylag rövid időszak alatt lezajló, viszonylag csekély adatmennyiségeket érintő folyamat. A másik fázisban az adattranszfer szintén kevesebb adatot érint egységnyi idő alatt, tehát ez az út is kevésbé terheli a fizikai kapcsolati láncot. Mindkét fázisban alapozhatunk arra, hogy valamennyi adatforrás – belső vagy külső – számítógép-hálózaton keresztül is elérhető, a pontos

stratégia

kidolgozása

csak

az

egyedi

szerződések

forrásrendszerek állapotának részletes definiálása után lehetséges.

alapján,

a

A

másolatként

szolgáló

backup

adatállományok

létrehozásához

a

forrásrendszerek adatállományait érkeztetni kell az állomásoztató puffer-területen, mely célszerűen az Adattárház központi diszk alrendszerén kerül kialakításra. Innen egy másik – pl. mágnesszalagos – adattároló egység révén mentésre kerül, előállítva egy konszolidálás nélküli, tényleges másolatot a forrásrendszerekből kinyert adatokról.

3.2.2.7 Kinyert adatok megfelelő ellenőrzése és szűrése A nyers bemeneti állományokból az Adattárházba kerülő adatokat – a már említett logikai

adatmodellnek

és

az

egyes

állományokra

egyedileg

érvényes

szabályoknak megfelelően – ellenőrizni és automatikusan szűrni kell. Ez a folyamat olyan előre megállapított, de változtatható szabályok alapján történjen, amely megvalósítja a logikai adatmodellnek való megfelelést. Az eredeti forrásrendszerekből

kinyert

adatok

kódtípusai

–

karakterkészletek,

mezőformátumok, minden egyéb specifikus logikai, fizikai sajátosságot figyelembe véve – oly módon kell, hogy konvertálódjanak az Adattárházba, hogy eredeti jelentésük egyértelműen értelmezhető legyen. A konkrét munkafolyamat során ellenőrizni kell a fájlok fizikai megjelenését és az adathibákat. Az adatok helyességét, teljességét, adatátviteli hibákat, az adatok integritását, az adatok tulajdonosát, üzemszerű működését vizsgálva feltárandók a működési zavarok, meghatározandó az eredmények minősége. A dokumentálás során fontos a személyi kötődés rögzítése, azaz ki, mikor, melyik rendszer melyik file-ját milyen minősítéssel dolgozta fel. A kódszótárak tartalmazzák az importálandó rendszerek régi, és a Migrációs Adatcentrumban – majd az Adattárházban érvényes – új kódjait, kódtípusait, logikai, fizikai, sajátosságait és a konverziók végrehajtásához szükséges eljárásokat. Általában elkerülhetetlen, hogy az ellenőrzés során ne keletkezzen hibalista, az összegzéseket ugyanakkor csak a hibátlan file-okra és adatokra lehet megkezdeni.

A logikai és fizikai adatmodellekre a bemeneti rendszerek és az Adattárház bármilyen változtatása kihat, mely változásokat eredményez nemcsak a kódszótárakon, hanem általában a logikai és fizikai adatmodelleken is. Mindez többnyire a fizikai modell, az adatbázis megváltoztatását, súlyosabb esetben akár a felhasználói programok módosítását is jelentheti, mely szabályokat az adatadminisztrációs,

adatbázis

karbantartási

feladatok

megtervezésénél

figyelembe kell venni. Egyértelműen javasolható egy olyan komplex megoldás, mely során a bejövő adatok feldolgozása nem sok kis különálló feladat megoldásaként történik, hanem könnyen ellenőrizhető teljes körű folyamatként.

3.2.2.8 Adatkonszolidáció A bemeneti adatállományok esetleg részben azonos adattartalmuk és eltérő állapotuk miatt konszolidációt igényelnek az adattárházba való felvételük előtt annak érdekében, hogy annak igazságtartalma optimális legyen, mentes legyen az indokolatlan redundanciáktól. Ez a konszolidáció a kidolgozott adatmodellen alapulva hajtandó végre, biztosítva, hogy az egyes rendszerekben meglévő de többször ismétlődő adatok csak egyszer legyenek az Adattárházba betöltve. A forrásrendszerek adatainak konszolidálásához szintén az adatgazdákkal történt definiálások eredményei – a fogalomtár, kódszótár és a logikai adatmodellek – jelentik a kiindulópontot. A kinyert adatok megfelelő szűrése és kondicionálása után kell gondoskodni arról, hogy az egyes rendszerekben meglévő de többször ismétlődő adatok csak egyszer legyenek a normalizált adatcentrumba – majd az intézményi adattárházba – betöltve.

3.2.2.9 Adattisztítás A beemelés, konvertálás során egyrészt biztosítani kell, hogy minden adat megfeleljen a bevitelekor érvényes input ellenőrzési szabályoknak vagy az

adatmodell készítésekor esetleg addicionálisan megállapított szabályoknak. Másfelől biztosítani kell, hogy a forrás rendszerekben lévő hiányos adatok megfelelő kiegészítésére megfelelő eljárás eleve meghatározott legyen, ennek végrehajtása alapján kerüljenek az Adattárházba betöltésre. A forrásrendszerek definiálásakor pontosan kiderül, mely adatok elfogadhatók és feldolgozhatók. Erre a felismerésre egy komplett szabályrendszert kell felépíteni, amely alapjául szolgálhat a tisztítási mechanizmusnak, amely tulajdonképpen az érvénytelen és hibás adatok kiszűrése. A hiányzó adatok kezelésének metódusát forrásrendszerenként külön-külön kell kidolgozni. A feladat jellegéből fakadóan nem garantálható természetesen, hogy valamennyi hiányzó adat helyreállítható lesz. Érvényességi

szabályokat

kell

az

adatfolyami

modulokba

beépíteni.

A

forrásrendszerek definiálása megadja, hogy az azonosnak tűnő adatokat melyik milyen módon tárolja. A konszolidáció során egyértelművé válik, hogy a célmodell milyen

adattárolási

módot

követel

meg,

ezen

szabály

alapján

olyan

rendszerenkénti adatkezelési, algoritmusra van szükség, amely megvalósítja az egységes tárolási módot.

3.2.2.10

Lekérdezések

A meglévő adatokból az adatszótárral azonosított adatokból egyszerű a lekérdezés támogatása. A lekérdező eszköz célszerűen kell, hogy támogassa az összegfokozatok beállítását, valamint az adatok többdimenziós szűrését, kombinálását. Emellett támogatnia érdemes a szabályfelismerő részben kialakított – felhasználói szokások alapján meghatározott – profilok szerinti kimutatások készítését, esetleges előrejelzéseket. A standard és ad-hoc lekérdezés LAN és web környezetben egyaránt megvalósítható kell, hogy legyen. A csak böngészővel rendelkező kliensek könnyen tájékozódjanak, válogathassanak kész „egységcsomagok” között, ezeket képernyőre lekérhessék, lokálisan elmenthessék, kinyomtathassák. Az eseti

lekérdezések összeállításának és futtatásának során a használt eszközök jól skálázhatóak legyenek, legyenek képesek a terhelést optimálisan megosztani. Mint fentebb olvasható, a lekérdezések összeállítása a metaadatokon alapul, amelyek a központi metaadatbázisból elérhetőek.

3.3 A felhasználók számára nyújtott szolgáltatások 3.3.1 Felhasználói csoportok A

rendszer

különböző

funkcióinak,

szolgáltatásainak

elérhetősége,

a

jogosultságok felhasználói csoportonként eltérőek. Tekintettel arra, hogy a rendszer alapvetően tájékoztatási, régiómarketing funkciókat is betölthet, nem célszerű túl sok korlátozást és túlzottan sokféle felhasználói csoportot kialakítani. Figyelembe kell azonban venni, hogy a hozzáféréseket az adatgazdákkal kötött megállapodások, szerzői jogi megszorítások is korlátozhatják. Alapvetően ötféle hozzáférési jogosultság kialakítása javasolható: 

Érdeklődő: jelszó nélkül korlátozott hozzáféréssel rendelkezik, az általános információkhoz

jut

hozzá

(a

projektcsatorna

rendszer

bemutatása,

alapdokumentumok, stb.). 

Regisztrált klasztertag: Az előzőektől annyiban különbözik, hogy lehetősége van a saját adatainak módosítására. Saját projektjei esetén on-line rögzítésére és adatmigrációra is lehetősége van.



Tervező és döntéshozó: Ide tartoznak mindenek előtt a klasztermenedzsment tagjai, az általuk felkért szakértők. Gyakorlatilag teljes körű hozzáféréssel rendelkeznek minden adattartalomhoz; on-line módon (is) elérhető funkciókat is biztosít, akár pl. a szakértői értékelésekhez. Bár e csoport jellemző információigénye eltérő részletességű lehet, az esetleges egyedi igények kielégítése érdekében célszerűnek látszik azonos hozzáférési jogosultságokat biztosítani számukra.



Operátor: valamennyi bemenő adatot jogosult felvenni, vagy módosítani, illetve gondoskodik az archiválásról. Gondoskodnak továbbá az adminisztrációs feladatok elvégzéséről.



Rendszergazda: teljes jogú hozzáférés valamennyi adathoz és funkcióhoz. Kulcsfontosságú adatfrissítés.

feladata

az

adatgazdákkal

való

kapcsolattartás,

az

3.3.2 A rendszer alapszolgáltatásai Az információs rendszer szolgáltatásain belül el kell különíteni a karbantartási funkciókat és a szűkebben vett információs funkciókat.

3.3.2.1 Karbantartási funkciók A

karbantartási

funkciók

a

szokásos

(adatfelvétel,

módosítás,

törlés,

jogosultságok beállítása, archiválás) mellett a különböző algoritmusok (pl. számítási,

besorolási

eljárások)

esetleges

módosítását

szolgálják.

Az

adatmódosítások során figyelembe kell venni, hogy a statisztikai adatok, továbbá a projektek adatai visszamenőlegesen több évre is megmaradjanak, lehetővé téve az időbeli változások követését és feltárását. Az adatmodellben ennek lehetőségét

a

megfelelő

mezők

többszörözése

adja,

amelyek

tartalma

módosításkor FIFO technikával kerül aktualizálásra. 

Adatmódosításra és új adat felvételére csak a rendszergazda, az operátorok – illetve megfelelő korlátozásokkal a pályázók és az értékelő szakértők – jogosultak. Adattörlés és a jogosultságok beállítása kizárólag rendszergazdai szinten történhet.



Különösen

a

projektfejlesztési

modul

esetében

hangsúlyoztuk

a

paraméterezhetőség követelményét. Esetenként előfordulhat, hogy az egyes eljárások paramétereiben lehet szükség módosításra. A módosításról olyan módon kell gondoskodni, hogy az ne legyen hatással a korábbi időszakokra vonatkozó eljárásokra, vagyis e paraméterek több változatát is tárolni kell a rendszerben. Az ilyen módosításokra csak a rendszergazda jogosult. Az operátori szintű karbantartási funkciókhoz soroljuk azokat az adatrögzítési, módosítási feladatok is, amelyek pl. a projektinformációk érkeztetésével kapcsolatosak, továbbá a kapcsolódó adminisztrációs eljárásokat (értesítések, döntés-előkészítés), illetve az ehhez kapcsolódó formalevelek, listák generálását.

3.3.2.2 Információs és egyéb szolgáltatások Az alapvető információs funkciók, illetve a felhasználóknak nyújtott egyéb szolgáltatások igazodnak az előzőekben ismertetett hozzáférési jogosultságokhoz. A következőkben ezeket az alapfunkciókat ismertetjük röviden – figyelembe véve, hogy a funkciók egymásra épülnek. 3.3.2.2.1 Nyilvánosan hozzáférhető információk A nyilvánosság (érdeklődők) számára hozzáférhető információk köre az alábbi lehet: 

A Bakony-Balaton Mechatronikai és Járműipari Klaszter projektcsatorna rendszerének rövid bemutatása.



A Bakony-Balaton Mechatronikai és Járműipari Klaszter alapvető bemutatása (tevékenység, tagjai, elérhetőség).



A projektcsatorna rendszer regisztrációs űrlapja, annak érkeztethetősége.



A klaszter projektalapú tevékenységeire vonatkozó, alapvető statisztikai adatok.



Általános információ projekt-ötletekről, a forrásbiztosításhoz kapcsolódó pályázati kiírásokról, befektetői lehetőségekről, mindezek letölthetőségével és az on-line regisztráció lehetőségével. Kapcsolódhatnak a pályázatok sikerét elősegítő

egyéb

segédanyagok

is,

pl.

projekttervezés

módszertana,

megtérülés-számítást segítő kalkulációk stb. 

A projektfejlesztési eredmények megtekintése: projektek listája, alapvető statisztikák.

3.3.2.2.2 A projektgazdák számára biztosított speciális funkciók A regisztrált projektgazdák számára az előzőekben említett funkciók mindegyike elérhető, de azok kiegészülnek néhány további szolgáltatással: 

Lehetőség

a

projekt

meghatározott

adatainak

on-line

módosítására,

kiegészítésére, pl. a projektgazdák adataiban bekövetkezett változások átvezetése, a projekt tartalmának, költségvetésének módosítása.



A projekt értékelésére

vonatkozó információk megtekintése, szakértői

vélemények. 

A

projekt

végrehajtásával,

monitoringjával

kapcsolatos

információk

megtekintése és rögzítése.

3.3.2.2.3 A tervezők, döntéshozók támogatása A tervezők és döntéshozók – alapvetően a klaszter-menedzsment és szakértők esetében ugyancsak az előző funkciók és információs tartalmak bővülnek tovább, mely alól kivétel természetesen a projektszintű adatok módosításának lehetősége, amely e felhasználói kör számára nem lehetséges. 

Gyakorlatilag teljes körű hozzáféréssel rendelkeznek minden adattartalomhoz;



Lehetőségük van interaktív módon információk lekérdezésére, ezzel ad-hoc jellegű információs igényeik kielégítésére.



A projektfejlesztő alrendszer lehetővé teszi az értékelési szempontok és a kapcsolódó pontrendszer kidolgozását, a szakértői értékelések felvételét - online módon is - és az ezeken alapuló listák generálását, pl. döntéselőkészítéshez.



Hozzáférést biztosít a projektek teljes adattartalmához, böngészési és keresési (leválogatási) funkciókkal.



Projektalapú statisztikák, a projektek összesítésével adódó kimutatások

3.3.2.3 A szolgáltatások struktúrája, a javasolt menürendszer Az előzőekben vázolt szolgáltatási funkciókat az alábbi struktúrába célszerű rendezni, ami egyben a rendszer lehetséges menüszerkezetének az alapját is képezheti.

Jogosultság OS ÉRTOS OS ÉRTOS OS

1. szint Magunkról

2. szint A klaszter rövid bemutatása

3. szint A bemutatkozó anyag karbantartása A bemutatkozó anyag böngésző alatti megjelenítése A projektcsatorna rendszer bemutatása A bemutatkozó anyag karbantartása A bemutatkozó anyag böngésző alatti megjelenítése Csatlakozási platform (szándéknyilatkozatok, Az alapvető „biankó” űrlapok karbantartása regisztráció, stb.)

ÉRTOS OS

Az alapvető „biankó” űrlapok kitöltése, érkeztetése Projektalapú lehetőségek

támogatási Az adattár karbantartása, pályázati dokumentációk,

RTOS

kapcsolódó linkek frissítése, cseréje Pályázati dokumentációk, FAQ-k,

RTOS

letöltése, kapcsolódó linkek indítása Közös projektötletek kialakítása

háttéranyagok az

nyilvántartási szintjén

adatlap A

projektötletek

elektronikus

formátumú

RTOS

részanyagainak érkeztetése A projektötletek meghatározott

RTOS

módosítása, kiegészítése A projektötletek értékelése (szakértői vélemények,

RTOS

pontozás), a vonatkozó információk megtekintése. Fiche A Project Fichek elektronikus formátumú

Közös

projektek

kialakítása

formátum nyilvántartási szintjén RTOS

a

Project

részanyagainak érkeztetése A Project Fichek meghatározott módosítása, kiegészítése

adatainak

adatainak

Jogosultság RTOS

1. szint

2. szint

3. szint A Project Fichek értékelése (szakértői vélemények, pontozás), a vonatkozó információk megtekintése. A projektek végrehajtásával, monitoringjával

RTOS

kapcsolatos információk rögzítése, megtekintése ÉRTOS

A projektcsatorna eredményeinek megtekintése: alapvető statisztikák

É – Érdeklődő R – Regisztrált projektgazda T – Tervező és döntéshozó O – Operátor S – Supervisor vagy rendszergazda

3.4 A megvalósítás logikai rendje 3.4.1 A megvalósítandó lépések Az integrált információs rendszer fejlesztését megvalósító projekt feladatainak logikai rendje az alábbiak szerint alakul: 

A fejlesztés előkészítése, elméleti előkészítés − Az

emberi

erőforrások

közreműködőinek,

kiválasztása,

szakértőinek

a

projekt-team

megnevezése.

A

konkrét résztvevők

megismertetése a projekt céljaival, terveivel, a megvalósítása kapcsán felmerülő szerepükkel, végrehajtandó feladataikkal, a szervezet tagjainak globális, személyes indító konzultációja. − A fejlesztéshez, tervezéshez szükséges technikai feltételek megteremtése, a meglévő eszközök tesztelése, a szükséges beszerzések megvalósítása. − A projekt információs csatornáinak kiépítése, különös tekintettel az elektronikus kapcsolattartás eszközeire. − Az implementációt előkészítő elméleti előkészítés (jelen dokumentum) − Az elméleti előkészítés eredményeinek elfogadása. − A szakaszt összefoglaló dokumentációk elkészítése. 

Az implementációs tervezési tevékenység − Részletes rendszerterv elkészítése, azaz a megvalósítandó rendszer funkcióinak

és

működtetési

környezetének

pontos

meghatározása.

Tartalmazza a követelményrendszert, a segédfunkciók, utilityk leírását, áttekinthető funkciótervet, menüstruktúrát, működtetési tervet, azaz a rendszer moduláris kapcsolatrendszerét. − Részletes adatbázisterv elkészítése, azaz a megvalósítandó rendszer adatmodelljének és adatbázistervének pontos definiálása. Tartalmazza a logikai adatmodellt, a megvalósítandó fizikai modellt, az adattáblák oszlopainak magyarázatát, az azokra vonatkozó formai és tartalmi előírásokat, restrikciókat, adatfolyam-diagramot.

− A rendszer-, és adatbázisterv elfogadása. − A szakaszt összefoglaló dokumentációk elkészítése. 

A rendszer felhasználói tesztelésre alkalmas változatának kialakítása, programozás − A programozási tevékenység megtervezése, azaz a programozási feladat eszköz-, humán-, és kapcsolati erőforrásainak és azok kapcsolati rendszerének meghatározása. − Programozás, a rendszer-, illetve adatbázistervek alapján a rendszer számítógépes implementációja. Megvalósítása során: 

meg

kell

határozni

a

már

rendelkezésre

álló

modulokat,

részmegoldásokat, melyeket a fejlesztés során fel lehet használni, 

figyelmet kell fordítani az ajánlott névhasználat konvencióira,



ügyelni kell a felhasználói felület kialakítását szabályozó belső szabványokra,



a programokat el kell látni ún. kommentekkel,



a fejlesztőknek el kell végezniük az egyes programrészletekre, illetve modulokra a fejlesztői tesztet, mely elemi módon ellenőrzi a megírt program működőképességét,

− A programozási tevékenység elfogadása, esetleges visszacsatolások elvégzése. − A szakaszt összefoglaló dokumentációk elkészítése. 

Tesztelés, esetlegesen visszacsatolt korrekciók, végleges, üzemszerű állapot előkészítése − Az megbízható üzemeltetéshez szükséges esetleges hardver fejlesztések, beszerzések megvalósítása. − Belső rendszerteszt, ennek figyelése, ez alapján a szükséges korrekciók megvalósítása, a rendszertervben megfogalmazottak megvalósulásának ellenőrzése,

a

kezelhetőség,

megbízhatóság,

működési

metódusok

minősítése, megfelelő visszacsatolások folyamatos elvégzése, jobbító intézkedések átvezetése. − Információfogadás, kezdeti adatkinyerés, azaz a rendszer adatokkal történő

feltöltése,

hozzáférések

kritikus

figyelése.

A

adatmennyiség-kísérletek, nagytömegű

adatkezelés,

konkurens az

általános

válaszidők ellenőrzése, konkurens hozzáférés zavartalan biztosítása, azaz annak tesztelése, hogy a párhuzamosan, ugyanazon adathalmazon dolgozó munkaállomások ne zavarják egymást. Kulcsfontosságú szempont az ún. deadlock szituációk kiszűrése. − A rendszert hasznosítani tudók bevonása a tesztelési folyamatba, pilot projekt indítása, a rendszer használatának „laikus felhasználó” általi minősítése, megfelelő visszacsatolások folyamatos elvégzése, jobbító intézkedések átvezetése. − A tesztelési tevékenység elfogadása. − A szakaszt összefoglaló dokumentációk elkészítése. 

Az üzemeltetés teljes körű indítása, publikációk − Az üzemszerű működés teljes körű beindítása. A megvalósítás során a projektvezető 

gondoskodik az installáló anyagok és installálási/üzembehelyezési forgatókönyv összeállításáról,



megszervezi a végleges üzembe helyezés feladatait, és egyezteti a feladatokat,



feladata a sikeres záró telepítés, a funkcionális működőképesség bemutatása, a kapcsolódó alapoktatás, valamint a belső átadás/átvétel utáni teljesítési jegyzőkönyv elkészítése,



megszervezi

a

záró

„üzemi

próbát”,

s

annak

kiértékelését

jegyzőkönyvben rögzíti, 

gondoskodik az installáló anyagok elhelyezéséről, valamint azok megfelelő védelméről,



megszervezi a kapcsolódó üzemeltetési oktatást, betanítást. Ehhez biztosítja a megfelelő oktatási anyagokat, segédletet, számítástechnikai hátteret, oktatót/oktatókat, ütemezést.

− Járulékos intézkedések, a projekt „utóéletének” biztosítása. Ez jelenti a más

projektben

is

használható

megoldások

dokumentálását,

a

fenntarthatóság érdekében foganatosított intézkedések, „utóéletért” felelős funkciók és személyek kijelölése. − Az eredmények publikálása, a rendszer várható eredményeinek második lépcsős felvázolása, a hasznosulás társadalmi és pénzügyileg kifejezhető értékelése. − A szakaszt záró, összefoglaló dokumentációk elkészítése. 

A projekt zárása: összefoglaló dokumentációk elkészítése, a szükséges beszámolók, elszámolások lebonyolítása.

3.4.2 A feladatok időbeli ütemezése A projekt feladatai az előzőekben megfogalmazottak szerint hat fő szakaszba sorolhatóak be. A szakaszok becsült időtartama:

A

0. szakasz: Előkészítés

2 hét

1. szakasz: Implementációs tervezés

3 hét

2. szakasz: Programozás

3 hét

3. szakasz: Tesztelés, korrekciók

2 hét

4. szakasz: Üzemeltetés indítása, bevezetés

2 hét

5. szakasz: A projekt zárása

1 hét

szakaszok

és

az

azokon

belüli

részfeladatok

időigényét,

egymásutániságát, logikai rendjét az alábbi Gantt-táblázatban tüntettük fel.

illetve

4 MELLÉKLETEK 1. Projektötlet nyilvántartó adatlap 2. „Project Fiche” formátumú projektnyilvántartó adatlap 3. Regisztrációs

és

partnerközvetítést

támogató

klasztertagok számára 4. Pályázati Támogatások és hiteleszközök leltára

adatlap-javaslat

a