DÖNTÉSTÁMOGATÓ RENDSZER. Szerző: IQ ConsultinG Kft. Készült a MAT támogatásával, az FSzH közreműködésével, 2009-ben

A STRATOSZ és tagszervezetei véleményalkotási mechanizmusának áttekintése, a tagszervezeti felhatalmazás szakmai megalapozottságának javítása, a kommunikációs felületek új formáinak kialakítására vonatkozó modell kialakítása DÖNTÉSTÁMOGATÓ RENDSZER

Szerző: IQ ConsultinG Kft. Készült a MAT támogatásával, az FSzH közreműködésével, 2009-ben.

Tartalomjegyzék A STRATOSZ-RÓL RÖVIDEN ............................................................................... 3 A SZÖVETSÉG CÉLJA .......................................................................................... 8 A SZÖVETSÉG FELADATAI.................................................................................. 9 A SZERVEZET FELÉPÍTÉSE .............................................................................. 11 A VÉLEMÉNYALKOTÁS MENETE JELENLEG ÉS A LEHETSÉGES JAVÍTÁSI MÓDOK ................................................................................................................ 19 ELMÉLETI MEGKÖZELÍTÉS ..................................................................................... 20 A MINDENNAPI GYAKORLAT ................................................................................... 23 EGY DÖNTÉSTÁMOGATÓ SZÁMÍTÓGÉPES ALKALMAZÁS HATÁSA ............ 23 A RENDSZER MODELLJE .................................................................................. 28 A DÖNTÉSTÁMOGATÓ RENDSZEREKRŐL RÖVIDEN .................................... 29 A DTR SZEREPE A STRATOSZ VÉLEMÉNYALKOTÁSI MECHANIZMUSÁBAN ............................................................................................................................. 31 A MEGOSZTANDÓ INFORMÁCIÓK KÖRE......................................................... 34 A MODELL ÖSSZEFOGLALVA ........................................................................... 45 A MŰSZAKI MEGVALÓSÍTÁSRÓL...................................................................... 49 AZ EGYEDI DÖNTÉSTÁMOGATÓ RENDSZEREK ......................................................... 49 Architekturális és biztonsági kérdések .......................................................... 54 Biztonsági mentések ..................................................................................... 59 A HUMÁN OLDAL .................................................................................................. 62 ÖSSZEFOGLALÁS .............................................................................................. 63 MELLÉKLET.................................................................................................. 67 - 90

Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

2/90

A STRATOSZ-ról röviden A STRATOSZ a Stratégiai és Közszolgáltató Társaságok Országos Szövetsége. 1994-es alakulása óta feladata, hogy az ország gazdasági életében meghatározó szerepet játszó vállalatok képviseletét ellássa. 1999-ig nem volt tagja az Érdekegyeztető Tanácsnak, utána azonban már élvezhette a teljes jogú tagságból eredő előnyöket. Szintén ebben az évben történt, hogy a STRATOSZ közgyűlése új, modern alapszabályt fogadott el, amiben újraszabályozták a szervezet belső működési rendjét is. Ezután már az érdekegyeztetés mellett a tagvállalatok munkájának közvetlen, aktív támogatása is hangsúlyt kapott. A VOSZ-szal, vagyis a Vállalkozók és Munkáltatók Országos Szövetségével történő együttműködés nagyban növelte a működés hatékonyságát, a két szervezet tagként vesz részt a másik munkájában. A 2000-ben kezdődött együttműködés eredményeképpen közös székhely és az érdekképviseleti tevékenységet illetően napi szintű egyeztetés alakult ki. A STRATOSZ önmagában is jelentős súllyal rendelkező gazdasági szereplőket képvisel:

Nemzetgazdasági ág

%-os megoszlás

Közlekedés (általános)

6

Vasúti közlekedés

15

Légi közlekedés

1

Vízi közlekedés, vízellátás

1

Távközlés és informatika

20


3/90

Média (rádió és televízió)

6

Energia

6

Elektromosság

2

Közúti közlekedés

15

Mezőgazdaság

5

Posta

18

Önkormányzatok

5

Összesen

100

1. táblázat: A STRATOSZ nemzetgazdasági ágazatai Ha megnézzük, hogy a VOSZ tagsága milyen megoszlású, láthatjuk, hogy a két szervezet együtt még inkább jelentősnek mondható.

Nemzetgazdasági ág Mezőgazdasági, Vadgazdaság és Erdőgazdálkodás

%-os megoszlás 3

Halászat

1

Bányászat

1

Feldolgozó ipar

27

Villamosenergia-, gáz, hő- és vízellátás

2

Építőipar

16

Kereskedelem, járműjavítás

23

Szálláshely, szolgáltatás és vendéglátás

3

Szállítás, raktározás, posta és távközlés

3

Pénzügyi tevékenység

2


4/90

Ingatlan ügyek

9

Közigazgatás, védelem, kötelező TB

1

Oktatás

2

Egészségügyi és szociális ellátás

1

Egyéb közösségi, személyi szolgáltatás

3

Alkalmazottat foglalkoztató magánháztartás

1

Területen kívüli szervezetek és testületek

1

Nem volt megadva a belépéskor

1

Összesen

100

2. táblázat: A VOSZ nemzetgazdasági ágazatai

Természetesen a fenti adatokból az is következik, hogy a döntési vagy akár a véleményalkotási feladtok sok résztvevő összehangolását igénylik, ami nyilván nem zökkenőmentes. Ez különösen így van amiatt, hogy már az egyes tagszervezetek véleményalkotási mechanizmusa sem egységes, hiszen megannyi különböző felépítésű szervezetről van szó, más szervezeti kultúrával, más tulajdonosi és vezetőségi struktúrával. A STRATOSZ tagszervezetei és azok képviselői az alábbiak: cég neve

képviselő

tagsági forma

Agria Volán Zrt.

Kelemen Imre

rendes tag

Alba Volán Zrt.

Tóth István

elnök

Kamarás Miklós

elnökségi tag

Németh Ákos

képviselő

ÁPV Zrt.


5/90

Dr. László Géza

elnökségi tag

Dr. Bielek Péter

képviselő

Balaton Volán Zrt.

Csima László

rendes tag

Bakony Volán Zrt.

Bebesi István

rendes tag

BBKR INTER Kft

Rózsa Gyula

Antenna Hungária Rt.

BKV

Budapesti

Közlekedési

Zrt. Borsod Volán Személyszállítási Zrt. DERKON Vezetési és Tanácsadó Kft. DKV

Debreceni

Közlekedési

Zrt. Északdunántúli Vízmű Rt

ellenőrző

bizottság

elnöke

Antal Attila

rendes tag

Sárközi György

rendes tag

dr. Kovács Lajos

rendes tag

Nagy Attila

rendes tag

dr. Szikszai József

rendes tag

Németh Eszter

Hajdú Volán Zrt.

Zilahi-Sebes Géza

rendes tag

Hatvani Volán Zrt.

Úti Csaba

rendes tag

Hungarokombi Kft.

Tomcsányi István

rendes tag

JÁSZKUN VOLÁN Zrt.

Sziráki Pál

rendes tag

Kisalföld Volán Zrt.

Pócza Mihály

társelnök

Kőrös Volán Zrt.

Szarvas Péter

rendes tag

Kunság Volán Zrt.

Hunyady Szabolcs

rendes tag

Dr. Szabó Pál

rendes tag

Szűts Ildikó

elnökségi tag

dr. Rudi Zoltán

rendes tag

dr. Berényi János

rendes tag

Tóth Béla

rendes tag

Magyar Posta Zrt. Magyar Televízió Rt. Magyar

Vasúti

Fuvarozási

Egyesülés MÁTRA Volán Zrt. Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

6/90

MVK Miskolc Városi Közleke-

Börzsei Tibor

rendes tag

Nógrád Volán Zrt.

Antal Attila

rendes tag

Pannon Volán Zrt.

Balázs Dezső

rendes tag

Rekreációért Kft.

Görgicze Zoltán

rendes tag

Somló Volán Zrt.

Barta János

rendes tag

System Consulting Rt

dr. Kapolyi László

elnökségi tag

Szabolcs Volán Zrt.

Ignácz László

rendes tag

Tisza Volán Zrt.

Dr. Szeri István

rendes tag

Vasi Volán Zrt.

Tóth Andor

rendes tag

Vértes Volán Zrt.

dr. Horváth István

rendes tag

Volánbusz Zrt.

Pekli Ferenc

rendes tag

Zalatnai László

rendes tag

dési Zrt.

Zala Volán Zrt.

Kamondi János

ellenőrző

bizottság

tagja

3. táblázat: A STRATOSZ tagszervezetei A tagszervezetek listájából kiolvasható, hogy főleg részvénytársaságok adják a tagságot. Ezek jellegüknél fogva bizonyos mértékben meghatározzák a véleményalkotás formáját. Formailag a STRATOSZ felé a szervezet képviselője adja a szervezete véleményét, de természetesen a vélemény kialakításáért nem ő egy személyben a felelős. A részvénytársaságokban a közgyűlés felhatalmazása alapján a menedzsment hozza meg a döntéseket, amelynek szakmailag a felkért szakértők véleményére vagy a menedzsment tagjainak tapasztalatára van alapozva. A STRATOSZ céljai az alapszabálya szerint a következők:


7/90

A Szövetség célja

a./ Tagjai érdekeinek képviselete. Ezen túlmenően, mindazon szervezetek érdekeinek képviselete, melyek a Szövetség céljaival egyetértenek, és az Alapszabályt elfogadják. b./ Az érdekegyeztetés fórumain részvétel. A tagok munkáltatói és gazdasági érdekei képviseletének ellátása. c./ Kapcsolattartás a Szövetség céljainak elérése szempontjából fontos nemzetközi szervezetekkel, külföldi és nemzetközi munkaadói-gazdasági érdekképviseletekkel. Részvétel a nemzetközi érdekegyeztető fórumok tevékenységében. d./ Kapcsolattartás a szakszervezetekkel. A szociális partneri szerep ellátása. •

A Szövetség egyszerre lát el gazdasági érdekképviseleti és munkáltatói érdekképviseleti tevékenységet.

•

Tevékenysége a széleskörű nyilvánosságra épül, amelynek során a többségi vélemény érvényesítése mellett a kisebbségi vélemény kifejezését és képviseleti lehetőségeit is biztosítja.

•

A Szövetség célkitűzéseivel összhangban álló gazdasági tevékenységet is folytathat.

•

A Szövetség sem a múltban, sem a jövőben nem támogatott/nem támogat pártokat, parlamenti képviselőt.

•

A Szövetség tagként léphet be olyan magyar, vagy külföldi társadalmi szervezetbe, melynek célkitűzései a Szövetség célkitűzéseivel összeegyeztethetőek, feltéve, hogy a tagság a Szövetség célkitűzéseinek végrehajtását nem veszélyezteti.


8/90

A Szövetség feladatai

A Szövetség feladatai a Szervezeti és Működési Szabályzat (SZMSZ) szerint az alábbiak: A Szövetség érdekképviseleti, érdekközvetítő és érdekegyeztető, továbbá a külgazdasági kapcsolatok fejlesztését elősegítő tevékenységet lát el, az Alapszabály II. fejezetében foglaltak szerint. A Szövetség a feladatait országos hatáskörű szervezetként látja el A Szövetség az érdekképviseleti, érdekközvetítő és érdekegyeztető, továbbá a külgazdasági kapcsolatok fejlesztését elősegítő tevékenységét az egész országra kiterjedően a tagszervezeteket érintő valamennyi gazdasági - ágazati, szakmai területen kifejti, így ezen belül különösen: •

képviseli, közvetíti és egyezteti tagjainak érdekeit

•

az érdekegyeztetés fórumain való közvetlen részvétel formájában is,

•

a gazdasági közigazgatás területén, a köztestületi kamrákkal való kapcsolattartás, együttműködés és feladatmegosztás során,

•

a szociális partneri szerepkör ellátása révén, a szakszervezetekkel való együttműködés útján is,

•

más érdekképviseleti szervvel együttműködve a közös célok eléréséhez szükséges mélységben, akár közös szervezeti kereteken belül is,

•

a nemzetközi gazdasági, külgazdasági együttműködés területén, együttműködve a Szövetség számára fontos nemzetközi szervezetekkel, a külföldi és a nemzetközi munkaadói-gazdasági érdekegyeztető fórumokkal, a nemzetközi érdekegyeztető fórumok tevékenységében való részvétel útján is,

•

a európai uniós jogközelítés és jogharmonizáció munkálatai keretében,

a fentieken belül különösen a közigazgatás és a gazdasági élet alábbi területein: Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

9/90

•

a gazdaságpolitikai kormányzati előterjesztések, a beruházás-politika, gazdasági jogszabályok előkészítése ,

•

a koncesszió-köteles tevékenységek szabályozása,

•

a közbeszerzések rendjének szabályozása,

•

versenyjogi (kartelljogi, konszernjogi stb.) szabályozásban részvétel , valamint

•

információk közvetítése

•

a hitellehetőségekről,

•

a tőzsdei értesülésekről,

•

a területfejlesztésről, az infrastrukturális beruházásokról,

•

a beszállítói programokról,

•

a gazdasági, jogi kereskedelmi, műszaki tájékoztatás (dokumentációk, kiadványok kibocsátása, terjesztése), gazdasági-műszaki tájékoztató központok létesítése és működtetése,

•

a tagja közötti érdekellentétek kiegyenlítése (a „mediation”), az etikai tanácsadás és intézkedés,

•

a külföldi országok jogszabályi előírásai, ipari, kereskedelmi, műszaki szokásai, szokványai megismertetése körében.

Ahhoz, hogy a fenti célokat a STRATOSZ hatékonyan el tudja látni, mindenképpen szükséges lenne egy, a jelenleginél gördülékenyebb belső döntéshozatali mechanizmus kialakítása, mert a jelenlegi állapot szerint a kérdésekben a tagszervezetek véleményének összehangolása – ami a közös képviselet szempontjából elengedhetetlen – csak akadozva működik.


10/90

A szervezet felépítése

A STRATOSZ jelenleg az alapszabályban foglaltak alapján a döntésit az alábbiak szerint hozza: A szövetség szervei: 1. a Közgyűlés, 2. az Elnökség, 3. a Titkárság, 4. az Ellenőrző Bizottság. A szövetség tisztségviselői: az Elnök és Társelnökök, az Alelnökök, az Elnökség tagjai, az Ellenőrző Bizottság elnöke. Az ügyeket az Ügyvezető Igazgató intézi. A Közgyűlés A STRATOSZ közgyűlése fontos szerepet játszik, a véleményalkotás fontos színtere, a legfőbb döntéshozó szerv. Az Alapszabály szerint (1) A Közgyűlés a Szövetség legfelsőbb testületi szerve, mely a tagok összességének képviselete. (2) A Közgyűlés a Szövetség tagjainak képviseletre jogosult vezetőiből, vagy az azok által delegált képviselőkből áll, mely utóbbi esetben a képviseleti jogosultságot írásos, teljes bizonyító erejű magánokiratba foglalt meghatalmazással kell igaDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

11/90

zolni. A Közgyűlésen minden tagot egy fő képvisel, aki egyben szavazati joggal rendelkezik. Minden tag egy szavazati joggal rendelkezik. (3) A Közgyűlés a Szövetség legfőbb döntéshozó testülete, amely évente legalább egyszer ülésezik. A Közgyűlést össze kell hívni az Ellenőrző Bizottságnak, vagy az Elnökségnek, vagy a tagság 10 százalékának - ok és cél megjelölésével - tett indítványa alapján. A Közgyűlést a Szövetség Elnöksége hívja össze. A Közgyűlés meghívóját az ülés napja előtt legalább 8 nappal valamennyi tagnak, és a tisztségviselőknek írásban meg kell küldeni. A meghívó tartalmazza a Közgyűlés helyét, idejét, és napirendjét, melyet az Elnökség véglegesít. A Szövetség tagjai írásban, a közgyűlés időpontját legalább 3 nappal megelőzően a napirendhez javaslatokat tehetnek. (4) A Közgyűlés akkor határozatképes, ha azon a Szövetség tagjainak legalább 50 százaléka megjelent. Határozatképtelenség esetén az újra összehívott Közgyűlés a meghirdetett napirend tárgyában a megjelentek számától függetlenül határozatképes. (5) A Közgyűlés határozatait általában nyílt szavazással, egyszerű szótöbbséggel hozza. Titkosan kell szavazni, ha azt a Közgyűlésen jelen lévők legalább egyharmada az indokok megjelölésével kéri. (6) A Közgyűlés üléseit a Közgyűlés által megválasztott levezető Elnök vezeti. Személyére a Közgyűlésen az Elnökség felhatalmazása alapján az Ügyvezető Igazgató tesz javaslatot. A Közgyűlésről jegyzőkönyvet kell felvenni, melyet a levezető Elnök, két hitelesítő és a jegyzőkönyv-vezető ír alá. A jegyzőkönyv-vezető és a hitelesítők személyére a Közgyűlésen a levezető Elnök tesz javaslatot.


12/90

A jegyzőkönyv tartalmazza az adatokat, amelyekből a jelenlét és a határozatképesség megállapítható, a Közgyűlés napirendjét, a hozzászólások lényegét, a szavazás eredményét, és a határozatokat. A jegyzőkönyvet valamennyi tagnak, és a tisztségviselőknek meg kell küldeni. (7) Az Elnökség tagjainak 1/3-át és az Ellenőrző Bizottság tagjait delegáló tagszervezeteket a Közgyűlés egyszerű szótöbbséggel választja. Az Elnökség tagja nem lehet tagja az Ellenőrző Bizottságnak. (8) A tisztségviselőket delegáló tagszervezeteket a Közgyűlésen választják meg. Az Elnökség tesz javaslatot a jelöltekre, de ezen túlmenően a Közgyűlésen is lehet további jelölteket állítani . Az Elnökségi tagokat, és a Felügyelőbizottsági tagokat delegáló tagszervezetek azonosak nem lehetnek. A delegáló tagszervezetek haladéktalanul megnevezik az általuk delegált személyeket , és azokról a Közgyűlés név szerint szavaz. A tisztségviselők megbízása elfogadással jön létre. Ha a delegált tisztségviselő a megbízatást nem fogadja el, vagy a megbízás elfogadása után feladata ellátásában bármely okból akadályozatva lenne, úgy a delegálásra jogosult tagszervezet - fenti szabályok értelemszerű alkalmazásával - helyette más személyt jelöl. (9) Az Ellenőrző Bizottság tagjait delegáló tagszervezetek megválasztása szintén az 5.3 (8) pontban leírtak alapján történik. Az Elnököt a Bizottság tagjai az első Ellenőrző Bizottsági ülésen választják meg, melyet a Közgyűlés időpontjától számított 5 napon belül meg kell tartani. (10) A tisztségviselőkről a Titkárság készít nyilvántartást. (11) A jelenlevők szavazatának 2/3-os többsége szükséges a Szövetség Alapszabályának, illetve módosításának jóváhagyásához, más társadalmi szervezethez Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

13/90

való csatlakozáshoz, az abból való kilépéséhez, a Szövetség megszűnéséhez, a tag kizáráshoz.

(12) A Közgyűlés kizárólagos hatáskörében:

a.) meghatározza a Szövetség tevékenységének irányvonalát, b.) dönt a Szövetség Alapszabályáról és módosításáról, c.) jóváhagyja a tagdíjfizetés elveit és mértékét, d.) meghatározza az éves költségvetést, e.) elfogadja az Elnökség éves beszámolóját, f.) dönt a tisztségviselőket és az Ellenőrző Bizottság tagjait delegáló tagszervezetek határozott időre történő megválasztásáról és felmentéséről. g.) határoz mindazokban a kérdésekben, melyeket az Alapszabály a Közgyűlés hatáskörébe utal, vagy az Elnökség döntéshozatal végett eléterjeszt, h.) dönt a tag kizárására vonatkozó , indokolással ellátott javaslatról, a Szövetség más szervezetbe való belépéséről, más szervezettel való egyesüléséről, megszűnéséről.

Az elnökség A második fontos szerv az Elnökség. Az Alapszabály szerint (1) Az Elnökség a Szövetség Elnökéből, a Társelnökökből, az Alelnökökből, az Ügyvezető Igazgatóból és az Elnökség egyéb tagjaiból áll.


14/90

Az Elnökség tagjainak kétharmadát az Elnökségbe az elsőbbségi tagok három évre, de legfeljebb az elsőbbségi tagsági viszony időtartamára személyre szólóan delegálják. Az Elnökség tagjainak további egyharmadát a rendes tagok delegálják személyre szólóan három éves időtartamra. Az Elnökség tagjai közül egyszerű többséggel megválasztja az Elnököt, a Társelnököket , és az Alelnököket. Az elnöki , társelnöki és alelnöki funkcióban a tisztségre való jelölés elveként rotációs elv érvényesül amelynek szabályait az SzMSz-ben az Elnökség hagyja jóvá. A rotáció elve alapján a tisztségekre való jelölés sorrendisége meghatározott, amely csak a jelölt bármely okból történő kiesése folytán változhat úgy, hogy a tisztségre a mindenkori soron következőt kell jelölni. Az Alelnökök számát az Elnökség határozza meg. A delegált tagszervezetek első számú vezetői, illetve azok állandó megbízott képviselői lehetnek az Elnökség tagjai. A Szövetség Társelnöki tisztségeit a korábban a Szövetség elnöki tisztségét betöltő személyeknek kell felajánlani. Az Elnökségi tagsági viszony elfogadással jön létre. Az Elnökség tagjai tisztségükre – a fentiek értelemszerű figyelembevételével -újra delegálhatók. A tisztségviselők munkájukat társadalmi munkában végzik, más, a Szövetséghez hasonló célkitűzésű szervezetnél csak akkor, és addig vállalhatnak az Elnökség előzetes tájékoztatásával bármely tisztséget, amennyiben és ameddig az a Szövetség céljainak megvalósítását, és feladataik ellátását nem veszélyezteti. A tisztségviselők feladataik ellátása során a Szövetség érdekeinek védelmében a tőlük elvárható gondossággal kötelesek eljárni. (2) Az elsőbbségi tagsággal járó többletkötelezettséget vállaló tagszervezet azonnal jogosult az Elnökségbe tagot delegálni.


15/90

(3) Az Elnökség tagjainak változása vagy új tagokkal való kiegészítése esetén az új tagok megbízása az Elnökség eredeti megbízásának időpontjáig tart. (4) Az Elnökség pályázati úton kinevezi az Ügyvezető Igazgatót, és gyakorolja felette a munkaviszony létesítésével, megszüntetésével és a munkaszerződés módosításával kapcsolatos munkáltatói jogokat. (5) Az Elnökség dönt az új tagok felvételéről. Ha az Elnökség a tagfelvételi kérelmet elutasítja, úgy az érintett a soron következő Közgyűlés állásfoglalását kérheti. (6) Az Elnökség határozatait nyílt szavazással, egyszerű szótöbbséggel hozza. Szavazategyenlőség esetén az Elnök szavazata dönt. (7) Az Elnökség ülését az Elnök, vagy egy Társelnök - akadályoztatásuk esetén az Elnökség tagjaiból az Elnök által meghatalmazott személy - vezeti, aki az ülésen az Elnök jogaival rendelkezik. (8) Az Elnökség határozatképes, ha az ülésen az Elnökségi tagok legalább 50% + 1 fő jelen van. (9) Az Elnökség üléseiről jegyzőkönyvet kell készíteni, melyet az Elnökségi ülésen arra megválasztott Elnökségi tag hitelesít és az Elnök ír alá. (10) Az Elnökség szakmai bizottságokat hozhat létre, melynek vezetőit az Elnökség tagjaiból, illetve a Szövetség tagjai közül választja. (11)Az Elnökség a Közgyűlés számára írásban éves beszámolót készít tevékenységéről. (12) Eljárásának részletes szabályait az Elnökség ügyrendjében állapítja meg. Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

16/90

(13) Az Elnök, a Társelnökök, és az Alelnökök - az Alapszabályban meghatározott feladat- és hatáskörük keretei között, az Ügyvezető Igazgató pedig – az Alapszabályban meghatározott saját hatáskörben, valamint a tisztségviselők által átruházott jogkörben képviseli a Szövetséget kívülálló harmadik személyek felé, bíróságok és más hatóságok előtt. A titkárság (1) A Szövetséggel munkaviszonyban lévő, alkalmazottakból álló döntéselőkészítő, operatív végrehajtó szervezet, mely a Szövetség folyamatos működését hivatott biztosítani. (2) A Titkárság tevékenységéről köteles a Közgyűlésnek évente írásban beszámolni. (3) A Titkárság élén a Szövetséggel munkaviszonyban álló Ügyvezető Igazgató áll. (4) A Titkárság alkalmazottai felett a munkáltatói jogokat az Ügyvezető Igazgató gyakorolja. Tanulmányunk szempontjából az első pont a lényeges, vagyis a Titkárság döntéselőkészítő szerepe. Az Ellenőrző Bizottság Az Ellenőrző Bizottság a véleményalkotásban nem vesz részt, feladata a Szövetség pénzügyeinek ellenőrzése. Vizsgálatának eredményéről a Közgyűlésnek köteles évente beszámolni. Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

17/90

Az ügyintéző vezető Az Ügyvezető Igazgatót az Elnökség pályázati úton nevezi ki és gyakorolja felette a munkaviszony létesítésével, megszüntetésével és a munkaszerződés módosításával kapcsolatos munkáltatói jogokat. Az ezt meghaladó munkáltatói jogkört az Ügyvezető Igazgató felett az Elnök gyakorolja. Az Ügyvezető Igazgató a tevékenységét a Szövetséggel fennálló munkaviszony keretében látja el. Az Ügyvezető Igazgató a tevékenységét az Elnök teljes körű, folyamatos és eseti felügyelete alatt látja el. Az Ügyvezető Igazgató az Elnökség ülésein részt vesz, tevékenységéről az Elnökségnek évenként köteles beszámolni, az Elnök irányában pedig rendszeres tájékoztatási kötelezettség terheli. Az Ügyvezető Igazgató feladatköre: Szövetség napi ügyeinek vitele, a Szövetség képviselete feladat- és hatáskörének keretei között, és átruházott jogkörben a Közgyűlés, az Elnökség üléseinek, döntéseinek előkészítése, a döntések végrehajtásának megszervezése, a mindezekről teljesítendő beszámolás, a tagok Szövetségen belüli tevékenységének vezetése, szervezése, valamint a munkáltatói jogok gyakorlása a Titkárság alkalmazottai felett, a Szövetség gazdálkodásának, a szövetségi kifizetések utalványozásának irányítása; feladat- és hatáskörének keretei közötti, valamint átruházott jogkörben az Elnök által meghatározott értékhatáron belül, az Elnök teljes körű, folyamatos és eseti felügyelete mellett , •

a Szövetség nevében – feladat – és hatáskörén belül és átruházott jogkörében eljárva – a testületi álláspont képviselete.


18/90

Bizottságok A Szövetség Közgyűlése vagy Elnöksége által meghatározott rendeltetéssel létrehozott állandó, vagy ad hoc testületek (szövetségi testületek), melyek lehetnek : •

ágazati bizottságok (tagozatok)

•

szakmai bizottságok (tagozatok)

•

területi (regionális) bizottságok (tagozatok)

A véleményalkotás menete jelenleg és a lehetséges javítási módok

A tagszervezetek által delegált képviselők – az Alapszabály szerint – egy-egy szavazattal rendelkeznek. A különböző szervezetek által képviselt vélemények eltérése nem feltétlenül csak az adott szervezet többi szervezethez képest eltérő érdekeiből adódó különbségek miatt jelenik meg, hanem a nyilvánvalóan meglévő információs aszimmetriából következő különbségek következtében is. Mivel az eltérő érdekek nyilvánvalóan szerves és ki nem küszöbölhető részét képezik a való világ működésének, az információs aszimmetria miatt tökéletlenségekre kell koncentrálni, ha javítani kívánjuk a közösen kialakítandó vélemény szakmai megalapozottságát. Felmerülhet a kérdés, hogy miért nem működik a kezdetektől fogva hatékonyan és megalapozottan a véleményalkotási mechanizmus. Erre egy másik kérdés is lehet válasz, méghozzá az, hogy vajon biztos-e, hogy nem működik hatékonyan. Természetesen, mint más, emberek által üzemeltetett rendszerek, feltételezhetjük, hogy vannak hatékonysági tartalékok. Ezek a hiányosságok részben a nem megfelelő működésnek, az ad hoc folyamatoknak köszönhetők, de ugyanennyire je-


19/90

lentős a rossz beidegződések, megszokások, vagyis a szervezeti hagyományok szerepe. Ez utóbbiak a szervezeti viselkedés tehetetlenségét jelentik, és nagy a jelentőségük akkor, amikor valami újat akar bevezetni egy szervezet – nem feltétlenül a véleményalkotási mechanizmusok területén. A változásokat ugyanis sokan nem szeretik, mert felborítja az eddigi rutint. Vannak, akik ellenérdekeltek, vannak, akik pedig egyszerűen minden féle változástól irtóznak. Ezeknek a munkatársaknak a viselkedését kezelni kell, az új rendszerek bevezetésekor figyelembe kell venni. Fel kell készülni arra, hogy az ilyen viselkedés miatt a bevezetési folyamat várhatóan a tervezettnél akár lényegesen tovább fog tartani, vagy legalábbis intenzívebb munkát fog megkövetelni a bevezetőktől. Ezért is fontos, hogy a jelentős változások élére a menedzsment határozottan odaálljon. Enélkül ugyanis az ellenérdekeltek könnyen el fogják szabotálni az új módszereket, ami végül is a változási projekt kudarcát okozza, megannyi elvesztegetett idő, munka és pénz árán. Ez a helyzet a STRATOSZ szintjén bevezetett rendszerekkel is. Az elnökségnek meg kell mutatnia, hogy elkötelezett az új rendszer iránt, hogy az egyes tagszervezetek ne csak formálisan érezzék kötelezőnek a rendszer átvételét, bevezetését, mert valahol leírták, hanem mert látják, hogy ezt komolyan is gondolják az új rendszer mellett döntött vezetők.

Elméleti megközelítés

Mindenek előtt tisztában kell lennünk azzal, hogy milyen feltételei vannak egy megalapozott döntésnek – függetlenül attól, hogy mi a döntés tárgya és azt milyen szakterületen kell meghozni.


20/90

Egy szervezet döntéshozatali folyamatánál az alábbi körülmények léphetnek fel mint bemeneti változók: •

Az elérendő cél Tisztázni kell, hogy a felmerült döntési helyzetben hogyan értelmezi a szervezet a „jó” döntést. Meg kell határozni, hogy milyen kimenetelt vár el a szervezet a döntés eredményeképpen.

•

A szervezet stratégiai szintjén meglévő céloknak való megfelelés Meg kell határozni, hogy a célt hogyan kívánja elérni a szervezet. Egy döntés csak akkor lehet jó, ha a belőle következő eredmény nem mond ellent a szervezet stratégiájának.

•

A szervezet taktikai szintjén meglévő adottságoknak való megfelelés Meg kell határozni, hogy milyen lépesek megtétele szükséges ahhoz, hogy a meghatározott célt elérje a szervezet.

•

A szervezet működési szintjén meglévő adottságoknak való megfelelés A napi működés szintjére lebontva meg kell határozni, hogy a szervezet egyes szereplőinek mikor milyen feladatot kell ellátniuk.

A gyakorlatban persze nem olyan könnyű a fentiek alapján döntést hozni, mert ennyi információ nem elég. A saját szervezeten belüli döntés meghozatalához általában az alábbiak szükségesek: •

A jelenlegi helyzet pontos ismerete.

•

A status quo megtartásában érdekelt személyek, szervezetek azonosítása és ezek lobbierejének felmérése.

•

A különböző döntési alternatívák megvalósulása esetén bekövetkező változások miatt érintett személyek és folyamatok köre, az előrelátható mellékhatások felmérése és kezelése.

•

Terv az előre nem látható mellékhatások kezelésére.


21/90

•

Exitlehetőségek vizsgálata – ha később bebizonyosodik, hogy a döntés rossz volt, akkor van-e lehetőség valamilyen formában az eredeti állapot visszaállítására, illetve milyen más, potenciális megoldások jöhetnek szóba.

•

A döntés átfutási ideje.

•

A döntés meghozataláig rendelkezésre álló idő. Ha ez nem elég a fenti pontok vizsgálatához, akkor meg kell vizsgálni, hogy mi várható, ha nem hozzuk meg a döntést, és hogy van-e lehetőség a határidő eltolására

Mivel tudni lehet, hogy más szervezetek döntései is befolyásolják a végső, STRATOSZ által képviselt döntést, nem árthat, ha egy-egy tag megpróbál előre információkat szerezni a többiek várható viselkedéséről. Még mielőtt a problémát talán kicsit túlbonyolítva – vagy talán éppen hogy a valós körülményeket elhanyagolva – játékelméleti boncolgatásba kezdenénk, nézzünk csak meg néhány lehetőséget arra, hogy a többiek viselkedését megismerjük: •

Ha korábban felmerült hasonló döntési helyzet, akkor az akkori döntésük elemzése iránymutató lehet, figyelembe véve a közben esetlegesen megváltozott körülményeket.

•

Ha változott a másik szervezet célrendszere, menedzsmentje vagy akár tulajdonosi szerkezete, akkor lehet, hogy most más szempontrendszer alapján fogja meghozni a döntéseket.

•

Ha lehetséges, akkor a többi szervezet vezetőivel kapcsolatba lépve előzetes állásfoglalást lehet kérni tőlük.

•

A más szervezetek által ismert információkat – amennyiben nem titkosak – lehetőség szerint próbálja meg a többi tag is megismerni.


22/90

A mindennapi gyakorlat

Látható, hogy az információ megismerése és feldolgozása a kulcsa a megalapozott döntéshozatalnak minden felmerülő döntési körben. Ezen a problémán az informatika segítségével ma már elég hatékonyan lehet változtatni. Figyelembe véve, hogy a STRATOSZ tagszervezetei menedzsmentje egyrészt számos, másrészt elfoglalt emberből áll, aligha várható, hogy minden döntési helyzet előtt hosszas személyes vagy telefonos egyeztetést tartsanak. Marad tehát a probléma, hogy az amúgy rendelkezésre álló információk nem jutnak el azokra a szintekre, ahol a döntést meghozzák vagy a döntéselőkészítést végzik.

Egy döntéstámogató számítógépes alkalmazás hatása

Változtatna a helyzeten, ha rendelkezésre állna egy olyan eszköz, ami segít választ adni a fenti kérdésekre azáltal, hogy benne tárolva van az egyes szervezetek által hozott döntések eredménye és az ehhez felhasznált információknak a többi szervezet által megismerhető része. Az egyes szervezetek ugyanakkor használhatnák arra is a rendszert, hogy a nem publikus információkat szintén tárolják benne a többi szervezet számára nem, vagy csak korlátozottan hozzáférhető módon. A csak elektronikus megkülönböztetésen túl természetesen lehetőség lenne arra, hogy a közzétételtől megóvni kívánt anyagok tárolása, kezelése és feldolgozása a publikus információktól fizikailag is elkülönítve történjék. A rendszer alkalmas lehet arra is, hogy az egyes döntési alternatívák hatásait modellezze. Ehhez persze bonyolult feltételrendszerek leprogramozására van szükség, mint minden döntéstámogatási rendszer esetében, ezért általánosságban nehéz róla bármit is mondani naivitás lenne, részleteiben kifejtve pedig szerDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

23/90

vezetenként egy-egy tanulmányt érdemelne a téma. Azt mindenképpen le lehet szögezni, hogy az ilyen rendszerek használatával hatékonyabbá válik a döntéselőkészítés és a döntéshozatal. A másik vonulat a tagszervezetek közötti információáramlás elősegítése, annak rugalmassá tétele és mindenki számára átlátható és elfogadható folyamattá tétele. Az ideális helyzet az lenne, ha az egyes szervezetek a rendelkezésükre álló információkat, elsősorban azokat, amik a döntések vagy véleményalkotások szempontjából szakmailag relevánsak, a többi szervezet rendelkezésére bocsátanák. Ennek hatékony informatikai támogatása nem lehet probléma, az elképzelt működésről később lesz szó. Az efféle rendszerek alkalmazása azért is célravezető, mert segítségükkel sokszor az takarítható meg, ami a döntéshozóknak a legkevesebb van: az idő. Nincs szükség állandó egyeztetésekre, a munka a kezdeti nehézségek leküzdése után meglepően gördülékenyen haladhat. Természetesen nem lehet megspórolni minden személyes egyeztetést, mivel ezekre sokszor más miatt van szükség. A személyes egyeztetések szerepe a közös álláspont kialakítása utáni attitűd befolyásolásában továbbra is nagy szerepet kell, hogy játsszon. Ugyanakkor ezek az egyeztetések leginkább a véleményalkotási folyamat mérföldköveire korlátozódhatnak, ezzel felbecsülhetetlenül nagy szolgálatot téve az egyeztetésben részvevő felek számára. A számítógépes alkalmazások által biztosított adatokat elemezve ráadásul könynyen nyomon követhető a folyamat előrehaladása is. A fent említett mérföldkövek felállítása is azért fontos, hogy menet közben meg lehessen nézni, hogy az előre eltervezett sebességhez képest hogyan halad a munka. A projektek értékelésekor használatos mérőszámok akár egy véleményalkotási folyamat során is jól használhatók. Ugyanúgy lehetőség van a beavatkozásra is, hiszen bármikor újabb erőforrások rendelhetők a folyamathoz, vagy akár vonhatók el onnan. A feladat méreDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

24/90

te és a határidő is változtatható, ha erre van szükség. Amennyiben a megváltozott feltételeket szintén beviszik a rendszerbe, újra láthatóvá válik, hogy az új szempontok alapján hogyan változott meg a projekt egészének előrehaladása. Szintén fontos, hogy ne csak a szakmai érveket, azok feldolgozott változatát tegye közkinccsé egy szervezet, hanem azt a szempontrendszert is, ami alapján a szakmai anyagból a következtetéseket levonta. Mivel a különböző tagszervezetek eltérő gazdasági ágazatokban tevékenykednek, minden bizonnyal egy teljes konszenzust nehéz lenne elérni. Azonban ha a szervezetek nemcsak azt ismerhetik meg már előre, hogy a többiek milyen szempontokat vesznek figyelembe, hanem azt is, hogy ezeket milyen irányvonalak mentén dolgozzák fel, akkor jobban meg tudják érteni a többiek döntési mechanizmusát. Ez minden bizonnyal segíteni fog abban, hogy a saját döntésüket ne egy izolált szinten, hanem mint egy nagyobb rendszer szerves része hozzák meg. Lehetőség lenne a rendszeren keresztül a kommunikációkra is, az egyeztetésekre, a nem világos pontokra való rákérdezésre. Mindezt természetesen olyan formában kell megvalósítani, hogy maximálisan kiszolgálja a tagszervezetek elvárásait és meglévő munkastruktúrájukat. Arra kell törekedni, hogy menedzsment és a döntéselőkészítők is az adatok olyan körét lássák, ami őket a legjobban segíti. Míg a döntéstámogatási tevékenységben résztvevő munkatársak számára azok az adatok az elsődlegesen szükségesek, amik alapján az elemzéseket, következtetéseket el tudják végezni. A menedzsment számára már az információk, vagyis inkább a tudás olyan reprezentációjára van szükség, ami abban segíti őket, hogy minél gyorsabban képbe kerüljenek az egyes alternatívákat, azok hatásait, mellékhatásait, az erőforrás-szükségleteket illetően.


25/90

Ahhoz, hogy egy ilyen rendszert ki lehessen alakítani, mindenekelőtt a jelenlegi döntéshozatali folyamatokból kell kiindulni. Tagszervezetenként meg kell határozni, hogy milyen pontokon lehetséges és javasolt az átalakítás az optimalizálás céljából. Ha sikerül kialakítani egy olyan rendszert, ami az egyes tagszervezetekre vonatkozó speciális igényeken kívül ellátja a feladatokat, akkor ez egy nagyon jó kiindulási alap lenne egy közös döntéshozatali rendszer kifejlesztéséhez. A közös rendszer használata azért lenne előnyös, mert az egyes tagszervezetek döntéstámogatási rendszerével hatékonyan együtt tudna működni. Megvalósítható lenne, hogy a belső döntések publikus része automatikusan bekerüljön egy olyan adatbázisba, ami a többi szervezet számára felhasználható módon tartalmazná az információkat, vagy pontosabban a tudást. Azok a szervezetek, ahol még a folyamat a döntéselőkészítési fázisban van, megtehetnék, hogy a döntéselőkészítéssel megbízott munkatársaknak kiadják feladatul, hogy tanulmányozza a többi szervezet által felvetett szempontokat, értékelje őket a saját szervezet preferenciáinak szempontjából. Így lehetőség lenne arra, hogy egy olyan döntést tudjon hozni, ami nem csupán a szervezet által rutinszerűen alkalmazott döntési szempontokat veszi figyelembe, hanem azokat is felhasználja, amiket az akár teljesen eltérő szervezeti kultúrával és szempontrendszerrel dolgozó más tagok találtak ki vagy alkalmaznak szintén rutinszerűen. Ez az eljárás tulajdonképpen arra ad lehetőséget, hogy folyamatosan új ötletek szivároghassanak be a néha már megkövült szervezeti viselkedés kereteibe. Egy szervezet döntései gyakran azért nem jók, mert a megszokásokon alapulnak, még akkor is, ha közben a körülmények olyan mértékben változtak, hogy az mindenképpen a döntéshozatali, de gyakran a szervezet működési módjának egész, de legalábbis jelentős részét felölelő változást tenne szükségessé. Ez sajnos azért van így, mert a nagy szervezetek működésének jelentős a tehetetlensége, és ha valamiért nem feltétlenül szükséges, akkor a körülményekhez való adaptációt hajlamosak elhanyagolni, egész egyszerűen azért, mert az egyén szintjén – még akDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

26/90

kor is, ha ez a menedzsment tagjait érinti – nem jelenik meg semmi arra utaló tényező, hogy a folyamatok nem optimálisan zajlanak. Ezért sok esetben az ösztönzési rendszer tehető felelőssé, mivel nem tartalmaz olyan elemeket, amik a változás szükségességét közvetítenék a vezető felé. Ilyen ösztönzési elem lehet, ha a vállalat részvényárfolyamát a többi iparági szereplő részvényárfolyamához mérik. A mai magyarországi környezetben ez az út azonban nem járható, egyrészt azért, mert a tagszervezetek többsége nem tőzsdén jegyzett részvénytársaság, másrészt azért, mert éppen a tagszervezetek stratégiai voltából következően nem minden esetben mérhető pontosan a vállalat értéke alapján, hogy a működés optimális-e. Tőzsdén jegyzett társaságok esetében sem lenn járható ez az út mindig, szintén a stratégiai jelleg miatt. Elég a közelmúltban lezajlott MOL-OMV párharcra gondolni, aminek eredményeképpen fundamentálisan nem indokolt részvényárfolyamemelkedést figyelhettünk meg a MOL esetében. Természetesen ebből hiba lenne arra következtetni, hogy a MOL hirtelen jobban kezdett el működni vagy fogékonyabb lenne a változásokra, esetleg bármilyen szempontból hatékonyabban működne, mint ahogy a kicsivel később bekövetkezett árfolyamesésből sem következik ezek ellenkezője. Mindent összevetve valószínűleg hosszan fennmaradó tökéletlenségnek kell tartanunk azt, hogy a nagy szervezetek lassan, vagy egyáltalán nem akarnak adaptálódni a körülményekhez. Mivel a célunk azonban az, hogy növeljük a szervezetek és a STRATOSZ véleményalkotási mechanizmusának szakmai megalapozottságát, meg kell kísérelnünk egy olyan modellt kialakítani, ami ilyen körülmények között is képes arra, hogy legalább a szakmai szintekre eljuttatja azokat az információkat – legyenek


27/90

akár feldolgozottak vagy nyersek –, amik az egyes szervezeteken belül javítják a szakmai megalapozottságokat.

A rendszer modellje

A rendszer mindenképpen több szinten kell, hogy megtalálható legyen a STRATOSZ-ban. Ez azt jelenti, hogy egy olyan alkalmazásra van szükség, amely nemcsak a STRATOSZ véleményalkotási mechanizmusát támogatja, hanem megjelenik az egyes tagszervezetek szintjén is. Ennek egyik funkciója az, hogy segítse a helyi döntéseket, akár azokat is, amelyeknek semmi közük nincsen a vállalat STRATOSZ-beli szerepéhez vagy tagságához. Erre praktikus okokból van szükség, hiszen ha már implementálnak egy ilyen alkalmazást, akkor hiba lenne nem használni a helyi döntésekben. Egyrészt azért, mert ez erőforrás-pazarlás lenne, másrészt azért, mert a gyakori használata beviszi a menedzsment és a döntéselőkészítők napi rutinjába, hogy adott esetekben ennek a rendszernek a használata szükséges. Így nem kerülnek olyan helyzetbe, hogy amikor „éles” üzemben kellene használni, akkor nincs senki, aki tudná, hogy mit és hogyan lehet a rendszerben rögzíteni, illetve, hogy mit és hogyan érdemes. Azzal kapcsolatban is tapasztalatokat szerezhetnek, hogy milyen eredményt várhatnak el attól, hogy ezeket az információkat és tudásokat rögzítették. Kiindulásképpen meg kell határoznunk, hogy mit várunk el a rendszertől, és hogy az elvárásunk megvalósítása érdekében milyen információkat tudunk abba belevinni. Fontos tudni, hogy a rendelkezésre álló információk strukturáltak-e vagy sem. Erre a kérdésre az adott tagszervezetek esetében eltérő választ fogunk kapni. Erős egyszerűsítéssel élve strukturált adatnak nevezzük azokat az adathalmazo-


28/90

kat, amik rendezve vannak abból a szempontból, amelyikből fel alkarjuk őket dolgozni. Egy egyszerű példát hozva, gondoljunk arra az adathalmazra, amit a telekommunikációs szolgáltatók havonta a cégek rendelkezésére bocsátanak, vagyis a híváslistákra. Ez egy strukturált adathalmaz, egyértelműen megállapítható belőle, hogy ki, mikor, kivel és mennyit beszélt. Ez az adathalmaz arra tökéletesen elég, hogy a túl sokat mobilozó munkatársaknak kiszámlázza a cég a túlhasználatot, ami nyilván nem előnytelen a gazdálkodás szempontjából. Sok helyen nem gondolnak azonban arra, hogy ezt a strukturált adathalmazt abból a szempontból elemezzék, hogy melyik munkaterület munkatársai melyik másik munkaterületen dolgozó kollégákat hívtak fel egy-egy projekt időtartama alatt. Ehhez ugyanis olyan adatbázisra lenne szükség, ami a hívási adatokon kívül tartalmazza az egyéb információkat is, vagyis azt, hogy ki hol dolgozik, mi a munkája, milyen projektben vesz részt. Pontosan az a döntéstámogató (és adatbányász) rendszerek feladata, hogy az ilyen típusú kérdésekre választ adjanak, illetve, hogy megkeressék azokat az öszszefüggéseket, amikre a használó esetleg nem is gondol.

A döntéstámogató rendszerekről röviden 1

Mivel a döntéshozás folyamata számos eltérő gazdasági és tudományterületen vagy akár a napi teendők szintjén is értelmezett, valamint sokféle megközelítése létezik, a döntéstámogató rendszerek (DTR) koncepciója szintén sokrétű, megjelenésének több formája van. Általánosságban elmondhatjuk, hogy olyan rendszereket hívunk így, amelyek segítenek döntéseket hozni, vagyis előre definiált alternatívák között választani. Ezt úgy teszik meg, hogy különböző paraméterek segít1

A Mellékletben egy alternatív döntéselőkészítő rendszert mutatunk be


29/90

ségével (amik száma és jellege attól függ, hogy milyen területen akarunk támogatást a döntéseinkhez) kiszámítják az egyes alternatívák lehetséges hatásait, a választásuk következményeit. A számításhoz felhasználhatnak képelteket, amik vagy pontos eredményt adnak, vagy becsléseket. Minél pontosabb a becslés, annál inkább megbízható lesz természetesen maga a döntéstámogatás eredménye is. Általában számítógéppel végzett számításokat használnak fel a döntéstámogatáshoz, sőt, ha a különböző számítási elemeket egy rendszerbe integrálják, akkor beszélünk igazán számítógépes döntéstámogató rendszerről. Az igazi áttörést az hozta meg ezeknél a rendszereknél, hogy együtt tudnak működni az adatbányász szoftverekkel. Ebből az is látszik, hogy a DTR-ek nem mindig egy alkalmazást jelölnek, hanem egymással hatékonyan együttműködő alkalmazásokat. Ilyenek segítségével érhető el, hogy a korábban említett mobiltelefonszokásokat vizsgáló példát ismét elővéve, megállapítsuk, hogy egy-egy projekt alkalmával milyen változások történnek a munkatársak kommunikációs gyakorlatában. A sajátos feltételek miatt ezeket az alkalmazásokat, de különösen a központi magot mindenképpen az adott szervezet egyéni igényeire kell szabni, vagyis a szervezet működését tanulmányozva meg kell határozni az elemezendő területeket, a rendelkezésre álló információkat. El kell dönteni, hogy lehetséges-e a meglévő információk digitalizálása és strukturálása. Tisztázni kell, hogy milyen jellegű döntéseknél kívánjuk használni a rendszert, és hogy azzal milyen jellemzőkre nézve akarunk kimeneteket modellezni. Ilyen kimenet lesz minden bizonnyal az árbevétel és a profit, de lehet ilyen a vállalat által fizetett járulékok, a piaci pozíció alakulása is. Modellezhető például egy reklámkampány hatása a bevételre és az alkalmazottak létszámára.


30/90

Egy ma működő DTR például az alábbihoz hasonló képernyővel igyekszik kiszolgálni a menedzsment információéhségét. Látható, hogy az előrejelzéseken túl a vállalati mutatók értékei alapján riasztásokat is küld a felhasználónak. A feldolgozható adatok köre a minta szerint valamiféle értesítési tevékenységre enged következtetni, de ez természetesen nem jelenti azt, hogy ne lehetne ezeknek az adatoknak a körét jóval szélesebb területről származtatni. Egyszerűen csak arról van szó, hogy mivel a vállalatok életében ezek az adatok a legfontosabbak, a DTR-ek úgy vannak kitalálva, hogy ezt a területet maximálisan lefedjék.

1. ábra – Döntéstámogató rendszer mintaképernyője

A DTR szerepe a STRATOSZ véleményalkotási mechanizmusában

Joggal merül fel a kérdés, hogy miért lenne fontos, hogy a tagszervezetek ilyen rendszereket használjanak? Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

31/90

Ha sikerül egy-egy tagszervezetnél a saját döntéstámogató rendszert beüzemelni, akkor arra lehet számítani, hogy abban az esetben, ha sor kerül a tagszervezetek közötti együttműködés informatikai alapokra helyezésére, akkor ez gördülékenyen fog menni. Ennek azért nagy a valószínűsége, mert legalább a döntéseknél felhasznált információk más rendelkezésre állnak elektronikus formában és a felhasználók tapasztalatokkal rendelkeznek ilyen rendszerekkel kapcsolatban. Az elektronikus információtároláshoz ugyan nem lenne szükség a szervezetenkénti saját rendszerre, de a túlterheltség miatt valószínűleg hiú ábránd arra számítani, hogy majd a tagszervezetek digitalizálni fogják a saját tudásukat pusztán a közösség kedvéért. Ha ettől nem kell tartani, akkor természetesen erre nincsen szükség. A STRATOSZ szintjén lévő közös rendszer működése részben hasonlítana a tagszervezetek rendszereire, részben – speciális szerepe miatt – eltérne attól. A hasonlóságot az adja, hogy a STRATOSZ szintjén hozott döntések vagy vélemények hasonlóan keletkeznek ahhoz, mint egy szervezeten belül a saját vélemény vagy döntés. Mind a STRATOSZ mind a szervezetek ugyanis kisebb egységekből épülnek fel. A vállalatok esetében ezt az alábbi ábra szemlélteti:


32/90

2. ábra – Egy általános szervezet felépítése

Ha a STRATOSZ szintjét nézzük, akkor nagy a hasonlóság, hiszen itt is több tagszervezet építi fel a Szövetséget. Míg az egyes szervezetek esetében az alkotó egységek nem egyenrangúak, addig a STRATOSZ-ban a tagok egy szavazattal rendelkeznek, amit értelmezhetünk a modell egyszerűsítésének is. Bonyolítás azonban, hogy míg egy vállalat estében a vezérigazgató tudhat mindenről, addig a STRATOSZ-szintjén nincs olyan pozíció, amibe minden információ szabadon áramolhat, hiszen az egyes tagok a bizalmas információkat nem adják ki. Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

33/90

Egy olyan rendszer, ahol a tagszervezetek a saját belső alkalmazásaikban rögzítik döntéseik körülményeit, és egyben azt is megadhatják, hogy a Szövetség többi tagja ezekből az adatokból miket láthat, akkor jelentős mennyiségű addicionális ráfordítás nélkül megoldható lenne, hogy a közös döntésekhez szükséges információkat és tudásokat úgy osszák meg egymással, hogy azt a többi szervezet illetékesei hatékonyan fel tudják használni saját döntéseik megoldásához.

A megosztandó információk köre

Fontos, hogy élesen és jól átgondolva különítsük el a bizalmas információkat azoktól, amiket többi tagszervezet megismerhet. Az optimális eset az lenne, ha minden közös véleményalkotási tevékenység előtt lehetőség lenne megvizsgálni, hogy mely adatok, információk azok, amiket célszerű a többi tagszervezet számára elérhetővé tenni, hogy azokkal segítsük az információáramlást. Míg az esetek túlnyomó többségében elegendő, ha a vállalat a környezetére vonatkozó adatokat megosztja a tagtársakkal, néha azonban ezzel még nem érjük el a kívánt hatást. Azt ugyanakkor csak az adott döntési helyzetben lehet megmondani, hogy az adatok mely köre segíti a többieket. A szakmai megalapozottság szempontjából különös figyelmet érdemel a felkért szakértők véleményének megosztása. Ennek legegyszerűbb módja, ha magát a szakértői dokumentumot tesszük nyilvánossá. A rendszer funkcionalitását hasznosítva azonban ennél sokkal többet is tehetünk.


34/90

Nézzünk egy olyan esetet, amikor a tagszervezetek közül néhányan (legalább ketten) vagy maga a STRATOSZ felkér szakértőket, hogy segítse őket a felmerült döntési

helyzetben.

A

szakértők

a

munkájuk

eredményeképpen

a

döntéselőkészítők számára hasznosítható formában, valószínűleg papíron, de legalábbis szöveges dokumentumként fogják prezentálni az eredményt. A jelenlegi döntéshozatali mechanizmusban, ha meg is osztják egymással a szakértői anyagok tartalmát a tagszervezetek, a legritkább esetben teszik ezt úgy, hogy azt valamilyen előfeldolgozott formában teszik közzé. Így aztán minden érintett saját maga ugyan le tudja vonni a következtetéseket, de azt már nem tudja, hogy a többiek ugyanazzal az információhalmazzal mihez kezdtek. Emiatt pedig olyan ötletek, vagyis vizsgálati szempontok veszhetnek el, amik felhasználásával sokkal megalapozottabban tudnák az egyes szervezetek a megfelelő következtetéseket levonni saját maguk és akár a STRATOSZ egészére nézve is. Javasolt tehát az, hogy az elkészült szakértői anyagokat olyan munkatársak is elemezzék, vagy legalább is a belső szakértők munkáját olyanok egészítsék ki, akik értenek a számítástechnika efféle eszközeinek használatához. Arra lenne tehát szükség, hogy a levont következtetések keletkezési módját és magukat a következtetéseket úgy rögzítsék, hogy azok később felhasználhatóak legyenek a többiek számára. Egy ilyen folyamat eredménye az lenne, hogy néhány értékelés után már rendelkezésre állna például az, hogy egy adott tagszervezet, aminek adottak (és ismertek) a mérlegadatai, mely szempontok alapján vizsgálta az alternatívákat és az, hogy ezek a vizsgálatok milyen eredményt hoztak. Ezzel az információval nemcsak arra lenne lehetőség, hogy azokat a tagszervezeteket, amelyek később kezdenek neki az adatok elemzésének, már egy félig-meddig feldolgozott adathalmaz fogadja, hanem arra is, hogy az egyes döntéselőkészítők felhívják a korábbi


35/90

elemzők figyelmét az esetleges irracionális következtetésekre, vagy sokkal inkább a később felmerült vizsgálati szempontokra. Ezen a módon a sok szervezetből álló Szövetség hatékonyan meg tudná osztani a tagszervezeteivel a már rendelkezésre álló információkat, vagyis a jelenlegi módszerrel szemben, nem fordulna elő az, hogy egy-egy feladatot – tulajdonképpen a szakértői anyagok elemzését – többször is elvégeznék a különböző tagszervezetek döntéselőkészítői. Fontos kérdés, ezért nem engedhetjük meg magunknak, hogy a tanulmányban ne feszegessük, hogy vajon lehet-e kellőképpen ösztönözni az egyes tagszervezeteket arra, hogy a saját maguk által, nyilvánvalóan díjazásért elkészített anyagokat, amiket ráadásul további munkával még részben vagy egész fel is dolgoztak, a Szövetség rendelkezésére bocsássák. Valamilyen módon tehát érdekeltté kell tenni a tagszervezeteket abban, hogy a saját információjukat közkinccsé tegyék. Erre több módszer is lehetséges. Az információ a jellegénél fogva olyan jószág, amiből nem lesz kevesebb, ha az eredeti tulajdonos másnak átadja. Ennek ellenére gyakran megfigyelhető, hogy az emberek igyekszenek megtartani maguknak a tudásukat. Ez többnyire arra vezethető vissza, hogy tudásból származó előnyöket nem akarják más számára is elérhetővé tenni, hiszen ugyanettől esetleg veszít az eredeti tudásgazda a versenyelőnyéből. Sajnos néha akkor is megfigyelhető ez a tudásirigység, amikor arra nincs is semmilyen racionális magyarázat, hanem csupán a rossz beidegződések miatt zajlanak úgy az események, mint akkor, amikor valóban indokolt a tudás kisajátítása. A meglévő vélt vagy valós ellenérdekeket valamilyen módon meg kell próbálni ellensúlyozni vagy egyéb módon ellehetetleníteni. Ez utóbbit például akkor tudjuk megtenni, ha utasítási joggal rendelkező személyek a tudásgazdákat arra utasítDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

36/90

ják, hogy megosszák a tudást. Ez természetesen működhet egy vállalat esetében, ahol a céghierarchia miatt értelmezhető és létezik az utasítási jog, de nem működhet akkor, amikor egymással egyenrangú tagok által alkotott szövetségről beszélünk. Persze a szövetséghez való csatlakozáskor a tagok akár önként is vállalhatják, hogy azokat a tudáselemeket, amik érintik a többieket vagy amik a közös véleményalkotás folyamata során a szervezetükben keletkeznek, megosztják a közösséggel, de ennek a betartatása nehézségekbe ütközik. Ennek oka, hogy egy ilyen rendszer eleve bizalmatlanságot szül amiatt, hogy minden tag tisztában van azzal, hogy ha egy másik tag meg akar magának tartani egy információt, akkor azt meg is tudja tartani, hiszen ha másra nem, hát üzleti titokra tud hivatkozni, vagy akár az információ létét is el tudja titkolni. Az egyetlen jó megoldás az, ha sikerül valamilyen módon érdekeltté tenni a feleket az információ megosztásában. Ennek lehet az a módja, hogy minden egyes, a közös tudástárba bevitt információ után valamilyen bónuszt kap a tagszervezet, vagy a Szövetség valamilyen módon kompenzálja, akár anyagilag. Ez persze fel veti azt a kérdést, hogy lehet-e minden információt anyagilag értékelni. Ha igen, akkor nincs probléma, de a valóságban vannak olyan esetek, amikor a pénzbeli érték vagy egyáltalán nem, vagy csak nem egyértelműen határozható meg. Ezekben az esetekben azt is mérlegelni kell, hogy ne kerüljünk olyan helyzetbe, amikor az információ értékelése bizonyosan több befektetést igényel, mint magának az információnak az értéke. Ha ez nem is következik be, akkor is viták forrása lehet az információ értéke. Az egyszerűség kedvéért éljünk a feltételezéssel, hogy sikerül megtalálni annak a módját, hogy a tagszervezetek a döntéselőkészítésük során felhasznált tudásokat megosszák a többiekkel, vagyis feltételezzük, hogy a szakértői anyagokat és az


37/90

azokból levonható primer információkat hajlandóak elérhetővé tenni a többi tagszervezet számára. Felmerül a kérdés, hogy milyen formában történjen ez a megosztás. Az erre a kérdésre adandó válasz függ attól, hogy sikerül-e rávenni a tagszervezeteket arra, hogy a döntéseiknél valamiféle döntéstámogató rendszert használjanak. Ha igen, akkor feltételezhetjük, hogy az információk nagy része rendelkezésre áll digitálisan. Ha nincs a tagszervezeteknél ilyen rendszer használatban, akkor – mivel a központi rendszer a hatékonyság és a szervezetek nagy száma miatt mindenképpen elektronikus – szükség van a felhasználandó tudások digitalizálására. Ez történhet úgy, hogy az elkészített szakmai anyagokat szkennelés vagy diktálás útján digitalizálják, de ideális esetben az anyag amúgy is rendelkezésre állhat elektronikus formában. A feladat legfontosabb része azonban nem is ez, hanem az, hogy a döntéselőkészítés során figyelembe vett szempontokat és a levont következtetéseket tegyék strukturális digitális formában elérhetővé. Ha az egyes tagszerveztek szintjén sikerült megoldani, hogy ne csak a hajlandóság, hanem az eszközrendszer is meglegyen a tudásmegosztásra, akkor tisztázni kell, hogy a STRATOSZ szintjén milyen struktúrában lenne célszerű ezeknek az adatoknak a megjelenítése. Vagyis el kell dönteni, hogy a közös rendszerbe milyen szempontok alapján kerüljön be egy-egy adat. Ez azért érdekes, mert ahogy arról már korábban volt szó, az adatok némelyike bizalmas, némelyike publikus, némelyik azonban tulajdonképpen átmenti, mert lehet, hogy bizonyos adatok megváltoztatásával, ahol maguk a változtatások viszont nem befolyásolják az információ értékét már publikussá tehetők. Az alábbi jellemzői lehetnek egy-egy szakértői anyagon alapuló tudásnak:


38/90

Általános jellemző: •

a tudás gazdája

•

mely véleményalkotási vagy döntési feladattal kapcsolatok az anyag

•

mikor aktuális az adott döntési vagy véleményalkotási feladat

•

a döntés vagy véleményalkotás milyen fázisban van a tagszervezetben jelenleg

•

mikorra tervezi a tagszervezet a folyamat lezárását

A dokumentum jellemzői: •

a szakértői anyag címe

•

a szakértői anyag készítője

•

a szakértői anyag elkészítésének ideje

•

a szakértői anyag elkészítésének célja

•

a tudásgazda a szakértői anyagot csak belső felhasználásra készítette, vagy eleve azzal a céllal, hogy a STRATOSZ-beli véleményalkotásban segítse

•

a tudásgazda a szakértői anyagot már feldolgozta-e

•

a feldolgozás során alkalmazott szempontok megnevezése

•

az egyes szempontok alapján alkotott vélemények ismertetése

•

az értékelési szempontok összessége alapján kialakított vélemény ismertetése

•

hasznosnak ítéli-e a tudásgazda a tanulmányt a STRATOSZ többi tagja számára

Külső körülményekkel kapcsolatos elemek: Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

39/90

•

milyen említésre méltó külső körülmények álltak fenn a következtetések levonásakor

•

várható-e, hogy ezek a körülmények megszűnnek

•

van-e olyan még be nem következett esemény, ami a következtetések érvényességét alapjaiban megváltoztatja

•

mekkora ezeknek az eseményeknek a valószínűsége

•

mikor várható ezen események bekövetkezése

•

van-e módunk befolyásolni ezen események bekövetkezését

•

érdemes-e megpróbálni befolyásolni ezen események bekövetkezését, vagyis a ráfordítások és a haszon arányban állnak-e egymással

•

mi a módja annak, hogy ezen események bekövetkezését befolyásoljuk

•

rendelkezésre áll-e a befolyásoláshoz szükséges erőforrás

•

ha ez nem áll rendelkezésünkre, akkor beszerezhető-e

•

mennyi időt vesz igénybe a beszerzése

•

milyen vezetői döntések meghozatalára van ehhez szükség

•

vannak-e pozitív mellékhatásai annak, ha befolyásoljuk a körülményeket

•

vannak-e negatív mellékhatásai annak, ha befolyásoljuk a körülményeket

•

a fentiek ismeretében érdemes-e megpróbálni befolyásolni a körülményeket

Ha nem szakértői anyag értékeléséről van szó, hanem belső adatok, információk felhasználásával kialakított véleményről, akkor is értelmezhető egy, a fentihez hasonló felsorolás. A fenti információkat azért kell strukturáltan tárolni, mert a többi tagszervezet számára a sok adat közötti eligazodást segíti majd ez a fajta elrendezés. Hogy a strukturáltságot megtartsuk, mindenképpen meg kell fontolni, hogy egyes adatokat szabadon, míg másokat egy adott halmazból választhasson ki a felhasználó. Vagyis míg a szakértői anyag címe nyilvánvalóan szabadon kitölthető kell, hogy Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

40/90

legyen, addig az arra vonatkozó információt, hogy a STRATOSZ szintjén mely véleményalkotási feladathoz tartozik a tudás, egy előre definiált halmazból kell kiválasztani. Ezt úgy kell elképzelni, hogy akkor, amikor egy véleményalkotási feladat felmerül, akkor a központi rendszert kezelő adminisztrátor bővíti az eddigi halmazt az éppen aktuálissal. Erre azért van szükség, mert ellenkező esetben előfordulhatna, hogy a szabad szövegmegadási lehetőség miatt ugyanazt a témát két tagszervezet egy-egy munkatársa más néven vinné be a rendszerbe. Ez a keresést tenné hosszú távon lehetetlenné, hiszen amikor a korábbi témák számossága már eléri azt a szintet, hogy nem lehet egy pillantással átlátni a halmazt, akkor fontos, hogy egy téma ne szerepeljen két címen, még akkor sem, ha az eltérés valójában csak egy névelő. Ha a fenti feltételek teljesülnek, akkor rendkívül hatékonyan megoldható a már más tagszervezetek által feldolgozott anyagok megosztása. Ehhez csupán arra van szükség, hogy annak a vállalatnak a döntéselőkészítője, ahol éppen most kezdenek neki foglalkozni az aktuális kérdéssel, belépjen a központi rendszerbe, ahol az azonosítás után – aminek során természetesen az is egyértelmű lesz, hogy melyik tagszervezet munkatársa az illető – láthatóvá válnak számára az éppen aktuálisan futó véleményalkotási feladatok. Egy-egy feladat lapja a rendszerben külön kis oldalt képez, ahol meg lehet nézni, hogy az adott témában eddig mely szervezetek milyen adatokat töltöttek fel. Elkülönített formában, például mappákba szervezve lenne célszerű mutatni az egyes szakértői anyagokat és az azokhoz tartó egyéb információkat, például a feldolgozásuk során keletkezett egyéb tudásokat vagy magukat az egyes szempontok alapján meghozott következtetéseket. A felhasználó mindezt úgy látná, hogy egyből az is nyilvánvalóvá válik, hogy melyik másik tagszervezet alkotta a véleményt. Az egyéni mérlegelésre van bízva, hogy ebből milyen következtetéseket von le a döntéselőkészítő, de feltételezhetDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

41/90

jük, hogy annak tudatában, hogy egy hasonló méretű, akár hasonló gazdasági ágazatban tevékenykedő cég milyen szempontokat vett figyelembe, jó eséllyel minden döntéselőkészítőben felmerül a hasonló szempontok vizsgálata. A látható adatok körét szintén meghatározhatja a belépett felhasználó személye. Erre azért van szükség, mert lehet az adatoknak olyan köre, amit bizalmas voltuk miatt csak egy adott beosztási szint feletti munkatársak láthatnak, más tagszervezetek munkatársai pedig egyáltalán nem. Szükség esetén ezt lehet még úgy is finomítani, hogy néhány adat csak akkor látszódik, amikor éppen aktuális, vagyis miután meghozták a döntést, illetve megalkották a STRATOSZ-szintű véleményt, ezek az adatok eltűnnek. Ezzel a módszerrel azonban érdemes óvatosan bánni, mert ha indokolatlanul használjuk ezt a funkciót, akkor az lehet, hogy azt fogja okozni, hogy az egyébként feleslegesen titkosított adatok felhasználásának lehetetlensége miatt olyan következtetéseket nem fogunk tudni levonni, amik pedig feltétlenül szükségesek lennének egy másik döntési vagy véleményalkotási folyamat során. Hogy megelőzzük a túlzásba vitt adattitkosítás mellékhatásait, érdemes lenne előre szabályozni, hogy milyen elvek alapján történjenek a rendszer használat során a hozzáférések korlátozásai. Meg kell határozni, hogy •

egy adott tagszervezetnél ki jogosult a tudások osztályozására, vagyis ki dönti el, hogy mi az, ami bizalmas és mi az, ami nem

•

az egyes szervezetek hol kívánják meghúzni a bizalmas információk körét, vagyis mik azok az információk, amiket semmiképpen nem adna ki a kezéből a STRATOSZ többi tagszervezete részére

•

a nem a fenti körbe tartozó információk közül melyek azok, amik minden részlettel együtt kikerülhetnek a közös rendszerbe


42/90

•

melyek azok az információk, amik csak szűrve kerülhetnek ki a közös rendszerbe, például úgy, hogy azt nem kívánja a cég nyilvánosságra hozni, hogy ki a szakértő, vagy akár azt sem, hogy melyik szervezetről van szó

•

melyek azok az adatok, amelyekkel kapcsolatban helye van az időszakos hozzáférésnek, vagyis amelyeket egy adott időintervallum után, például a véleményalkotási fázis lezárultával kíván titkosítani

•

melyek azok az adatok, amelyeket csak bizonyos beosztású emberek láthatnak

•

titkos adatok esetén melyek azok a tagszervezetek, amelyek mégis láthatják az adott információt

•

milyen egyéb, egyedi feltételek vannak, amik befolyásolják az információ láthatóságát

A legutolsó pont természetesen rengeteg feltételt jelenthet, amiket csak tagszervezet-specifikusan lehet meghatározni, de még valószínűbb, hogy még attól is függ, hogy éppen milyen területen kell döntést hozni vagy vélemény alkotni. Mivel ez azt is jelenti, hogy ezek a feltételek egyediek és speciálisak lesznek, valószínűleg nem kerülhet sor arra, hogy a közös rendszerben strukturáltan megjelenjenek. Erre azonban talán nincs is feltétlenül szükség, hiszen a többi döntéshozó munkáját az nem nehezíti, ha nem tudja, hogy miért nem látható egy információ, vagy miért csak szűrten látható, elég ha magát az eredményt látja. A pontos szabályozásra mégis azért van szükség, hogy legyen egy olyan szabályrendszer, ami alapján el lehet dönteni, hogy egy adott információ végül melyik kategóriába esik, és ez a szabályrendszer lehetőleg viszonylag objektív legyen. Ha tehát eljutottunk oda, hogy tisztázódott, ki, mit és mikor láthat, akkor feltételezve a döntéshozók racionális viselkedését abba a problémába fogunk belefutni, hogy minden tagszervezet igyekszik a lehető legkésőbb elkezdeni a saját véleméDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

43/90

nyének a kialakítását, hiszen minél tovább vár, annál több másik tagszervezet által megvizsgált véleményt láthat a közös kommunikációs rendszerben, vagyis annál kevesebb hozzáadott értéket kell neki produkálnia. Ezért nemcsak arra van szükség, hogy arra ösztönözzük a szervezeteket, hogy megosszák tudásukat, hanem arra is kell őket ösztönöznünk, hogy ne tanúsítsanak potyautas magatartást. Hiszen gyakorlatilag a közös kommunikációs rendszer erre nagyon jó alkalmat teremt, ha azt vesszük, hogy a közös rendszerben jelen levő tudások tulajdonképpen közjavak. A közjavakkal kapcsolatos legfontosabb piaci kudarc pedig a potyautas magatartás, amikor is a fogyasztó igyekszik a lehető legalacsonyabb szinten tartani a közjószág előállításában való részvételét. Ezt a valójában az önzésből eredő emberi tulajdonságot nagyon nehéz kordában tartani. A mi esetünkben talán csak az lenne az egyetlen járható út, hogy folyamatosan figyelemmel kísérjük az egyes tagszervezetek viselkedését, és ha sorozatosan azt tapasztaljuk, hogy visszaél a lehetőségekkel vagyis potyautas-magatartást tanúsít, akkor valamilyen szankció életbe léptetését kell a fontolóra venni. Az is megfelelő eljárás lehetne, hogy a tagszervezetek rotációs rendszerben kijelölik, hogy milyen sorrendben kell az egyes tagszervezeteknek az elemző munkában részt venniük, vagyis mindig más lenne az, aki a potyautas-magatartás előnyeit elvehetné. Természetesen ezt a rendszert alaposan meg kell tervezni, hiszen a döntési helyzetek nem alkotnak homogén halmazt, vannak nehezebb és vannak könnyebb helyzetek, legyen szó akár döntésről, akár véleményalkotásról. Mérlegelni kell, hogy egy adott szervezet milyen típusú elemzéseket tud elvégezni, van-e az adott időben kapacitása az elemzésre, és egyáltalán érintett-e a problémában olyan szinten, hogy kell neki véleményt alkotnia. Mivel a tagszervezetek sokféle gazdasági területen tevékenykednek, előfordulhat, hogy a rotációs rendszer miatt olyan területen való véleményalkotást várnánk el egy szervezettől, ami Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

44/90

számára nem is releváns, így a kierőszakolt vélemény várhatóan szakmailag megalapozatlan lesz. Egy véleményalkotási fázis indításakor tehát célszerű lenne először azt eldönteni, hogy mely szervezetek azok, amelyektől az elsődleges véleményeket várjuk. Ennek eldöntése természetesen önmagában sem egyszerű, hiszen nem minden esetben várható, hogy tagszervezetek önként fognak ajánlkozni a szerepre. Ezt a problémát a korábban említett ösztönzési rendszer kialakításakor lenne célszerű figyelembe venni.

A modell összefoglalva A közös vélemény kialakítására vonatkozó modell tehát a következő főbb lépésekből áll: A STRATOSZ szintjén elvégzendő lépések: •

Annak eldöntése, hogy szükség van-e szakértői anyagokra.

•

Annak a tagszervezetnek a kiválasztása, amelyik a leghatékonyabban tudja elkészíttetni és elemezni a szakértői anyagot. Ez természetesen lehet maga a STRATOSZ is.

•

A rendelkezésre álló idő meghatározása.

Az elsődleges elemzést végző szervezet által elvégzendő lépések: •

a szakértőnek átadandó anyagok halmazának meghatározása

•

a szakértő kiválasztása

•

a szakértőnek a szükséges adatok átadása

•

a szakértői anyag értékelési szempontjainak meghatározása

•

a szakértői anyag értékelése a különböző szempontok alapján


45/90

•

az esetlegesen szükséges adattitkosítási eljárások meghatározása (vagyis annak eldöntése, hogy az információkat teljesen publikusan, részben publikusan, azaz szűrve, vagy teljesen bizalmasan kezeljük)

•

annak vizsgálat, hogy nem túlzott-e az elhatározott titkosítási szint

•

a titkosítási eljárások alkalmazása

•

az így előállt tudás megosztása a többi tagszervezettel a közös rendszerbe való felvitel segítségével

Ezek a lépések érvényesek akkor is, ha nem csak egy, hanem több szervezet is készíttet szakértői tanulmányt. A többi szervezet által elvégzendő lépések: •

Annak vizsgálata, hogy az adott szervezet számára fontos-e saját vélemény kialakítása. Ez nem feltétlenül szükséges ugyanis, hiszen az eltérő tevékenységek miatt bizonyos kérdésekben egy adott szervezet esetleg nem kíván véleményt alkotni.

•

A közös rendszerből a témával kapcsolatos eddigi szakértői anyagok kinyerése.

•

Annak vizsgálata, hogy az elsődleges véleményalkotók milyen szempontok alapján milyen következtetéseket vontak le.

•

Ezen következtetések szakmai szempontból való vizsgálata. Ha a szervezet nem tart szakmailag kellőképpen megalapozottnak egy következtetést, akkor ezt valamilyen formában jelezheti a következtetést levonók felé. Ez praktikusan szintén a közös rendszeren keresztül történhet, méghozzá annak megjelölésével, hogy melyik következetést és milyen szempontból tartják megalapozatlannak.

•

A mások által felvetett szempontok alapján megpróbálni a saját szervezet szempontjából releváns következtetéseket levonni.


46/90

•

Ezeket a következetéseket szintén bevinni a közös rendszerbe, hogy mások is láthassák.

A folyamat itt azonban még nem érhet véget, hiszen a visszacsatolásokat le kell még kezelni. Ezért rendszeres időközönként újra és újra be kell néznie a rendszerbe azoknak a tagszervezeteknek is, vagyis azok döntéselőkészítőinek, amelyek már megtették a szükséges lépéseket. Erre azért van szükség, hogy értékeljék a visszajelzéseket, valamint hogy új ötleteket merítsenek: •

a többi tagszervezet által adott visszajelzések értékelése

•

a saját álláspont megvédése vagy felülvizsgálata

•

a többi elsőrendű értékelő szempontjainak vizsgálata

•

a nem elsőrendű értékelő tagszervezetek szempontjainak vizsgálata

•

a fentiek alapján az új szempontok figyelembevételével a vélemény finomítása vagy teljes felülvizsgálata

És természetesen most sem maradhat el a többi tagszervezet számára adandó esetleges visszajelzés •

a többiek szempontjainak szakmai megalapozottságának vizsgálata a korábban ismertetett módon

A fenti folyamatot addig kell ismételni, amíg •

minden szervezet kialakította a véleményét, vagy pedig megállapította, hogy nincs szükség véleményalkotásra


47/90

•

nem marad olyan szempont és következetés, amit szakmailag vitatna egy másik tagszervezet, vagy legalábbis nem marad olyan, amit az eredeti ötletgazda ne védett volna meg

•

sikerül valamilyen konszenzusos véleményt alkotni STRATOSZ-szinten

Ha a folyamat lezárul, akkor eljutottunk oda, hogy egy olyan véleményt sikerült formálni, ami legalább a tagok többségének szempontrendszerét tükrözi. Ez a vélemény már alkalmas lehet arra, hogy a társadalmi egyeztetéseken úgy tálalják, mint a STRATOSZ tagszervezeteinek véleményét. A szakmai megalapozottság biztosításához természetesen nem elég néhány eljárási és technikai szabály betartása. A megalapozott véleményhez megbízható bementi információkra és jó információfeldolgozásra van szükség. Ezek biztosítása nem könnyen oldható meg egy szabályrendszer alapján, mert rengeteg szubjektív elem is helyet kell, hogy kapjon a folyamatban. Emiatt az egész folyamatértékelés szubjektív lesz. Vagyis nem mondható meg teljesen egyértelműen, hogy egy adott vélemény szakmailag megalapozott-e, mivel még ha sikerül is a bemeneti információknak egy olyan tág halmazát a szakértő rendelkezésére bocsátani, ami vitathatatlanul kielégíti a teljességre vonatkozó kritériumot, akkor sem lesz vitathatatlan a szakértő hozzáértése. Még pártatlan hozzáállást feltételezve is könynyen meglehet, hogy van az adott szakmában egy legalább annyira megbecsült másik szaktekintély, akinek a véleménye talán éppen ellentétes a számunkra munkát végző kollégájával. Ezek a szempontok azonban csak a körülmények gondos mérlegelése után, egyedi döntéseken keresztül rendezhető megnyugtatóan, általánosságban legfeljebb irányelvek határozhatók meg. Ilyen irányelv például, hogy a szakértő felkeresése előtt tájékozódjunk a szakterültet ismerőktől vagy az irodalomból, hogy milyen iskolák léteznek az adott területen, ezek közül melyik mennyire számít a Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

48/90

mainstreambe, vagy inkább csak relatíve kevesek által támogatott elveket valló alternatív irányzat-e. Ha megismerjük ezeket a szempontokat, akkor van esélyünk arra, hogy nem azt a szakértőt bízzuk meg a munkával, aki éppen ráér, vagy aki az ára alapján a legjobbnak tűnik, hanem azt, aki számunkra a legértékesebb munkát fogja végezni, méghozzá olyat, amivel a szakértőt felkérő szervezet is azonosulni tud. Tulajdonképpen azt mondhatjuk, hogy a szakértő felkérése már önmagában egy szakértőt igénylő munka. Ez így egy körkörös logikai formula is lehetne, amit nyilvánvalóan nem lehet egyszerűen feloldani, vagyis értelmetlennek tűnhet. Valamilyen szinten azonban mégis fontos ezzel foglalkozni, hiszen ha nem tesszük, akkor előfordulhat, hogy gyakorlatilag alig járunk jobban, mintha véletlenszerű véleményt alkottunk volna – csak ezt az eredményt sokkal drágábban sikerült elérni.

A műszaki megvalósításról

A rendszer megvalósítása internet-alapú kommunikációs technológia felhasználásával történhet. Meg kell vizsgálni az alkalmazandó technológiát, a kommunikációs csatornát, a biztonsági kockázatokat, a megvalósítás időigényét és költségvonzatát.

Az egyedi döntéstámogató rendszerek Ahogy korábban láthattuk, a zökkenőmentes működés egyik feltétele az, hogy a tagszervezetek rendelkezzenek belső rendszerrel, ahol az adatokat tárolják. Erre ugyan nincs feltétlenül szükség a központi rendszer működése szempontjából, de mivel az enélkül való megvalósítás sok többletmunkát ró a tagszervezetek döntéselőkészítő munkatársaira, mindenképpen érdemes a megfontolása. Az elvárások ezekkel a belső rendszerekkel kapcsolatban: Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

49/90

•

könnyű kezelhetőség

•

integrálódjon a vállalat meglévő rendszereibe

•

hatékonyság a döntéstámogatásban

•

képes legyen a strukturálatlan adatok közötti kapcsolatok felismerésére, vagyis alkalmas legyen adatbányász funkciók ellátására

•

a központi rendszerrel gördülékenyen működjön együtt

•

beszerzése ne jelentsen nagy anyagi terhet a vállalat számára

•

használata nem vessen fel biztonsági kockázatokat

•

lehetőleg távolról is elérhető legyen

A fentiek közül talán a legkényesebb kérdés a jelenlegi rendszerekkel való együttműködés biztosítása. Erre hatékony megoldást adni azonban minden esetben a vállalat jelenleg használt rendszereinek ismeretében lehet, ezért általános esetben nem vizsgálható a probléma, csak egyedileg. A minimális elvárás azonban az, hogy a meglévő adatbázisokkal tudjon együttműködni, az alkalmazások kezelőfelületével tulajdonképpen nem szükségszerű a kompatibilitás. A döntéstámogatásbeni hatékonyságot illetően szintén egyedi vizsgálatokra van szükség, mivel ezt befolyásolja a feldolgozni kívánt adatok jellege. A központi rendszerrel való együttműködési képesség nyilvánvalóan kritikus a STRATOSZ szempontjából, mivel enélkül az egész modell megvalósíthatósága sérülhet. Ennek nem mond ellent, ha egy tagszervezet mégis amellett dönt, hogy nem kíván egyedi döntéstámogató rendszert üzembe helyezni. Az anyagi vonzatot illetően az adhat reményt, hogy ha egyszerre több tagszervezet is megrendel hasonló alkalmazást, akkor jelentős diszkontra tehetnek szert,


50/90

mivel a különbözőségek mellett jelentős mennyiségű közös vonás is lesz a rendszerekben, ami megkönnyíti a szállító dolgát. A biztonsági kérdésekben a vállalat többi rendszerénél alkalmazottak az irányadók. Ha a rendszert integrálják a jelenlegiekkel, akkor ezzel biztosan nem lesz probléma, hacsak nem vezetnek be rá külön szabályokat.

A központi rendszer A központi rendszer tulajdonképpen az információ és a tudások megosztására szolgál. Mivel ez jellegénél fogva nem egy belső rendszer, az elvárt tulajdonságai sem pontosan azonosak a belső, döntéstámogató rendszerekéivel. Nézzük, itt mi a fontos: •

illetéktelen hozzáférések megakadályozása

•

a belső DTR-ekből az adatok automatikus lehívása

•

könnyű adminisztráció, hogy az új véleményalkotási feladatokat egyszerű legyen rögzíteni

•

internetes elérhetőség, mivel valahol kell lennie egy központi adattárolónak, nem lehet minden tagszervezetnek saját másolata az összes adatról, vagy legalábbis ez felesleges technológiai problémákat okozna

•

felhasználóbarát kezelőfelület

•

lehetőség a véleményalkotási feladatok logikusan strukturált felépítésére, vagyis könnyű legyen megtalálni, amit a felhasználó keres

•

különböző keresési szempontok implementálása a bevitt információhalmazon o kulcsszavak o időintervallum o az információt publikáló szervezet neve o az információ jellege


51/90

szöveges tanulmány

értékelési szempont

következetések

szöveges kiegészítések

o az információ bizalmasságának foka o keresés szövegminta egyezés alapján •

platformfüggetlen megvalósítás

•

a rendszer rugalmas felépítése, hogy az esetleges változtatási kérelmeket könnyen át lehessen vezetni a rendszerbe

•

rendelkezésre álljon a felhasználói dokumentáció minden tagszervezetnél

•

legyen egy központi segélyszám, amin valaki tud segíteni a felhasználóknak, ha elakadnak. Erre főleg a használat első szakaszában lehet szükség.

A központi rendszer esetében nagyon fontos a megfelelő informatikai biztonság megteremtése. Ennek vannak jól körülhatárolható technikai és kevésbé jól kézben tartható emberi vonatkozásai is.

Technikai megvalósítás

A technikai oldalról vizsgálva a biztonsági kérdéseket, az alábbiakat kell figyelembe vennünk: •

adatforgalom titkosítása o https használata web alapú alkalmazás esetén o kliensprogram használata o VPN használata mindegyik esetben

•

hozzáférések korlátozása o jelszóval o hardverkulccsal


52/90

o a kettő kombinációjával o esetleg csak adott számítógépekről való elérése legyen engedélyezett •

hozzáférési kísérletek naplózása

•

adott számú meghiúsult hozzáférési kísérlet után a hozzáférés letiltása adott időre vagy akár addig, amíg az adminisztrátor kézzel nem engedélyezi az újbóli próbálkozásokat

•

szigorú jelszóházirend használata

•

a hozzáférések időbeli korlátozása

•

az egyidejű felhasználók számának korlátozása (ez inkább teljesítménybeli mint biztonsági kérdés)

•

a kiosztandó szerepkörök gondos megtervezése és személyekhez rendelése

•

az adatok rendszeres mentése

Az emberi oldallal kapcsolatban az alábbiak fontosak: •

a megtervezett biztonsági szabályok betartatása o az emberek meggyőzése arról, hogy fontosak a biztonsági kérdések o felvilágosítás a helyes biztonsági eljárások betartási módjairól, vagyis lépésről lépére megmutatni, hogy mit hogyan és miért tegyenek a rendszer használat során

•

annak megakadályozása, hogy az egyes felhasználók egymás jelszavát használják

•

a jelszavak titkosságának megőrzésére való ösztönzés

Ezekre a kérdésekre azért fontos odafigyelni, mert hiába a legprofesszionálisabban megtervezett rendszerbiztonság, ha az emberi tényező a lehető legmeglepőbb módokon teszi azt semmissé. Elég arra gondolnunk, hogy az emberek hajDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

53/90

lamosak a jelszavukat a monitorra ragasztani, vagy otthagyni a számítógépet, miközben fut a biztonságosnak szánt alkalmazás.

Architekturális és biztonsági kérdések

Nézzük az egyes műszaki lehetőségeket, hiszen a részletek ismerete nélkül nem lehet megalapozott döntést hozni. Nyilvánvalóan internet-alapú alkalmazásra van szükség, mert az egyes felhasználók fizikailag távoli helyszínekről kívánnak belépni a rendszerbe. Ez azt feltételezi, hogy van valahol egy központi szerver, ami az adatok tárolását és a központi alkalmazás kiszolgálását végzi. Ezzel kapcsolatban csak arra kell figyelni, hogy a szerver stabil elérhetősége és a fizikai biztonsága biztosított legyen. Mindkét feltétel teljesül, ha egy korszerű szerverhotel szolgáltatásait vesszük igénybe. A következő kérdés, amit tisztázni kell, az az, hogy web alapú rendszert vagy úgynevezett szerver-kliens alkalmazást akarunk-e használni. Vannak ugyan átmenetek a mai technológia szintjén, de nézzük a két végletet: •

web-alapú rendszerek

•

saját kliensprogramot használó alkalmazások

A web alapú rendszerek esetében a felhasználóknak csak egy internetböngészővel kell rendelkezniük, minden adatot a központi szerver tárol, és minden adatfeldolgozási műveletet ő végez. Ennek a megoldásnak az az előnye, hogy nem kell külön kliensprogram, viszont ha fontos a hálózaton forgalmazott adatok mennyisége, vagy nagyok sok az adatokkal helyben végzendő művelet, akkor ez nem a legtakarékosabb megoldás. Rugalmassága azonban jelentős, hiszen ha a szükDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

54/90

ség úgy hozza, akkor akár egy internetkávézóból is be lehet lépni vele az alkalmazásba. Nincs továbbá, vagy legalábbis csak nagyon ritkán szükség annak előírására, hogy a felhasználók milyen operációs rendszert használjanak. Saját kliensprogram használata esetén a helyi számítógépre először telepíteni kell a kliensprogramot, majd ezt a szerveren lévő kiszolgáló alkalmazással össze kell kapcsolni a hálózat segítségével. Számolni kell a negatív oldalon a telepítési nehézségekkel, az inkompatibilitásokkal, ha nem az ideális operációs rendszert használja a felhasználó. Előny azonban, hogy az egész rendszer a szervert csak a szükséges mértékben terheli, és nem generál felesleges adatforgalmat, ami részben a biztonsági kockázatokat is csökkenti. Sokkal szofisztikáltabb megjelenési formát lehet a kliensprogrammal teremteni, bár a mai modern eszközökkel ez a különbség már kezd elmosódni. A két véglet között olyan megoldásokat találunk, amik a web alapú elérést egészítik ki olyan módon, hogy adatfeldolgozás egy része a helyi gépen történik, vagy hogy a helyi gép eszközeit aktívan használják (lemezmeghajtó, modem stb.) A tanulmány tárgyát képező rendszer esetében ilyen megoldásokra azonban várhatóan nem lesz szükség. Bármelyik megoldást is választjuk, mindenképpen szükség van arra, hogy a helyi számítógép és a szerver közötti adatokat titkosítsuk, vagyis olyan formában utaztassuk az interneten, hogy az mások számára ne legyen lehallgatható. A különböző titkosítási algoritmusokra nyilván nem lenne értelme kitérni, a lényeg, hogy webes alkalmazás esetén hasznos a https használata, valamint akár webes, akár kliensprogramos infrastruktúrát választunk, a kapcsolatot lehetőleg VPN, vagyis virtuális magánhálózat használatával építsük fel. Ez gyakorlatilag egy olyan csatornát képez a két számítógép (a felhasználó számítógépe és a szerver között), amiben az adatcsomagok egyfajta biztonsági csomagolásban utaznak, ami lehe-


55/90

tetlenné teszi a lehallgatást, még akkor is, ha valaki meg tudja szerezni az egész adatfolyamot. A VPN kapcsolatok működését az alábbi ábra szemlélteti.

3. ábra – VPN A VPN korszerű technológiának tekinthető, bár ebből is létezik kevésbé biztonságos változat. Hátránya, hogy sokszor komoly konfigurálási feladatot ad a vállalati hálózatot üzemeltető rendszergazdáknak, de ha minden jól be van állítva, akkor gördülékenyen működik. A jelszavas hozzáférés lényegét senkinek nem kell bemutatni, a szigorú jelszóházirend azonban nem olyan közismert. Itt arról van szó, hogy nem engedjük meg a felhasználóknak, hogy olyan jelszavakat használjanak, amelyeket nagyon könnyű próbálgatással kitalálni. A leggyakrabban használt jelszavak ugyanis általában értelmes szavak, jobb esetben egy vagy két számmal az elejükön vagy a végükön. Éppen emiatt a rosszindulatú támadók vagy a támadóprogramok azt csinálják, hogy először szótárak segítségével próbálgatják a jelszavakat, csak az után próDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

56/90

bálkoznak meg a véletlenszerű karakterek használatával. Tovább tudjuk nehezíteni a támadók dolgát, ha a jelszavunkban kis és nagybetűket is használunk, vagy ha speciális karaktereket teszünk bele. Az ember számára természetesen nagyon nehéz egy bonyolult és emaitt értelmetlen jelszó megjegyzése, ezért ha tehetik, akkor a felhasználók igyekeznek az egyszerűbb jelszavakat használni. A szigorú jelszóházirend azt jelenti, hogy nem engedünk olyan jelszavakat használni, amik nem felelnek meg a bonyolultsági kritériumainknak. Valójában létezik olyan megoldás, ami ugyan szokatlan, de mégis mindenkinek, vagyis a felhasználónak és a rendszerbiztonságnak is jó. Ez pedig a jelszavak helyett a jelmondatok használata. Itt arra gondoljunk, hogy a jelszó lehet például az, hogy „Tavasz szél vizet áraszt.” Ebben a jelszóban van kis és nagybetű is, van írásjel is, tehát megfelel a bonyolultsági kritériumoknak, és még csak azt sem mondhatjuk, hogy nehéz lenne megjegyezni. A próbálgatásos módszer ellenszere az is, ha bizonyos számú hibás próbálkozás után letiltjuk az adott felhasználót. Hasonló az eljárás ahhoz, mint amikor a mobiltelefon PIN-kódját hibázza el az ember egymásután háromszor. Ekkor a telefon letilt, és vár egy másik, hosszabb kódot. A mi esetünkben is erről van szó, csak nem egy hosszabb kódot vár a rendszer, hanem például azt, hogy elteljen egy bizonyos idő, vagy hogy egy adminisztrátor újra aktiválja a hozzáférési lehetőséget. Az időzár azért jó megoldás, mert ha minden harmadik rossz próbálkozás után kell várni egy percet, akkor a néhány milliárd lehetőség végigzongorázása nyilván beláthatatlanul sokáig tartana (több, mint ezer évig), vagyis gyakorlatilag ellehetetleníti ezt a támadási módszert. A jelszavas védelem kiegészíthető úgynevezett hardverkulccsal is. Ez azt jelenti, hogy nem elég egy jelszó ismerete a belépéshez, hanem valamilyen fizikai eszközt is csatlakoztatni kell a számítógéphez. Ez lehet egy USB-eszköz, egy kódkártya, vagy egy floppy-lemez. Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

57/90

Ehhez technológiailag hasonló, ha a felhasználót biometrikus adataival is azonosítjuk. Itt lehet szó ujjlenyomat-olvasóról, de akár írisz- vagy hangfelismerő rendszerről is. Ezek persze bonyolultabb eszközök, bevetésük előtt mérlegelni kell, hogy az adatok vannak-e annyira érzékenyek, hogy megérje őket ezeken a módokon védeni. Röviden tekintsük át a különböző megoldásokat! Az íriszvizsgálat során a szem íriszét azonosítja össze a rendszer a tárolt adatokkal. A vizsgálat egyszerű, a felhasználónak gyakorlatilag csak bele kell néznie egy eszközbe. A szkennelést mutatja a 4. ábra.

4. ábra – Íriszvizsgálat Az ujjlenyomat-olvasó olcsóbb berendezés, azonban egyes vélemények szerint sokkal kevésbé megbízható. Előnye viszont, hogy a mai számítógépek gyakran már gyárilag beépített ujjlenyomat-olvasót tartalmaznak. A hozzáférések időbeli korlátozása akkor lehet hasznos, ha attól tart a titokgazda, hogy az egyébként hozzáféréssel rendelkező felhasználók akkor, amikor senki nem látja őket, tehát például munkaidőn kívül, olyan célokra használják a rendDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

58/90

szert, amire nem lenne szabad. Természetesen figyelni kell arra, hogy nehogy ezzel a valóban szorgalmas munkatársak számára tegyük lehetetlenné a munkavégzést. Technikailag megoldható, hogy az alkalmazást csak bizonyos számítógépekről lehessen elérni. Ez fokozza a biztonságot, azonban csökkenti a rugalmasságot. Nemcsak azt nehezíti meg, hogy például egy internetkávézóból elérjük a rendszert, hanem azt is megakadályozza, hogy egy engedélyezett számítógép meghibásodása esetén egyszerűen odébb üljön a felhasználó, és egy másik gépről folytassa a munkát. A fenti védekezési módokat mindenképpen ki kell egészíteni azzal, hogy naplózzuk a belépéseket. Részletesebben naplózni kell, hogy ki, mikor honnan jelentkezett be, és hogy milyen adatokat töltött fel vagy le, továbbá milyen egyéb akciókat végzett: felhasználók hozzáadása, módosítása vagy törlése, jelszavak megváltoztatása, jogosultsági beállítások változtatása, naplózási beállítások változtatása. Ezek az adatok nemcsak az illetéktelen hozzáférések azonosításában lehetnek segítségünkre, hanem arra is lehetőséget adnak, hogy elemezzük az egyes felhasználók aktivitását, a rendszer teljesítményét, vagy akármilyen egyéb célra használjuk fel ezeket az adatokat. Fontos, hogy a naplófájlokat ne lehessen kézzel módosítani vagy törölni, hiszen akkor éppen az agyafúrtabb, rosszakaratú támadókat nem tudnánk megtalálni.

Biztonsági mentések

Nemcsak a támadások miatt, hanem akár műszaki meghibásodás miatt, vagy emberi hibából kifolyólag is sérülhet a szerveren tárolt adatállomány. Ilyen esetekben Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

59/90

segít, ha rendelkezésre áll egy biztonsági mentés. Ilyen mentést célszerű rendszeresen készíteni, és a szervertől függetlenül tárolni. Kezdő felhasználók gyakori hibája, hogy a mentési file-okat ugyanarra a merevlemezre mentik, vagy ugyan másikra, mint ahol az adatok eredetileg voltak, de olyan lemezre, ami szintén az adott számítógépben van. Ez azért nem tanácsos, mert ha a szerver meghibásodik, például a tápellátás hibájából az alkatrészek túlfeszültséget kapnak, akkor jó eséllyel mindegyik adattároló sérülni fog, az adatok pedig elvesznek. Az sem túlságosan biztonságos megoldás, ha az adatokat CD-re írjuk és a gép közelében, ugyanabban a helyiségben tároljuk, mert egy esetleges tűz esetén így is oda lesz minden adat. A legjobb megoldás, ha a mentéseket az adatok származási helyétől fizikailag elkülönítve tároljuk. Szintén fontos szempont, hogy az adatokat milyen rendszerességgel mentjük. Ezt természetesen nagyban meghatározza az, hogy az adatok milyen ütemben keletkeznek, íródnak a rendszerbe. Ha naponta várható újabb adat, akkor elég naponta vagy kétnaponta, de ha folyamatos a használat, akkor akár egy napi többszöri mentés is indokolt lehet. Az is szempont, hogy a mentéseket milyen sokáig őrizzük meg. Azért jobb hoszszabb időre eltenni a mentéseket, mert ha például egy dokumentumot szándékosan letöröltek, és ez csak egy héttel később szúr szemet valakinek, akkor ha nincs meg az egy héttel korábbi mentés, akkor bizony már nem lesz lehetőség az adatok visszaállítására. El kell továbbá dönteni, hogy milyen mentési módot választunk. Ez azért érdekes, mert meg kell találni az egyensúly a biztonsági szint és az erőforrásigény között. Az alábbi főbb módozatok közül választhatunk:


60/90

•

teljes mentés

•

csak a változás mentése

Természetesen ezeket lehet finomítani például olyan módon, hogy megjelöljük a rendszer számára, hogy melyek a már mentett file-ok, és azokat csak változás után mentjük, még akkor is, ha egyébként teljes mentést végzünk. A teljes mentés a legbiztonságosabb, azonban ez igényli a legtöbb erőforrást is. Ez igaz mind a tárhely, mint az idő szempontjából. A tárolt dokumentumok ugyanis az idő előrehaladtával olyan jelentős méretet is elérhetnek a tároló lemezeken, amekkorára előre nem is számított senki. A nagy mennyiségű adat másolása pedig sok időbe telhet, különösen, ha megfogadjuk az arra vonatkozó tanácsot, hogy a másolatot az eredetitől fizikailag távol, vagyis gyakorlatilag egy másik számítógépen tároljuk, ami azt követeli meg, hogy az adatokat a hálózaton utaztassuk. Ez persze felveti újra a biztonsági kérdéseket is, de itt is a korábban leírtak az irányadók. A különbségi mentéssel az a probléma, hogy ugyan hatékony sok szempontból, de ha arra kerül a sor, hogy teljesen vissza kell állítani az adatokat, mert például a tároló megsemmisült, akkor akár több száz változásmentést kell újra betölteni, hogy megkapjuk az egy nappal korábbi állapotot. Ez pedig azt követeli meg, hogy nagyon sokáig tároljuk a mentéseket. Célszerű tehát valamilyen kevert megoldást keresni. Valamilyen rendszerességgel készítsünk teljes mentéseket, gyakrabban pedig különbségi mentéseket. Tehát például végezzük hetente teljes mentést, és naponta különbségit. Így legrosszabb esetben is csak hét mentést kell betöltenünk, ha visszaállításra kerül sor.


61/90

A humán oldal

Az emberi oldalról való megközelítés sokkal komplikáltabb. A felhasználókkal meg kell értetni, hogy a biztonsági eljárások nem az ő életük megkeserítése miatt vannak, hanem éppen az ő érdekükben. Tanácsos oktatásokat tartani, ahol megmutatják számukra a célszerű eljárásokat, azt, hogy egy-egy adott szabályozás milyen veszélyektől óvja meg őket és az egész rendszert. Ha sikerül rávenni őket a szabályokkal való azonosulásra, akkor sokkal könnyebb dolgunk lesz a szabályok betartatásakor is. A leggyakoribb, hogy a felhasználók megmondják egymásnak a jelszavukat, mert például az egyikük elfelejtette, és nem akarják, hogy emiatt késedelmet szenvedjen a munka. Ez a látszólag jóindulatú eljárás azonban rengeteg veszélyt rejt magába, még akkor is, ha egyébként mindkét résztvevő jóindulatú. Gondoljunk csak arra, hogy a közelben levő illetéktelen harmadik személy meghallhatja a jelszót, vagy hogy esetleg a második személy felírja ezt a jelszót, hiszen már a sajátját sem tudta megjegyezni. Ez az eljárás a biztonsági kockázatokon túl azonban a naplófájlok használhatóságát is megkérdőjelezi, hiszen így azok téves információkat fognak tartalmazni a felhasználók kilétéről, amiből természetesen csak téves következtetéseket lehet levonni. A másik gyakori hiba a jelszó papírra való felírása. Ez ellen hatékonyan lehet védekezni a korábban említett jelmondat-szerű jelszavak használatával. Erre mindenképpen fel kell hívni a felhasználók figyelmét. Gyakran azért nem kerül sor ezeknek az eszköznek a használatára, mert egyszerűen nem jut az érintettek eszébe.


62/90

A biometrikus adatok felhasználása ellen sokan tiltakoznak, mert aggasztja őket, hogy ujjlenyomatukat a cégük tárolja. Számukra megnyugtató lehet olyan eljárások használata, amik nem az egész ujjlenyomatot tárolják, hanem annak csak apró részleteit, így arra nincs mód, hogy az ujjlenyomattal visszaéljenek, ellenben az azonosításra elég ez is. Ha még így is idegenkednek az eljárástól, akkor arra kell őket rávenni, hogy ne tekintsék tehernek a távoli eléréshez használatos hardverkulcs használatát. Ez ugyanis egy apró eszköz, amit a felhasználónak magánál kell tartania, tehát szintén kényelmetlenséget tud okozni, mert például a felhasználó elveszti, vagy egyszerűen csak elfelejti, hogy hova tette.

Összefoglalás

Minden bizonnyal szükség van a mostani eljárásrend modernizálására, megfelelve a kor és a technológiai kihívásainak. A fentiekben vázolt kétszintű rendszer nem csupán az eredeti célt tudja ellátni, hanem alkalmas arra is, hogy az egyes tagszervezetek belső folyamatait segítse. Ezáltal olyan eszközt kapnak a tagszervezetek, ami a mindennapi működésük során is jól használható. Ha ezt ki is használják, akkor ennek egy pozitív mellékhatása, hogy azokban a véleményalkotási helyzetekben, amikor a többi tagszervezettel együttműködve a közös tudások alapján kell közös véleményt alkotni, már nem egy új rendszerrel találkoznának a döntéselőkészítők, hanem egy legalább nagyjából ismert rendszerrel. Kézenfekvő, hogy kor szellemének megfelelően egy olyan rendszert használjunk, ami a központi szervert az internet segítségével köti össze a tagszervezetek döntéselőkészítői és szakértői által használt számítógépekkel. Létezik olyan megoldás, ami a szerver elérésére kliensprogramot használ, de talán egyszerűbb


63/90

olyan rendszer készítése, ahol a felhasználóknak csak egy böngészőprogramra van szükségük. A biztonsági kérdéseket illetően is többféle megoldás kínálkozik. Ezek némelyike használ fizikai azonosítókat, némelyik csak jelszót vagy jelszavakat. A döntést, hogy melyik megoldást választjuk, az adatok értékének, bizalmasságuk mértékének, a szükséges erőforrásoknak és az emberi tényezőknek a mérlegelése után lehet meghozni. A rendszer kétszintű, mert a központi szerver a STRATOSZ szintjén lévő véleményalkotási feladatok segítéséért felelős, míg a tagszervezetek saját rendszerei azon kívül, hogy a központi alkalmazást ellátják adatokkal, az adott szervezet számára belső döntések meghozatalában is segédkeznek. Természetesen az adatok keveredése megelőzhető. Vagyis nem kell attól tartani, hogy olyan információ is kikerül a tagszervezetből a közös rendszerbe, aminek nem lenne szabad. Ha bizonyos tagszervezetek anyagi vagy más okokból nem kívánnak saját belső rendszert működtetni, akkor ezt természetesen megtehetik, így első lépésként valószínűleg kisebb anyagi ráfordítással tudnak csatlakozni a rendszerhez, de több időt kell szentelniük a központi rendszerrel való munkára és az adminisztrációs feladatok ellátására. Erre azért van szükség, mert a központi rendszer adatokkal való feltöltése az adott tagszervezet részéről nem lesz automatizálható. Ha a szervezet később meggondolja magát, akkor később is tud saját rendszert üzembe helyezni, de ennek utólagos integrálása a már meglévők közé lehet, hogy nagyobb ráfordítást fog igényelni, mintha már a központi rendszer valamint a többi tagszervezet saját rendszereinek kialakításával egy időben üzembe helyezték volna azt. A kétszintű megoldás védelmet nyújt bizonyos adatvesztési kockázatokkal szemben is, mivel a központi szerverről, lévén hogy csak egy darab van, könnyen kéDöntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

64/90

szíthető biztonsági másolat, aminek a tárolását is szakszerűen el lehet látni. Nem kell továbbá a tagszervezeteknek felelősséget vállalniuk a működtetésért, mert egy szerverhotelben elhelyezve a kiszolgáló számítógépet, napi 24 órás szakértői felügyelet alatt lehet tartani, vagyis a rendelkezésre állási paraméterek nagyon magas szinten tarthatóak, amire egy rendszeres használat esetében, sok felhasználós környezetben mindenképpen szükség is van. A kétszintű rendszer használatával az adminisztratív feladatok is minimalizálhatók, mert nincs szükség az adatok rögzítésére minden tagszervezet esetében különkülön. A közös központi tárolóból mindenki, akinek van joga hozzá, lekérheti az adatokat, elemezheti azokat, vagy a mások által készített elemzéseket is megtekintheti. Ezzel az információk és tudások hatékonyan megoszthatók a résztvevők között. Felmerül, hogy hogyan lehet megelőzni a résztvevők potyautas viselkedését, ami amiatt várható, hogy azok a tagszervezetek, amelyek időben később állnak neki a rendelkezésre álló szakértői anyagok tanulmányozásának, előnyhöz jutnak azáltal, hogy a többiek elemzéseit láthatják. Mivel ez teljesen racionális viselkedés, kell valamilyen módot találni arra, hogy ellenérdekeltté tegyük őket az effajta viselkedés tanúsításában. Ennek eszköze lehet valamilyen pozitív ösztönzés, vagy valamilyen előírás, mint például, hogy az elemzéseket rotációs rendszerben kötelesek elkezdeni a tagszervezetek. Itt természetesen figyelemmel kell lenni arra, hogy nem lehet pusztán matematikai módszerekkel meghatározni, hogy mikor melyik tagszervezet a legyen soros, mivel a szakmai kompetenciák inhomogén eloszlása miatt a legtöbbször nem arra a tagszervezetre fog kerülni a sor, amelyikre szakmailag leginkább ráillene, vagyis nem azokra a személyekre, akik értenek is hozzá. Ezért tehát valamilyen módon súlyozni szükséges ezt az algoritmust. Ennek kidolgozása az egyes tagszervezetek kompetenciáinak részletes ismeretét követeli meg, másrészt a felmerülő véleményalkotási feladatok jellege is befolyásolja a súlyozás kialakításának szempontrendszerét. Döntéstámogatórendszer Készítette: IQ ConsultinG Kft., 2009. [email protected] verzió: 2.0

65/90

A tagszerveztek sorozatos véleményalkotása és az egymás véleményére való reagálásuk eredményeképpen olyan közös vélemény alakul ki, amilyennel többékevésbé az összes tagszervezet egyetért, és amely szakmai alapokon nyugszik. Egy ilyen vélemény kialakítása pedig elengedhetetlen ahhoz, hogy azt mondhassuk, a STRATOSZ által képviselt vélemény a tagok konszenzusos és szakmailag megalapozott.


66/90

Melléklet

A Doctus Döntéselőkészítő Rendszer 2 A Doctus egy keretrendszer (Shell) tudásbázisú szakértőrendszer (Knowledge-Based Expert System) építéséhez. A tudásbázisú rendszerek tudásbázisokkal támogatják a munkánkat, és azért szakértői, mert szakértői szintű tudásra vonatkozik, azaz a legmagasabb szintű tudásra, ami még szavakba önthető, és azt is jelzi, hogy ez egy szűk területre vonatkozó tudás. Egy tudásbázisú szakértőrendszer két fő részből áll, a tudásbázisból és a keretrendszerből. Az, hogy a Doctus egy keretrendszer azt jelenti, hogy egy üres szoftver, amit arra terveztünk, hogy a szakértők tudása alapján tudásbázisokat készítsünk. Ennek során a szakértők tudását rendszerezzük, és gyakran új tudás fölfedezésével jár. A tudásbázis építése három folyamatot foglal magában, ezek: a tudásgyűjtés (Knowledge Acquisition), a tudásrendezés (Knowledge Engineering), ami a rendszerezésből és a finomhangolásból áll, valamint az alkalmazás. Mindezeket a folyamatokat a tudásrendező (Knowledge Engineer) támogatja.

G-1. Ábra: Tudásbázisépítés A tudás megjelenítésére a Doctus szimbolikus logikát használ. Ez egy olyan formalizmust jelent, melyben a tudást logikai állítások írják le, amelyek szimbólumokból állnak, amiket “ha. akkor” szabályok kapcsolnak öszsze. A szimbólumok fogalmak, azaz a szakértő saját szavai. Emiatt a Doctus a szimbolikus mesterséges intelligencia körébe tartozik. A tudásbázisú rendszereket arra használjuk, hogy döntési alternatívákat értékeljünk, ezért a Doctus egyúttal a döntéstámogató rendszerekhez (Decision Support Systems) is tartozik. A döntési alternatívákat a Doctusban eseteknek nevezzük. Az esetek értékelése a következtetés. A Doctus háromféle következtetésre alkalmas: 2

© Doctus Bt.


67/90

•

•

•

Ha a szakértő ki tudja mondani a fontos döntési szempontokat és a közöttük lévő szabályokat, a rendszer alkalmazza ezeket a szabályokat, hogy előállítsa az értékelést. Ezt dedukciónak, vagy szabályalapú következtetésnek (Rule-Based Reasoning – RBR) nevezzük. Ezt akkor szoktuk használni, ha nincs tapasztalat a területen, és emiatt eredeti döntésre (Original Decision) van szükség. Ha a szakértő ki tudja mondani a szempontokat, de nem tudja megmondani, hogy melyek fontosak közülük és nem tudja megfogalmazni a közöttük lévő szabályokat, de eléggé tapasztalt (néhány tucat esetet ki tud mondani az értékeléssel együtt), akkor ebből a tapasztalatból kiindulva megtalálhatjuk azokat a szabályokat, amelyek leírják tapasztalat eseteit. Ez a következtetés az indukció, ami az esetalapú következtetés (Case-Based Reasoning – CBR) szimbolikus változata. Mivel jelentős tapasztalatot feltételez a területen, az ilyen helyzetben rutindöntésről (Routine Decision) beszélünk. Az indukció eredményéből a fontos döntési szempontokat redukcióval határozhatjuk meg. Ez a harmadik fajta következtetés, de csak az indukció után következhet, így nincs harmadik fajta tudásbázis. Csak kétféle tudásbázist építhetünk, szabályalapút és esetalapút.

2 Eredeti döntés (ha nincs tapasztalat a területen) Ha nincs feldolgozható tapasztalata a területen, a szakértőnek ki kell mondania a szabályokat, ezért ebben a helyzetben szabályalapú következtetést (Rule-Based Reasoning – RBR) használunk. Mivel az általánosan megfogalmazott szabályokat alkalmazzuk az egyedi esetekre ezt a következtetést dedukciónak is nevezzük.

2.1 Előnyök Ha a tudásrendezés sikeres volt, akkor a tudásbázisú rendszer ugyanazt az értékelést adja az esetekre, amit a szakértő adna. Akkor mit sikerült hozzáadni? A tudásbázis a szakértő (vagy szakértőkből álló csoport) tudásának áttekinthető leírása, ami alapján a döntési javaslat könnyen indokolható. Az áttekinthetőség mellett a szakértő új tudásra lelhet, azáltal, hogy rájön, hogy bizonyos tulajdonságok nem fontosak, vagy átalakíthatja tudását a komplex szabályok megértése alapján. Ez azt jelenti, hogy az explicit elvárások közötti hallgatólagos kapcsolatok egy része explicitté vált a szakértő számára.

2.2 A tulajdonságok összegyűjtése A tudásgyűjtés első lépése mindig a döntési szempontok megfogalmazása. A döntési szempontokat a szakértő a tulajdonságokkal (azaz a tulajdonságok neveivel) és azok értékeivel írja le. Egy tulajdonság egy értéke egy elvárás, vagyis egy döntési kritérium. A tulajdonságok és az értékek összegyűjtése a Doctus első lapján (“Attributes” címke) történik.


68/90

G-2. Ábra: Tulajdonságok és értékek összegyűjtése. A tulajdonságok értékei különböző jósági sorrendben lehetnek: növekvő (increasing), ha az első érték a legrosszabb; csökkenő (decreasing), ha az első helyen a legjobb van; ha egyik érték nem jobb, mint a másik, akkor a sorrend nominális (nominal). Ha szabályalapú tudásbázist építünk, akkor a tulajdonságok és értékeik meghatározása után a közöttük lévő kapcsolatok meghatározása következik. Ezeknek két része van, a “mitől” és a “hogyan” függ

2.3 A tulajdonságok hierarchiája: a szabályalapú gráf Minden tulajdonságra meg kell adnunk, hogy mely tulajdonságoktól függ. Ehhez a tulajdonságokat egy hierarchikus gráfba rendezzük, amit szabályalapú vagy deduktív gráfnak hívunk (Rule-Based Graph). A gráf a Doctus harmadik lapján jelenik meg a szerkesztés úgy történik, hogy az egérrel egymás alá húzzuk a tulajdonságneveket (drag-and-drop).

G-3. Ábra: A szabályalapú gráf. Ha B tulajdonságot bekötöttük A tulajdonság alá (tehát A függ B-től), akkor B-t A faktorának (factor) nevezzük. Ugyanaz a tulajdonság lehet több más tulajdonságnak is faktora, de saját magának nem lehet (sem, közvet-


69/90

lenül sem közvetve). A gráf gyökere nem faktora egyetlen tulajdonságnak sem, ezt nevezzük döntési tulajdonságnak (decision attribute) vagy kimenetnek. A gráf leveleinek nincsenek faktorai, ők a bemeneti tulajdonságok (input attributes). A többi tulajdonság más tulajdonságok faktora és neki is vannak faktorai, ezek a függő tulajdonságok (dependant attributes). Ha elkészült a szabályalapú gráf, akkor minden pontjában meg kell határozni a szabályokat.

2.4 Az esetek összegyűjtése A tudásbázisú rendszereket arra használjuk, hogy az eseteket értékeljük. Eset bármi lehet, amit le tudunk írni az összes fontos szempontból (azaz a kimondott tulajdonságokkal). Minden tulajdonság egy-egy értékét rendeljük minden egyes esethez. Tuljadonképpen az egy-egy érték az alapértelmezett, de a Doctus szintén kezeli az ismeretlen (“Unknown”), a mindegy (“Don’t care”) és az osztott értékeket (distributed values). Az esetek leírása a Doctus második lapján (“Cases” címke) történik. Dedukciónál, azaz szabályalapú következtetésnél ez a szabályalapú gráf megszerkesztése után következik, de később is bármikor adhatunk új eseteket a tudásbázishoz. A legkönnyebben úgy tudjuk hozzárendelni a tulajdonságok értékeit az esetekhez, ha a jobb egérgomb menüt használjuk.

G-4. Ábra: Az esetek összegyűjtése.

2.5 Tudásimport – adatbányászat A tudásimport (Knowledge Import) funkció arra szolgál, hogy az eseteket közvetlenül külső adatforrásokból hozzuk. A beépített adatforrás típusok (némelyik csak “advanced mode” használata esetén érhető el): Excel munkafüzet, Microsoft Query, postafiók (mailbox) és az internetcímmé formázott (URL encoded) esetek, de bármilyen forrás elérhető az ODBC meghajtón keresztül.


70/90

G-5. Ábra: Tudásimport. Az adatforrás rekordjai a tudásbázis esetei lesznek. A tulajdonságok hozzárendelését és az esetek importálását varázsló (wizard) támogatja. Az importált érték lehet szöveges (text) típusú, azaz rugalmas (flexible) valamint számszerű. Ez utóbbiakat egy klaszterező algoritmus fogja kezelni. Az adatbányászat elképzelése abból a megfigyelésből fejlődött ki, hogy a szervezetek óriási mennyiségű adatot tárolnak (információrendszereik adatbázisaiban és adattárházaiban) és ezek többségét semmire sem használják. Elképzelhető, hogy ezen adatok közötti kapcsolatokban olyan szabályokat találhatunk, melyekből új tudást lehet fölfedezni. Az adatforrásokban található számszerű adatokat szimbólumokká kell alakítani. Ha a tudásimport modulon keresztül a Doctust összekapcsoltuk a külső adatforrással, ezt az átalakítást a beépített klaszterező algoritmus végzi el. A felhasználó csak a várt klaszterek számát kell, hogy megadja, a folyamat többi része automatikus.


71/90

G-6. Ábra: Külső adatok klaszterezése. A szabályalapú következtetésnél az adatbányászat azon az ötleten alapul, hogy a szakértő fejében lévő puha fogalmak némelyike visszavezethető az adatbázisokban és adattárházakban tárolt kemény adatok közötti puha összefüggésekre. Így a szabályalapú gráf egyes ágainak vége (a gráf levelei) számszerű bementet kaphatnak, pontosabban olyan szimbólumokat, amelyek numerikus tartományok klaszterezéséből származnak. Mivel az adatbázisokat és adattárházakat folyamatosan frissítik, a tudásbázis is mindig friss lesz az adatok szempontjából. Egy okos tudásbázis kialakításával intelligens értesítő funkciót hozhatunk létre, amely csak akkor hívja fel magára a figyelmet, ha az adatok változása a kimenetet is megváltoztatja.

2.6 A szabályok Ha kiválasztunk egy tulajdonságot az “Attributes”, a “Cases” vagy a “Rule-Based Graph” lapon, a negyedik lap címkéje megváltozik, a kiválasztott tulajdonság nevének megfelelően: “Rules of”. A gráf minden csomópontjában (azaz minden függő tulajdonságnál) meg kell adni egy szabályhalmazt, amely egy kimenetet (a kiválasztott tulajdonság egy értékét) rendel hozzá a faktorok értékeinek, minden lehetséges variációjához. Ha a szabályban minden faktornak egy értéke szerepel, elemi szabálynak (elementary rule) nevezzük.

Matek: Használjuk a következő jelöléseket: Tulajdonságok: A, B, C, (X a döntési tulajdonság)

Értékek: A={a1, a2, a3, }; B={b1, b2, b3, };

X={x1, x2, x3, }


72/90

Szabályok: A=a1

B=b2

C=c1

X=x1

Olvasd: Ha A értéke a1 és B értéke b2 és C értéke c1 és

akkor X értéke x1

Ha egy szabály értelmezési tartománya legalább egy tulajdonságra nagyobb, mint mint egy érték, akkor komplex szabálynak nevezzük. A lefedett tartomány csak szomszédos értékekből állhat, és lehet zárt (két érték és a közöttük lévők) vagy nyitott (jobb vagy rosszabb mint valamilyen érték).

Matek: A fenti jelöléseket használva.

Szabály: A [a2,, a5]

B=b2

C=c1

X= x1

Olvasd: Ha A értéke a1 és a5 között van és B értéke b2 és C értéke c1 és Szabály: A

a2

B=b2

C=c1

akkor X értéke x1

X=x1

Olvasd: Ha A értéke legalább a2 és B értéke b2 és C értéke c1 és

akkor X értéke x1

A komplex szabályokat tekinthetjük elemi szabályok összevonásának. A tudás kevesebb komplex szabállyal könnyebben leírható. Persze ugyanaz a tudás többféle komplex szabályhalmazzal is leírható, azaz többféleképpen tudjuk összevonni az elemi szabályokat. A Doctus két különböző felületet kínál a szabályok kezelésére, amelyek között a felhasználó váltogathat. Az 1D felületen a szabályok lista formájában jelennek meg. Új szabályt közvetlenül beírhatunk a táblázatba, vagy használhatjuk a szabály beszúrása (insert rule) utasítást. A 2D felületen egyes faktorok a táblázat sorait határozzák meg, mások az oszlopait. A táblázat minden cellája egy-egy szabály, melynek bemeneteit a helye (sor és oszlop) határozza meg, a kimenetét pedig a felhasználó adja meg, a jobb egérgomb menüből választva egy értéket. Egyszerre több cellát is kijelölhetünk.

G-7. Ábra: Szabályok 1D-ben.


73/90

G-8. Ábra: Szabályok 2D-ben. Az értékek már bemutatott jósági sorrendje alapján a Doctus tanácsokkal támogatja a szabálybevitelt. A tanácsok elfogadása segít elkerülni a szabályok ellentmondásait (inconsistency).

G-9. Ábra: Tanácsok a szabálybevitelhez. Akár használjuk a szabályokat, akár nem, semmi sem akadályozza meg, hogy ellentmondó szabályokat vigyünk be. De, ha kiválasztottuk a konzisztenciavizsgálat (consistency check) opciót, a Doctus megjelöli az ellentmondó szabályokat.


74/90

G-10. Ábra: Konzisztenciavizsgálat.

2.7 A következtetés A következtetés a szabályalapú rendszerben úgy működik, hogy aktivizáljuk a szabályokat az esetekre. Ezt az esetek értékelésének is nevezik, ugyanis minden esetre megkapjuk a döntési tulajdonság egy értékét. Az eredményt a “Cases” és a “Rule-Based Graph” oldalakon láthatjuk.

G-11. Ábra: A szabályalapú következtetés eredménye.


75/90

2.8 Döntéselemzés és csiszolás Nagyon kellemes volna a döntési helyzet, ha volna egy és csak egy eset, amelynek az értékelése a döntési tulajdonság legjobb értéke volna. Ez azonban rendkívül ritkán az első nekifutásra, általában több legjobb esetünk is van, vagy éppenséggel egyetlen sincs. A csiszolás támogatására a Doctust egy magyarázó opcióval (explanation) láttuk el. Magyarázatot kérhetünk az esetek értékelésére, és a függő tulajdonságokhoz tartozó értékeikre is. Megmutatja, hogy melyik szabály, okozta a kérdezett kimenetet.

G-12. Ábra: Az eredmény magyarázata. A magyarázatok segítségével meghatározzuk, hogy hol található az oka annak az értékelésnek, amellyel elégedetlenek vagyunk. A csiszolást viszont már kézzel kell elvégeznünk. Az eddigiek mellett azért is érdemes csiszolni a tudásbázist, hogy a tudás leírását egyszerűsítsük – persze úgy, hogy semmi fontos ne vesszen el. A finomhangolás általában a következők valamelyikét jelenti (esetleg többet is):

• • • • •

új tulajdonságok és/vagy értékek bevitele meglévő tulajdonságok és/vagy értékek átnevezése meglévő tulajdonságok és/vagy értékek törlése szabályok módosítása esetek módosítása.

A csiszolás után a tudásbázisnak tükröznie kell a szakértő véleményét a döntésről. A csiszolás akkor ért véget, amikor a szakértő a tudásbázis minden elemével egyetért.


76/90

2.9 Tudásexport – intelligens portál A Doctus különféle intelligens ágensek (intelligent agent) formájában képes exportálni a tudásbázist. Ezek közül néhány csak az “advanced mode” használata esetén érhető el.

G-13. Ábra: Tudásexport. Az exportált tudás kétféle lehet:

•

•

A statikus exportált tudás valamiféle pillanatfelvétel a tudásbázisról, azaz nem képes következtetésre. Generálhatunk különböző típusú képeket és táblázatokat, amelyek a tudásbázis gráfjait vagy adatait tartalmazzák, valamint generálhatunk jelentést rtf formátumban, amely tartalmazza a tudásbázis összes táblázatait. A dinamikus exportált tudás képes következtetni. A beépített sablonokból generálhatunk webes szerver oldali alkalmazásokat (php, perl, jsp), kliens oldali alkalmazásokat (következtetésre képes html oldal, javascript) és önálló alkalmazásokat (c++, xls).

A tudásexportálásnak köszönhetően a tudásbázist sok felhasználó számára elérhetővé tehetjük, akik felhasználhatják következtetésre, de változtatni nem tudják. Az exportált tudás egyes változatai arra is alkalmasak, hogy portletként elhelyezzük őket a portálunkban. Ha a tudásbázis eredetileg külső forrásból hozott adatokat, ez a kapcsolat az exportált tudásbázisban is fenntartható. Így gyors értékelések készíthetők, melyekben a döntéshozónak csak néhány mezőt kell kitöltenie (kiválasztani néhány tulajdonság értékeit az esetekhez), míg a többi bement közvetlenül az adatbázisokból származik.


77/90

G-14. Ábra: Értékelés az intelligens portálban.

3 Rutindöntés (ha van néhány tucat eset a területen) Előfordul, hogy a szakértő nem tudja, vagy nem akarja kimondani a szabályokat, de a tapasztalatában van néhány eset az értékeléssel együtt. Ezeket az eseteket felhasználhatjuk arra, hogy megtaláljuk a tulajdonságok értékeit összekapcsoló szabályokat. Mivel az esetek képezik a következtetés alapját, ezt esetalapú következtetésnek (Case-Based Reasoning – CBR) nevezzük. Mivel konkrét esetek halmazát használjuk arra, hogy általánosított szabályokat fogalmazzunk meg, használhatjuk az indukció elnevezést is.


78/90

3.1 Előnyök Az esetalapú tudásbázis szembeötlő előnye, hogy a tulajdonságok száma lecsökken az informatív tulajdonságokra. Ez megkönnyíti a döntés delegálását. Ez természetesen nem jelenti azt, hogy programozott döntéshozókat csinálunk, hiszen az esetalapú gráf (Case-Based Graph) a szakértő tudását adott feltételek mellett jeleníti meg. Ha megjelenik egy új eset, amit nem ír le a tudásbázis, az azt jelenti, hogy nem volt hasonló eset a szakértő tapasztalatában. A feltételek szintén megváltozhatnak. Emiatt a ajánlatos a tudásbázist folyamatosan bővíteni az új esetekkel, hogy a lehető legfrissebb állapotban tartsuk. Az esetalapú tudásbázis építésének legnagyobb nyeresége kevésbé szembetűnő. Ez a folyamat szinte mindig tudásfelfedezéssel jár, azaz a hallgatólagos tudás egy része szavakba önthetővé válik. Nagyon gyakori, hogy a szakértőt megdöbbenti az esetalapú gráf első látványa, ezért ilyenkor, a csiszolás nem csak azért szükséges, hogy a tudásbázist pontosítsuk, hanem azért is, hogy jobban megértsük az eredményt.

3.2 A tulajdonságok összegyűjtése A tudásgyűjtés első lépése mindig a döntési szempontok megfogalmazása. A döntési szempontokat a szakértő a tulajdonságokkal (azaz a tulajdonságok neveivel) és azok értékeivel írja le. Egy tulajdonság egy értéke egy elvárás, vagyis egy döntési kritérium. A tulajdonságok és az értékek összegyűjtése a Doctus első lapján (“Attributes” címke) történik.

G-15. Ábra: Tulajdonságok és értékek összegyűjtése. A tulajdonságok értékei különböző jósági sorrendben lehetnek: növekvő (increasing), ha az első érték a legrosszabb; csökkenő (decreasing), ha az első helyen a legjobb van; ha egyik érték nem jobb, mint a másik, akkor a sorrend nominális (nominal). Ha esetalapú tudásbázist építünk, akkor a tulajdonságok és az értékek meghatározása után az esetek öszszegyűjtése következik. Meg kell adnunk az esetek értékelését is. A Doctus majd megtalálja azokat a szabályokat, amelyek leírják a szakértő tapasztalatának eseteit.


79/90

3.3 Az esetek összegyűjtése A tudásbázisú rendszereket arra használjuk, hogy az eseteket értékeljük. Eset bármi lehet, amit le tudunk írni az összes fontos szempontból (azaz a kimondott tulajdonságokkal). Minden tulajdonság egy-egy értékét rendeljük minden egyes esethez. Tuljadonképpen az egy-egy érték az alapértelmezett, de a Doctus szintén kezeli az ismeretlen (“Unknown”), a mindegy (“Don’t care”) és az osztott értékeket (distributed values). Az esetek leírása a Doctus második lapján (“Cases” címke) történik. Indukciónál, azaz esetalapú következtetésnél az esetek összegyűjtése közvetlenül a tulajdonságok összegyűjtése után következik, de később is bármikor adhatunk új eseteket a tudásbázishoz. A legkönnyebben úgy tudjuk hozzárendelni a tulajdonságok értékeit az esetekhez, ha a jobb egérgomb menüt használjuk.

G-16. Ábra: Az esetek összegyűjtése.

3.4 Tudásimport – adatbányászat A tudásimport (Knowledge Import) funkció arra szolgál, hogy az eseteket közvetlenül külső adatforrásokból hozzuk. A beépített adatforrás típusok (némelyik csak “advanced mode” használata esetén érhető el): Excel munkafüzet, Microsoft Query, postafiók (mailbox) és az internetcímmé formázott (URL encoded) esetek, de bármilyen forrás elérhető az ODBC meghajtón keresztül.


80/90

G-17. Ábra: Tudásimport. Az adatforrás rekordjai a tudásbázis esetei lesznek. A tulajdonságok hozzárendelését és az esetek importálását varázsló (wizard) támogatja. Az importált érték lehet szöveges (text) típusú, azaz rugalmas (flexible) valamint számszerű. Ez utóbbiakat egy klaszterező algoritmus fogja kezelni. Az adatbányászat elképzelése abból a megfigyelésből fejlődött ki, hogy a szervezetek óriási mennyiségű adatot tárolnak (információrendszereik adatbázisaiban és adattárházaiban) és ezek többségét semmire sem használják. Elképzelhető, hogy ezen adatok közötti kapcsolatokban olyan szabályokat találhatunk, melyekből új tudást lehet fölfedezni. Az adatforrásokban található számszerű adatokat szimbólumokká kell alakítani. Ha a tudásimport modulon keresztül a Doctust összekapcsoltuk a külső adatforrással, ezt az átalakítást a beépített klaszterező algoritmus végzi el. A felhasználó csak a várt klaszterek számát kell, hogy megadja, a folyamat többi része automatikus.


81/90

G-18. Ábra: Külső adatok klaszterezése. Az esetalapú következtetésnél az adatbányászat azon az ötleten alapul, hogy Doctus szabálykereső algoritmusa alkalmas arra is, hogy egy adatbázis vagy adattárház adatai között találja meg a mintákat. A számszerű adatokat először a klaszterező algoritmus alakítja szimbólumokká, míg a nem-számszerű adatok rugalmas értékekként (flexible value) kerülnek a tudásbázisba. Az ilyen típusú adatbányászat eredménye könnyen értelmezhető – mármint a terület szakértője számára.

3.5 Döntési fa: az esetalapú gráf A Doctus esetalapú gráfot generál, mellyel osztályokba sorolja a szakértőtől összegyűjtött eseteket. Az esetalapú gráf egy döntési fa, de nem függőségi viszonyokat mutat, hanem a “ha akkor” szabályokat, amelyeket az esetek feldolgozásából nyert. A “ha akkor” szabályokat úgy tudjuk leolvasni, hogy a gráf gyökerétől a levelek felé haladunk, ahol a kimenet értéke jelenik meg. Az esetalapú gráf generálásakor három elágaztatási mód közül választhatunk: Az alapértelmezett a hatékony (“Efficient”), amit a következő fejezetben részletesen bemutatunk. A bipoláris (“Bipolar”) minden csomópontot kétfelé ágaztat jó és rossz csoportokba sorolva a tulajdonság értékeit. A heurisztikus (“Heuristic”) ugyanazt az eredményt adja, mint a hatékony, amennyiben sok eset és/vagy tulajdonság van, ami egyébként jelentősen növelné a futási időt.


82/90

G-19. Ábra: Az esetalapú gráf. Az esetalapú gráfban megjelenő tulajdonságokat informatív tulajdonságoknak nevezzük, mivel ezek elegendőek, az összes esetet osztályozásához.

3.6 Az esetek osztályozása Hogyan készül el végül is az esetalapú gráf? Tegyük fel, hogy az esetek egy halmazt alkotnak, melyben rendetlenség van, a rendet definiáljuk a minősítő érték (a kimeneti tulajdonság értéke) homogenitásával. Ez azt jelenti, hogy az egyes részhalmazokba tartozó eseteknek egyforma a minősítő értéke. Keressük azt a tulajdonságot, amelyik a leginkább hozzájárul a rendhez. Egyenként vesszük a tulajdonságokat, és részhalmazokat képezünk azok értékei szerint. A tulajdonságok rendcsináló erősségét az informativitással (entrópianyereséggel) fejezzük ki. Kiválasztjuk a leginformatívabb tulajdonságot, ez kerül a gráf gyökerébe, és az első szintű részhalmazokat ennek értékei szerint képezzük. Ezeket a részhalmazokat az előbbi algoritmus szerint bontjuk tovább, míg minden részhalmaz homogén lesz a minősítő értékek szerint. A homogén részhalmazokat nem bontjuk tovább, ezek lesznek a gráf levelei.

3.7 A következtetés Az esetalapú következtetés eredménye az esetalapú gráf, amely leírja a szakértő tapasztalatának eseteiből indukált szabályokat. Új esetet szintén egyszerű értékelni az esetlapú gráf alapján: csak meg kell nézni, hogy mik az új eset jellemzői az informatív tulajdonságokra, és ennek alapján be kell sorolni a gráf gyökerétől a levelek felé haladva. Emellett a Doctus a redukcióval és egyes tudásexport megoldásokkal is támogatja az új esetek minősítését.

3.8 Döntéselemzés és csiszolás A szakértő általában rosszul viseli, hogy a tapasztalata leírható mindössze néhány tulajdonsággal azok közül, amiket kimondott. A Doctus azzal támogatja az esetalapú gráf elemzését, hogy könnyet átlátható információ-


83/90

kat ad minden csomópontban az informativitásról, a sűrűségről, az esetekről és a statisztikáról. Szintén könynyű kicserélni azt a tulajdonságot, amelynek értékei alapján tovább ágazik egy csomópontot, bár ennek vannak feltételei, amikre érdemes odafigyelni. A csiszolás párhuzamos, vagy majdnem párhuzamos tudásmodellek közötti váltogatás. Ez azt jelenti, hogy a tulajdonság kicserélése egy csomópontban csak abban az esetben lehet indokolt, ha azonos vagy majdnem azonos az informativitása és a sűrűsége.

G-20. Ábra: Tulajdonságok informativitása és sűrűsége. A csiszolásnak vannak más módjai is. Előfordul, hogy olyan esetet találunk, amely sehogyan sem illeszkedik az esethalmazba, és durva torzulásokat okozhat az esetalapú gráfon. Ezeket az eseteket általában nem jól írják le a felsorolt tulajdonságok, ezért kakukktojásoknak nevezzük őket. Ezeket érdemes kizárni az esetalapú következtetés bázisából. Néha van két (vagy több) eset, amelyeknek teljesen egyformák a jellemzői, kivéve a minősítést. Ez általában azt jelenti, hogy egy új tulajdonságra vagy értékre van szükség, amely alapján meg tudjuk őket különböztetni. És persze módosíthatjuk az eseteket is.



84/90


•

•


A tudásexportálásnak köszönhetően a tudásbázist sok felhasználó számára elérhetővé tehetjük, akik felhasználhatják következtetésre, de változtatni nem tudják. Az exportált tudás egyes változatai arra is alkalmasak, hogy portletként elhelyezzük őket a portálunkban. Az exportált esetalapú tudásbázisnak két nagyon hasznos alkalmazása van: így gyűjthetünk újabb eseteket a tudásbázis bővítéséhez és gyors értékelést adhatunk az új esetről, a gráf gyökerétől a levelei felé haladó utat követve.


85/90

G-22. Ábra: Exportált esetalapú tudásbázis esetek gyűjtéséhez és gyors értékeléshez.

4 Tanulás az esetekből (a modell redukálása) Ha a szakértő elfogadta az esetalapú gráfot, akkor egy gombnyomással létrehozhatunk egy új szabályalapú tudásbázist, amelyben csak az informatív tulajdonságok szerepelnek, de ugyanazt a következtetést adja az indukcióban használt esetekre. A következtetés szabályok alapján történik, de ezeket a szabályokat esetekből nyertük indukcióval, ezért azt mondjuk esetalapú szabályokból következtetünk (Case-Based Rule Reasoning). Mivel a tudásbázist egy meglévő modell redukálásával kaptuk, redukciónak is nevezzük. A tulajdonságok és az esetek már induláskor benne vannak a tudásbázisban, ezért itt nem szól fejezet a tulajdonságok és az esetek összegyűjtéséről illetve a tudásimportról.

4.1 Előnyök A redukcióval generált tudásbázis nagy előnye, a lecsökkent méret, azaz hogy jóval kevesebb tulajdonság szerepel benne. Ez lehetővé teszi a felhasználó számára az új esetek gyors értékelését, de oda kell figyelni az aktualitásra (vagyis annak elveszésére). Hogy elkerüljük az elavult tudásbázis használatát, karban kell tartani az eredeti esetalapú tudásbázist folyamatosan hozzáadva az új eseteket és újragenerálva az esetalapú gráfot. Ha megváltoznak a feltételek, meg fog változni az esetalapú gráf is.


86/90

4.2 Egyszintű hierarchia Amikor az esetalapú gráfból a Doctus automatikusan generál egy szabályalapú tudásbázist, abban tulajdonságok egyszintű hierarchiában lesznek. Hogy megkülönböztessük ezt a szabályalapú gráfot a szokásostól, külön nevet adtunk neki, ami meg is jelenik a Doctus harmadik lapjának címkéjében esetalapú szabálygráf (Case-Based Rule Graph). Eltekintve attól, hogy egyszintű, ez a szabálygráf ugyanúgy működik azok, amiket a megszokott módon épített szabályalapú tudásbázisokban hoztunk létre, lásd a Eredeti döntés – A tulajdonságok hierarchiája: a szabályalapú gráf fejezetet.

G-23. Ábra: Az esetalapú szabálygráf.

4.3 Hiányzó és eldöntetlen szabályok Ha a szabályoknak van olyan értelmezési tartománya, amit az esetalapú következtetéshez használt esethalmaz nem fed le vagy többszörösen is lefed, a redukált tudásbázis egyes szabályai hiányozhatnak, vagy eldöntetlenek lehetnek.


87/90

G-24. Ábra: Eldöntetlen szabályok a redukcióban. A hiányzó vagy eldöntetlen szabályok jelenthetnek lehetetlen tartományt vagy rosszul definiált tulajdonságot vagy értéket. Ezeket a helyzeteket általában a csiszolás során tisztázzuk. A szabályhalmazban ugyanazokat a műveleteket tudjuk használni, mint a szabályalapú tudásbázisok esetében, lásd a Eredeti döntés – A szabályok fejezetet.

4.4 A következtetés Esetalapú szabályoknál a következtetés ugyanúgy működik, mint a szabályalapú tudásbázisokban láttuk, (Eredeti döntés – A következtetés fejezet), de csiszolás nélkül megtörténhet, hogy az új eset(ek) értékelése eldöntetlen lesz, vagy egyáltalán nem lesz értékelés. Ez utóbbi esetben nagyon érdemes megismételni az esetalapú következtetést, az új esete(ke)t is figyelembe véve.

4.5 Hallgatólagos tudás és csiszolás A hiányzó vagy eldöntetlen szabályokat úgy tehetjük a legegyszerűbben egyértelművé, hogy átírjuk a szabályok kimeneteit. Ellenben érdemes elgondolkodni azon, hogy mi okozta a hiányzó vagy eldöntetlen szabályokat? Ha a szakértő biztos benne, hogy lehetetlen tartományról van szó, akkor akár úgy is hagyhatjuk őket, hiszen úgysem lesz oda tartozó eset. Ha mégis találunk olyan új esetet, amely ebbe a tartományba esik, elképzelhető, hogy megváltoztak a feltételek, és ebben az esetben érdemes frissíteni az esetalapú következtetést. Ha a csiszolás során változtattunk a tulajdonságokon és/vagy az értékeken, ugyanezeket a változtatásokat érdemes végrehajtani az eredeti esetalapú tudásbázison is, és megismételni az esetalapú következtetést. Mivel a redukált tudásbázisban a tulajdonságok egyszintű hierarchiában vannak, könnyen megtörténhet, hogy több mint 3-4 tulajdonságot kell összekapcsolnunk a szabályokkal, és így a szabályhalmaz kezelése nehézkessé válik. Nincs akadálya annak, hogy a gráfot többszintűvé alakítsuk, a szokásos drag-and-drop módszert használva, ahogy az a Eredeti döntés – A tulajdonságok hierarchiája: a szabályalapú gráf fejezetben szerepelt.


88/90

A csiszolt esetalapú szabálygráfot visszacsatolásként használhatjuk az eredeti szabályalapú vagy esetalapú tudásbázishoz, és ezáltal kimondhatóvá tehetjük a hallgatólagos tudás egy részét.



•

•


A tudásexportálásnak köszönhetően a tudásbázist sok felhasználó számára elérhetővé tehetjük, akik felhasználhatják következtetésre, de változtatni nem tudják. Az exportált tudás egyes változatai arra is alkalmasak, hogy portletként elhelyezzük őket a portálunkban. Mivel a redukcióval egy új szabályalapú tudásbázist hozunk létre, ennek exportált változatai nagyon hasonlóak a dedukcióban használtakhoz, csak annyi a különbség, hogy kevesebb mezőt kell kitölteni.


89/90

G-26. Ábra: Az exportált redukált modell.


90/90

DÖNTÉSTÁMOGATÓ RENDSZER. Szerző: IQ ConsultinG Kft. Készült a MAT támogatásával, az FSzH közreműködésével, 2009-ben

Recommend Documents