Adatbáziskezelés és Vállalatirányítási Információs Rendszerek

Szent István Egyetem

Vállaltgazdasági és Szervezési Intézet Információgazdálkodási Tanszék

Gödöllı

ADATBÁZISKEZELÉS ÉS VÁLLALATIRÁNYÍTÁSI

INFORMÁCIÓS RENDSZEREK

EGYETEMI JEGYZET A tantárgy folyamatos fejlesztése miatt jegyzet

csak a 2008. tavaszi félévben érvényes!

Készítette:

Dr. Kovács Árpád Endre Klárné Barta Éva

Molnár Attila Szalay Zsigmond Gábor

Gödöllı 2008.

iii. oldal

TARTALOMJEGYZÉK

1. BEVEZETÉS ...................................................................................................................5

2. A vállalatirányítási információs rendszerek gazdaságtana............................................7 2.1. Információelméleti alapfogalmak ...........................................................................7

2.1.1. Az információrendszer..................................................................................7 2.1.2. A közleményforrás entrópiája ......................................................................9

2.2. A vállalatirányítási rendszerek szervezeti megközelítése ...................................12 2.2.1. A vezetıi szintek és információs igényeik ................................................12 2.2.2. Információs szolgáltatás a menedzsment információs rendszeren

keresztül .......................................................................................................12 2.2.3. A vállalati információs rendszerekkel kapcsolatos elvárások,

követelmények ............................................................................................13 2.2.4. A vállalatok innovációs készsége az információ-menedzsment

területén .......................................................................................................14 2.3. Az információ gazdasági hasznosságának mérhetısége ....................................16

2.3.1. Az információ, mint termelési tényezı.....................................................16 2.3.2. A teljes körő információ értéke..................................................................17 2.3.3. A pontosabb információ Bayes-tétel alapján számított értéke...............18 2.3.4. A növekvı szabályozás-intenzitás értéke..................................................21

2.4. A vállalati információs rendszerek gazdaságossága ...........................................24 1.1.1. Az információs rendszerek költség-haszon összetevıi .........................24 1.1.2. IT beruházások TCO elemzése (Total Cost of Ownership) ................25 1.1.3. Return on Investment (ROI) ....................................................................27 1.1.4. Net Present Value (NPV), Internal Rate of Return (IRR)....................27

2.5. A vállalati információs rendszerek sajátságos költségei.....................................28 2.5.1. A lekötés és az átállási költség....................................................................29 2.5.2. A lekötés fajtái..............................................................................................30

3. Az információ-gazdálkodás ...........................................................................................33 3.1. A vállalatirányítási információs rendszerek meghatározása...............................33 3.2. A vállalatirányítási információs rendszerek evolúciója ......................................34 3.3. A vállalatirányítási információs rendszerek feladatai..........................................37

4. Integrált vállalatirányítási információs rendszerek......................................................39 4.1. Az integrált vállalatirányítási információs rendszerek alapjellemzıi ................39 4.2. Az integrált vállalatirányítási információs rendszerek felépítése.......................40 4.3. Az integrált vállalatirányítási információs rendszerek funkcionális területei...41

4.3.1. Vállalatirányítási területek ...........................................................................42 4.3.2. Vállalatirányítási modulok és szerepkörök ...............................................44

4.4. ERP modulok .........................................................................................................44 4.5. CRM modulok ........................................................................................................44

5. Az igénybevétel formái ..................................................................................................49 5.1. Bevezetéshez kapcsolódó elemek.........................................................................49 5.2. Tradicionális modell ...............................................................................................49 5.3. Outsourcing modell................................................................................................50

5.3.1. Hosting..........................................................................................................50 5.3.2. Alkalmazásszolgáltatás - ASP.....................................................................51

Tartalomjegyzék

iv. oldal

6. Vállaltirányítási modulok ...............................................................................................55 6.1. Pénzügyi modulok ..................................................................................................55

6.1.1. Pénzügy-számvitel – Financial (FI) ...........................................................55 6.1.2. A pénzügyi könyvelés funkciói ..................................................................56

6.2. Eszközgazdálkodás – Asset Management (AM).................................................58 6.2.1. Az eszközkönyvelés néhány funkciója......................................................58

6.3. Kontrolling – Controlling (CO)............................................................................60 6.4. Logisztikai modulok ...............................................................................................63

6.4.1. Anyaggazdálkodás – Material Management (MM) ..................................63 6.4.2. Termeléstervezés – Production Planning (PP) ........................................65 6.4.3. A termeléstervezési modul néhány funkciója...........................................66 6.4.4. Mőszaki rendszerek strukturálása ..............................................................67 6.4.5. Értékesítés – Sales and Distribution (SD) ................................................68 6.4.6. Minıségmenedzsment – Quality Management (QM).............................69 6.4.7. A QM modul belsı funkciói ......................................................................70 6.4.8. PA Modul (Személyügyi Adminisztráció).................................................70 6.4.9. PD modul (Személyügyi fejlesztés) ...........................................................71 6.4.10. Projekt rendszer – Project System (PS) ..................................................72

6.5. CRM – Customer Relationship Management .....................................................73 6.5.1. A marketing modul funkcionalitása ..........................................................74 6.5.2. Az értékesítési modul bemutatása .............................................................74

7. Adatbázisok és adattárházak – az információs rendszerek adatkezelıi ...................79 Adatbázisok és adatbáziskezelı rendszerek................................................................79 7.1. Adatmodellezés.......................................................................................................82

Relációs adatmodell ...............................................................................................84 7.2. Adatbáziskezelı rendszerek többfelhasználós környezetben ...........................92

Osztott adatbázisok ...............................................................................................94 Internetes adatbázisok ...........................................................................................94

7.3. OLTP és OLAP rendszerek..................................................................................95 Mőveleti adatbázisok – OLTP rendszerek..........................................................95 Döntéstámogató rendszerek – OLAP rendszerek.............................................95 Adattárházak (Data Warehouse) ..........................................................................96

7.4. A vállalati információs rendszerek és az adatbázisok.........................................99

8. A vállalatirányítási információs rendszerek kiválasztása ......................................... 101 8.1. A rendszerkiválasztás folyamata ........................................................................ 101

8.1.1. A meghívottak körének megállapítása ................................................... 105 8.1.2. A pályázat meghirdetése .......................................................................... 105 8.1.3. Pályázati konzultációk.............................................................................. 106 8.1.4. A beérkezett pályázatok értékelése ......................................................... 106 8.1.5. Eredményhirdetés..................................................................................... 107

Copyright: Minden jog fenntartva!

5. oldal

„... az emberek többsége túlságosan is sok tényezı ismeretében kíván dönteni. Emögött az húzódhat meg, hogyha az ember elég sok tényt ismer, akkor a döntés majd önmagától megszületik.

A sikeres vezetık általában gyors döntéshozók. Nincs szükségük arra, hogy minden megismerhetı tényt megismerjenek. Elfogadják, hogy ık is hozhatnak rossz döntéseket, bár bíznak abban, hogy igen-is helyes döntéseket hoznak!”

(Mark A. McCormack)

1. BEVEZETÉS

Információ központú világában élünk, amely információ fontossága és jelentıssége a gazdaság-ban vitathatatlan. A nagyobb vállalatoknál már nemcsak a vezetıknek, hanem valamennyi mun-katársnak szüksége van azonnali, pontos, megbízható adatokra, információkra a saját szakterület-ükön. A vállalat vezetése napi munkája során folyamatosan döntéseket hoz. Általában minél ma-gasabb szinten születik egy döntés, annál összetettebb. Más-más problémakört takar egy-egy be-ruházási-, finanszírozási-, technológiai- vagy humánpolitikai döntés meghozatala.

A számítógépes integrált vezetıi információs-rendszerek Magyarországon a mezıgazdaságban korlátozottan kerülnek alkalmazásra. A témával foglalkozó vállalatvezetı a szakirodalomban azt olvashatja, hogy a számítógépesítés növeli a hatékonyságot és a felsı vezetés információ-ellátottságát, ezzel szemben azt tapasztalja, hogy a folyamatos beruházások ellenére beosztottjai a számítógépes feldolgozás munkaigényességérıl, pontatlanságáról panaszkodnak, ı pedig nem jut használható adatokhoz a rendszerbıl, az üzleti folyamatokról.

Az Adatbáziskezelés és vállalatirányítási információs rendszerek címő tárgy célja, hogy olyan naprakész, átfogó szemléletmódot nyújtson, amely megfelelı alapot ad az egyetemi hallgatók számára ahhoz, hogy biztonsággal eligazodjanak a vállalatoknál fellelhetı rendszerek területén.

A jelen jegyzetben felhalmozott ismeretanyag azon a Magyarországon még újszerő megköze-lítésmódon alapul, hogy az információval, mint erıforrással történı gazdálkodás nem az informatikai szakemberek, hanem a vállalati vezetık feladata.

Jelen jegyzet a gödöllıi Szent István Egyetem - Vállaltgazdasági és Szervezési Intézetének okta-tástámogató rendszerén (http://vgszi.szie.hu) található tananyagokkal együtt olyan ismeretanyago-kat tartalmaz, amelyek nem nélkülözhetıek a korszerő információgazdálkodást folytató vállalatok vezetıi számára.

7. oldal

2. A VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK GAZDASÁGTANA

Bármely rendszer mőködése csak információkkal megfelelıen alátámasztott döntésekkel terelhetı a kívánt cél felé. A kibernetika megjelenésével az információ egyre hangsúlyosabb szerephez ju-tott. Egyenrangúvá vált az anyag és az energia jelentıségével. Az információ a rendszerek belsı összetartó elemévé vált, illetve az információs rendszerek az elemek kapcsolati rendszerei lettek. (Haklak – Nagy [1975].)

Az információkat forrásuk alapján elkülönítjük vállalaton belüli és vállalaton kívüli információkra. A belsı információk bizonyos vállalati helyzetekrıl és folyamatokról (pl. ktg-ek alakulása, kapaci-tások, készletszintek, termelés alakulása, szociológiai jellemzık) szolgáltatnak adatot. A külsı információk a környezetre vonatkozó adatokat tartalmazzák (pl.: felvevıpiac alakulása, beszerzési piac árai, törvények, rendeletek).

A menedzser az a személy, aki felelısséggel használja fel a rendelkezésre álló erıforrásokat a szervezeti cél elérése érdekében. Erıforrások alatt az embereket, az anyagi- és pénzeszközöket, valamint az információt értjük. A legtöbb szervezet leggyakoribb célja a bevételek növelése, a költségek csökkentése, azaz az eredmény növelése. A menedzser ezen célok elérésén dolgozik, miközben négy menedzser funkciót valósít meg: a tervezés, szervezés, irányítás és az ellenırzés (controlling). (A. Szymanski - P. Szymanski - Morris – Pulschen [1988].)

A tervezés az a folyamat, amikor az elıttünk álló lehetséges tevékenységeket úgy állítjuk össze, hogy ezzel megvalósítsuk a szervezet rövid- és hosszú távú céljait. A szervezés során összegyőjt-jük a rendelkezésre álló embereket, eszközöket, tıkét és kialakítunk egy olyan struktúrát, amely lehetıséget biztosít a hatékony munka végzésére. Betölteni a vezetı szerepét, ellenırizni az em-bereket a kommunikáción és a motiváláson keresztül, ez az irányítás. A kontrolling ellenırzi, hogy a szervezet valóban a kívánt cél felé tart-e. A menedzser értékeli a szervezet teljesítményét, és ha szükséges megtervezi és megvalósítja a változtatásokat. (A. Szymanski - P. Szymans-ki - Morris - Pulschen [1988].)

2.1. INFORMÁCIÓELMÉLETI ALAPFOGALMAK

Nem könnyő megfogalmazni azt, hogy mi is az az információ. A szakirodalom ebben a kérdés-ben sem egységes, hiszen még az adat fogalmának meghatározását is sok vita övezi. Az mégis megállapítható, hogy az adat mindig a valóságra vonatkozik, egy olyan tényszerő megállapítás, ami a világról nyújt ismereteket (Halassy [1982].) Az információ már egy feldolgozott értelmezett adat, ezért nem hagyhatjuk figyelmen kívül azt, hogy valamely információforrás információ tar-tamát alapvetıen befolyásolja az a körülmény, hogy ki a vevıje. (Noszkay [1994].) Egy hírrend-szer tervezésekor tudnunk kell, hogy egyik vagy másik információt a vevık teljesen másként ér-telmezhetik. Ebbıl adódóan a rendszer tervezıjének át kell látnia az egyes felhasználói szinteket és jellemzıiket, továbbá azt, hogy miért van szükség az információra. (Petrovics [1977].) Ezen rendszerelméleti és vállalati megközelítéseket megelızıen célszerő az információelméleti alapok áttekintése.

2.1.1. Az információrendszer

Egy diszkrét információrendszer, illetve kódolási rendszer jelkészletének (jelhalmazának, jelrend-szerének) egy elemét jelölje Sj, ahol j = 1,…, n és n e halmaz elemeinek száma. Az egyes jelek helyszükségletét (sormenti hosszát), tartalmát (terjedelmét) reprezentálja tj. Ezek alapján az Sj tárolásához vagy átviteléhez általában az információhordozó közeg tj mennyisége szükséges. A

Adatbáziskezelés és Vállalatirányítási Információs Rendszerek

8. oldal

jelkészlet fix hosszúságú amennyiben tj állandó (tj = const) minden j-re, ellenkezı esetben változó hosszúságú. A számítógépek általában fix hosszúságú vagy byte-hosszúságú kódolási rendszert használnak, míg például a Morse-abc változó hosszúságú jelekbıl áll. Az információelméletben a csatorna kifejezés alatta egy információs közeg, azaz a jelsorozatokat megırzı és továbbító fizikai eszközök összességét kell érteni. A csatorna kapacitását, azaz egy bizonyos terjedelemegységben vagy idıegységben átvihetı maximális információ mértékét (jel/mp, jel/sor, jel/mm, stb.) az adott csatorna, illetve információhordozó esetében választott jelek (Sj) és tartalmaik (tj) határoz-zák meg.

S1 – t1 … Sj – tj … Sn – tn

Amennyiben az információhordozó, illetve a csatorna egy bizonyos pozíciójának, elemi egysége (cella) j állapotban van, akkor elmondható, hogy ez az adott cella Sj jelet tartalmazza. Mivel j az n – a teljes és az összes lehetséges állapotot tartalmazó halmaz – egy eleme, így adódik, hogy Sj szimbólum felfogható a csatorna állapotaként is. Az információt a tárolás és az átvitel közben zavaró hatások érhetik, amelyeknek hatására, pl. az Si jel pi(j) nem zéró valószínőséggel Sj-re vál-tozhat. Ezt a bizonytalanságot az információelméletben zajnak nevezik. A valóságban teljesen zajmentes információs csatorna nem létezik.

Azonban valamely zajmentesnek feltételezett csatorna cellánkénti (fajlagos) információkapacitását – állandó jelhossz (tj = t, j = 1,…, n) esetében – az alábbi természetes alapú logaritmus függvény-nyel szokták jellemezni:

nkC ln= ,

ahol n a jelhalmaz elemeinek a száma és k egy arányossági tényezı. Az m pozíciót (cellát) tartal-mazó információhordozó egységnek a lehetséges állapotkombinációinak a száma nm, vagyis ennyi különbözı információ befogadására alkalmas. Ennek az egységnek az információkapacitása

nmkmCC m ln)( == .

A logaritmus-függvény alkalmazásával ily módon az m, n és a C közötti összefüggés leírható. Pél-dául ha n = 27 és m = 50, akkor (mivel ln 27 = 3,2959):

kkC 1653,350)50( =×= .

A csatornakapacitás egységének a bináris csatorna fajlagos kapacitását (n = 2) alapul véve

12ln =k .

Ebbıl

4428,16931,0

1

2ln

1===k .

Így általában egy csatorna fajlagos információkapacitása

2ln/lnnC = .

És mivel

nn 2log2ln/ln = ,

nC 2log= .

A vállalatirányítási információs rendszerek gazdaságtana

9. oldal

Amennyiben az információt reprezentáló jelrendszer (vagyis az „alfabéta”) 27 jelbıl áll, akkor információs kapacitása:

76,427log27ln 2 === kC bit/betőhely.

A bináris csatorna fajlagos információkapacitását tekintve egységnek, a csatornakapacitást általá-nosan „bit” egységekben fejezhetı ki.

A kapacitást nem t egységekben, hanem természetes fizikai hossztartam egységekben az alábbiak-ban fejezhetı ki:

nlogt

1C 2= (bit/sec, bit/mm, stb.).

2.1.2. A közleményforrás entrópiája

A továbbítandó közlemény úgy tekintendı, mint egy meghatározott számú lehetséges közlemé-nyeket tartalmazó halmaz egyik eleme. E megszorítás bevezetése lehetıvé teszi a valószínőségek egyszerőbb számítását, ugyanakkor nem vezet a kombinatorikai tér jelentıs csökkentéséhez, hi-szen a közlemények hossza nem került korlátozásra. Így akár egy jelbıl álló közlemények is ösz-szeállíthatóak, amelyek összeadva már nem korlátozódnak az eredeti közleményhalmaz elemeire. Ezek alapján a közlemény átvitele mindig abból áll, hogy a közleményforrásban létrejöhetı köz-lemények halmazából kerül kiválasztásra egy meghatározott közlemény. Legegyszerőbb esetben – a csatornakapacitás egységének meghatározásához hasonlatosan – két közleményre korlátozódik a választási lehetıség. A választás legyen véletlenszerő, azaz az egyes közlemények elıfordulásá-nak valószínősége ½. Például legyenek a közlemények a Fej vagy írás címő játék eredményei. Eb-ben az esetben a továbbított információ tartalma, azaz mennyisége (fej vagy írás; 0 vagy 1) azo-nosnak tekinthetı a bináris csatorna fajlagos kapacitásegységével (biner egység = bit). Ez alapján bevezethetı a H információhányad (információmennyiség) fogalma, és az – a kapacitáshoz ha-sonlóan – logaritmus függvénnyel írható le.

Egy n darab elemet tartalmazó jelhalmaz felhasználásával készített közlemény esetében minden pozíciónál az egyes jelek megjelenési valószínősége: pi = 1/n. Amennyiben n a 2 valamilyen egész számú kitevıje, akkor bekövetkezik az a feltétel, ami alapján valamelyik jel választása megegyezik a kiindulási halmaz mindaddig tartó felezésével, míg csak két egyelemő halmaz nem lesz, azaz a felezések visszavezethetıek két egyenlı valószínőségő esemény közötti választások sorozatára. A sorban egymást követı részhalmaz-csoportokban a jelek száma:

n , 2/n , 22/n ,…, 12/ =Hn .

Ebbıl következıen

Hn 2= és nH 2log= .

Tehát n jelet tartalmazó készletbıl elıállított közlemény egy jelének információhányada megegye-zik az egymás után végrehajtott választások (felezések) számával.

Amennyiben elengedésre kerül az a megszorítás, hogy a jelek azonos valószínőséggel fordulnak elı (p1, p2), de a vizsgálat kedvéért csak kettıre szorított jelkészlet esetén (A1, A2) a következı képpen vezethetı le az m jelet tartalmazó közlemények információhányada (H(m)).

Az A1 jel elıfordulási valószínősége p1, A2 pedig p2. Amennyiben m→∞, akkor jó közelítéssel elmondható, hogy minden közlemény p1m számú A1 és p2m számú A2 jelet tartalmaz. Az egyes közlemények a jelek elrendezésében különböznek egymástól, de minden közlemény azonos való-színőséggel fordul elı. E független események bekövetkezésének valószínősége:


10. oldal

mpmpppp 21

21 += ,

ahol 121 =+ pp és 1p , 02 ≥p .

Innen a ténylegesen elıfordulható, különbözı közlemények M száma:

pM

1= .

Így az egyes közlemények H(m) információmennyiségének meghatározása visszavezetésre került az elıbbi feladatra, vagyis most n helyett M számú azonos valószínőségő esemény közötti választás-sal nyert információmennyiséget (egy közlemény információhányadát) kell meghatározni, ami

M H(m) 2log= .

A közlemény egy-egy jelére esı információhányad pedig (bit/jel):

)loglog()log2log(1

log1

log1

2221212221122 pppppmppmpm

pm

Mm

H +−=+−=−== .

És általában a közlemény egy-egy jelére esı információhányad:

∑=

−==n

i

ii

m p p mHH1

2)( log / bit/jel.

Ez a mérték az eseményrendszer bizonytalanságának mutatója, vagyis a lehetséges események számának, illetve egy esemény „váratlanságának” várható értéke, amit Weiner és Shannon az átla-gos információmennyiség, az információhányad mérésére vezettek és a termodinamikai hasonló-ság miatt, entrópiának neveztek el. Tehát az információhányad esetünkben a közleményforrás entrópiája.

Ugyanakkor az entrópia a határozatlanság és a szervezetlenség mértéke, melynek okán fellépı bizonytalanságot oszlatja el a közlemény. A közleményforrás entrópiája a közlemények lehetséges kimeneteleinek sokaságából származó bizonytalanságból adódik, amelyet a közlemény által hor-dozott információmennyiséggel jellemezhetı. Egy üzenet megjelenésének a valószínősége fordí-tott arányban van az eseményrendszerrıl hordozott információinak a mennyiségével. Minél való-színőbb egy üzenet, annál kevesebb információt szolgáltat. Minél bizonytalanabb egy esemény-rendszer kimenetele, annál tartalmasabb információra van szükség ahhoz, hogy ismereteket lehes-sen szerezni róla.

Amennyiben a közleményt felépítı jelek statisztikailag függetlenek egymástól, azaz pj(j=1;…;n) elıfordulási valószínőségőek és tj=1 konstans tartalmú {Sj} jelhalmaz zajmentes csatorna, akkor a csatorna információhányada egyenlı lesz – az információelmélet megközelítésében – a pj eloszlás entrópiájával. Ebbıl az összefüggésbıl adódóan az entrópia az információhányad, azaz a közle-mény egyetlen jelére esı információmennyiség (fajlagos információtartalom) mérıszáma. Ez megfelelıen nagy léptékben az információ tartalmasságát jellemzi.

A még teljesen ismeretlen közlemény tartalmi bizonytalansága az entrópia. Amennyiben a közle-mény tartalma semmiféle határozatlansággal nem bír, azaz tartalma elıre ismert, akkor az entró-pia értéke nulla (Hmin=0). Azonban minél nagyobb egy eseményrendszer bizonyos állapotának a határozatlansága, annál nagyobb értékkel bír az eseményrendszer állapotáról információkat hor-dozó közlemény. Minden információszerzésnek az a célja, hogy a beérkezı közlemények infor-mációtartalmának megismerésével csökkentsük valamely eseményrendszer kimenetelének bizony-talanságát.


11. oldal

Értelemszerően az entrópia nem lehet nagyobb a fajlagos csatornakapacitásnál, szélsıséges eset-ben is csak legfeljebb Hmax=C összefüggés lehet igaz, amibıl az alábbi reláció írható fel:

nH 2log0 ≤≤ .

Az entrópia és a bizonytalanság, azaz a fajlagos csatornakapacitás elméleti maximális értékének hányadosa adja a viszonylagos entrópiát, ami egyúttal a tömörítési tényezı is (H/Hmax).

A redundancia azon felesleges információk viszonylagos mennyiségét adja, amely a kódrendszer szerkezetébıl adódóan belekerül a közleménybe. Egy zajos csatornában – ahol torzulások érik az eredeti üzenetet – jelentıs szerepe van a jól tervezett redundanciának, hiszen a helyes ütemő is-métlések segítenek a zaj hatására helyenként megváltozott üzenet eredeti tartalmának megismeré-sében. Természetesen ezzel együtt csökkeni fog az információhányad értéke is.

Egy közlemény tömörítése a redundáns jelek csökkentésével, teljes megszőntetésével érhetı el. Azaz az eredeti közlemény felosztható a viszonylagos entrópiával jellemzett tartalmas információ-ra és a redundancia (R) által meghatározott részre. Ebbıl következıen igaz az alábbi összefüggés:

C

HCHHR

−=−= max/1 .

Az R egy dimenziónélküli szám, és értéke 0 és 1 között mozoghat:

10 ≤≤ R .

Az elızıekben M-mel került jelölésre az m betős jelcsoportok azonos valószínőséggel elıforduló teljes számát. Az egyes jelcsoportokban azonos valószínőséggel elıforduló betők esetén az M-et, az nm hatvánnyal fejezhetı ki. Ez az érték a csatornakapacitás, és az összes lehetséges közleményt tartalmazza. Azonban az értelmes közlemények száma általában kevesebb és soha sem nagyobb mint a csatornakapacitás:

MNm ≤ , illetve m

m nN ≤ .

Legyen az értelmes információk mennyisége I(m), ami – a fentiekhez hasonlóan – az Nm logaritmi-kusaként definiálható:

)(22)( loglog m

mm CnmNI =≤= .

A jelcsoport egyes jeleire jutó értelmes információhányad:

CI ≤ .

Bármelyik értelmes információ tárolásához szükséges legkisebb pozíciószámú (u) csatornára felír-ható az alábbi összefüggés:

u

m nN ≤ ,

ahol u az a legkisebb egész szám, amely ezt a feltételt kielégíti. Ezek alapján megtehetı, hogy az m pozíciós értelmes közleményeket egyenként megfeleltetünk egy u hosszúságú jelkombinációnak. Ezzel lényegében az eredeti, kiindulási információ kódjának tömörítése alakult ki. Az u segítségé-vel meghatározható a szükséges fajlagos kapacitás is:

nCnm

u22 loglog =< .

Az információelméletben az információtartalmon azt a – szintén bit egységekben kifejezett – C(u)min legkisebb kapacitást jelenti, amelyben az információ még reverzibilisen kódolható. Az eh-hez tartozó kódolási rendszert optimális kódnak nevezik. Ez többnyire változó hosszúságú jelso-rozatokkal tehetı meg a legjobb hatásfokkal. Ekkor a sőrőn elıforduló, nem váratlan eseménye-


12. oldal

ket a lehetı legrövidebb, míg a ritkán elıforduló, váratlan eseményeket hosszabb jelsorozatokkal kódolhatóak.

A menedzsment információs rendszerekkel kapcsolatban az információelméletnek elsısorban a különféle kódolási rendszerek kialakításában van szerepe. Ezen túlmenıen pedig szemléleti segít-séget ad a velük végzett munkában.

2.2. A VÁLLALATIRÁNYÍTÁSI RENDSZEREK SZERVEZETI MEGKÖZELÍTÉSE

2.2.1. A vezetıi szintek és információs igényeik

A cselekvéseket meghatározó információkat célorientált tudásként értelmezhetjük. Egy vállalat esetében ez azt jelenti, hogy a hierarchia különbözı szintjein található vezetıknek más és más információra van szükségük ahhoz, hogy a folyamatokról megfelelı képet kapjanak, és helyesen határozzanak. Az információ a címzettet cselekvésre, meghatározott tevékenységre és nem utol-sósorban gondolkodásra készteti. Azonban az információ ösztönzı erejét erısen befolyásolja az információ vevıje.

A menedzsmenten belül három alapvetı szintet különböztetünk meg:

− felsı szintő vezetés, − közép szintő vezetés, − alsó szintő vezetés.

Mindhárom vezetıi szinten más súlyozással szerepelnek a menedzser funkciók, és más-más igé-nyeket támasztanak az információkkal szemben is. Azonban az egyes szinteken nemcsak felhasz-nálódnak az információk, hanem keletkeznek is. Ezzel növelik az egymásrautaltságot, és hatéko-nyabb együttmőködésre ösztönözi a felhasználókat.

A felsı szintő vezetı döntései hosszú távra szólnak, stratégiai jellegőek és alapvetıen befolyásol-ják a szervezet céljait. A négy menedzser funkció közül az idejének nagy részét tervezéssel és szervezéssel tölti. Összegzett információkra van szüksége a szervezet múltbeli és a jelenbeli ope-ratív helyzetérıl és a jövıbeli projektekrıl. Ezen információkat belsı forrásból kapja meg, de szüksége van külsı információkra is a környezetbıl. Tudnia kell az ágazati trendekrıl, a világ gazdasági történéseirıl, a kormányzati szabályozásról és minden más eseményrıl, ami befolyással lehet a szervezet mőködésére.

A közép szintő vezetı mind a négy menedzsment funkciót ellátja és a rövid távú, taktikai dönté-sekre koncentrál. Döntéseivel, amit a felsı vezetés ellenıriz az összes vállalati célt meg kívánja valósítani. Munkája olyan területekre terjed ki, mint például a költségvetés, ütemezés, teljesít-mény-ellenırzés. Ennek megfelelıen pontos adatokra van szüksége a múltból és a jelenbıl, hogy azokat összehasonlítva beavatkozzék, ha szükséges. Fıleg belsı információkra támaszkodik, de néhány külsı információra is szüksége van.

Az alsó szintő vezetı a napi irányítást látja el. İ felelıs a taktikai döntések végrehajtásáért, ame-lyet a közép szintő vezetı felügyelete mellett lát el. Olyan információkra van szüksége, amelyek a napi tevékenység során keletkeznek és valamely speciális terület alapadatai.

2.2.2. Információs szolgáltatás a menedzsment információs rendszeren keresztül

Mind a három szinten dolgozó menedzser a szervezet céljainak megvalósításán dolgozik, de eh-hez különbözı információkra van szükségük, mint azt az elıbbiekben láttuk. Az információk gyakran jelentések formájában jelenik meg a menedzserek asztalán. A menedzsment információs rendszerek alapvetıen négyféle jelentéseket állítanak elı a döntéshozó számára: elırejelzı, speciá-lis, eseti, idıszaki.


13. oldal

Az elırejelzı jelentések segítenek a felsı szinten dolgozó menedzser számára képet alkotni a jö-vıbeli folyamatokról. Ezen jelentések tartalmazhatnak széleskörő adat-analíziseket, de többnyire csak adatok. A jelentésben szereplı információk alapján a menedzser képes lesz a „Mi lesz, ha…?” típusú kérdések megválaszolására.

Speciális jelentések akkor kerülnek kibocsátásra, ha a menedzser egy bizonyos területet vagy hely-zetet akar megvizsgálni. Legtöbbször adatokat és analíziseket tartalmaz. Ilyen helyzet például, ha egy vállalkozásnál összeomlik a költségvetés. A felsı- és a középvezetés is használ speciális jelen-téseket.

Eseti jelentést leginkább középvezetık kérnek akkor, ha valamelyik mutató vagy adat szélsısége-sen eltér a megszokottól. Ezzel a jelentéssel veszélyessé válható folyamatokat szőrhetnek ki.

Az idıszaki jelentés a leggyakrabban használt jelentésféle. A jelentésben található adatok vonat-kozhatnak egy napra, egy hétre, egy hónapra vagy bármekkora idıszakra, amit indokolttá tesz az ügymenet. Például egy az értékesítésrıl készült idıszaki jelentés bemutatja az egyes termékekbıl eladott mennyiségeket, utána ezt összehasonlítva egy hasonló témában régebben készült elırejel-zı jelentéssel pontosíthatók az elırejelzések.

2.2.3. A vállalati információs rendszerekkel kapcsolatos elvárások, követelmények

A vállalati információs rendszerek a következı feladatokat vállalják fel magukra a problémák enyhítésére:

─ csökkenti a vezetıhöz jutó információk mennyiségét, ─ ugyanakkor lehetıvé tenni a tetszıleges mélységő hozzáférést, ─ növelni a vezetıhöz érkezı információk lényegszerőségét, idıszerőségét, használható-

ságát, és aktualitását, ─ összpontosítania a vezetés figyelmét a cég kritikus sikerfaktoraira, ─ növelni a vezetıi, irányítói munkát, nyomon-követést és kommunikációt, ─ megtalálni a változtatáshoz szükséges legkorábbi jelzı tényezıt, ─ figyelni a versenyhelyzet változásait, fogyasztói igényeket stb.

A vállalati információs rendszer nem zavarja a vezetı munkastílusát, ellenkezıleg: annak haté-konyságát növeli. A vállalati információs rendszer egy lehetıség arra, hogy a vezetés könnyebb és hatékonyabb módon hasznosítsa a rendelkezésre álló információkat.

A vállalati információs rendszer minden olyan rendszer, ami gondoskodik arról, hogy az emberek az adatokkal vagy az információkkal együtt kapcsolatban legyenek a szervezet operatív irányításá-val. A vállalati információs rendszer felkínálják azt a lehetıséget, hogy a dolgozókkal, a tulajdono-sokkal és az ügyfelekkel kapcsolatos adatokat feldolgozza, segítse az egyes szereplık közötti ügy-letek lebonyolítását és információkkal lássa el az erre illetékes embereket. Ugyanakkor fontos megjegyezni, hogy az információs rendszerek hatékonyságát nem az információk mennyiségének növelése, hanem a szőrése határozza meg.

A vállalati információs rendszerekkel szemben támasztott legfontosabb követelmények:

a) Az információ:

− elégítse ki a különbözı vezetıi szintek igényeit, − ne tartalmazzon felesleges adatokat, − küszöbölje ki a párhuzamos feldolgozást, − jelentıségének megfelelıen csoportosítható és továbbítható legyen, − legyen egyértelmő és összehasonlítható!


14. oldal

b) Az információkkal szemben a vezetık támasszanak olyan igényt, hogy:

− megbízhatóak legyenek, − alkalmasak legyenek elemzésre, következtetések levonására, − az információs rendszer rugalmas legyen, a követelményekhez gyorsan alkalmazkodjon, − feldolgozásuk, továbbításuk tudományos módszerekkel, korszerő eszközökkel valósuljon

meg!

c) Általános elv, hogy minden információnak ott kell megjelennie, ahol arra szükség van.

d) Gondoskodni kell az információk ellenırzésérıl is.

Egy másik megközelítésben az információs rendszereknek a következı feltételeknek kell megfe-lelnie:

− teljesség, − valódiság, − idıazonosság, − egyértelmő elrendezés, − rugalmasság, − ellenırizhetıség, − biztonság, − gazdaságosság.

Egy információs rendszer akkor tekinthetı teljesnek, ha a rendszer szabályozásához, vezérléséhez szükséges valamennyi lényeges elemet, ezek logikai és mennyiségi összefüggéseit megfelelı szer-kezetben tartalmazza. A kezelhetıség szempontjából elkerülhetetlen, hogy bizonyos egyszerősíté-seket tegyünk, de ezekkel az egyszerősítésekkel pontosan tisztában kell lennünk.

2.2.4. A vállalatok innovációs készsége az információ-menedzsment területén

A tanulási folyamatok megvalósítására való készség szorosan összefügg az innovációk befogadá-sának készségével. Habár az új cselekvési alternatívák használatára való készség emberenként változó, mégis ebbıl a szempontból különbözı kategóriákba lehet sorolni az embereket. Egy-részrıl léteznek nézeteket irányító és hamar befogadókész személyek. Egyes háziasszonyok az elsık között vannak, akik az új termékeket kipróbálják, és egyes gazdák a többi gazda elıtt pró-bálnak ki új termelési eszközöket. Azonban éppen így lehet olyan egyéneket is találni, akik az innovációkat csak sokkal késıbb fogadják el.

Ezek a különbségek ösztönözték ROGERS-et arra, hogy öt megkülönböztetett befogadó kategó-riába osztályozza az egyéneket (ROGERS 1962), melyet az 1. ábra mutat be. Az idı függvényé-ben vizsgált valószínőségeket, hogy az egyének befogadják az innovációkat, normál eloszlásúnak tekintette. A 0 idıpontban jelenik meg elıször egy innováció. Egy lassú növekedés mentén fo-gadja el egyre több egyén az innovációt. Számuk végül elér egy maximum pontot, majd ismét csökkenni kezd. Mind az empirikus, mind az elméleti (teoretikus) tudományok alátámasztják a megadott normáleloszlást.

A normáleloszlás függvény integrálja megadja az eloszlásfüggvényt, melyet az 2. ábra szemléltet. Az eloszlásfüggvény megmutatja, hogy egy bizonyos idı alatt egy populáció mely része fogadta el az innovációt. Minél intenzívebben növekszik az s-formájú eloszlásfüggvény, annál gyorsabban terjed el az innováció adaptálásának folyamata.


15. oldal

0

0,1

0,2

0,3

0,4

0,5

0 2 4 6 8 10 12 14

Idı

Befogadók hányada

A B C D E

0

0,2

0,4

0,6

0,8

1

0 2 4 6 8 10 12 14

Idı

Befogadók halmozott hányada

1. ábra: Egy innovációk befogadóinak osztályozása a relatív befogadási idı alapján

2. ábra: Egy innováció befogadóinak hányada az innováció megjelenése után eltelt idı függvényében

ROGERS nevéhez főzıdik az a kísérlet is, melynek során az öt befogadó kategóriába tartozó egyének szubjektív értékfogalmát leírta. Az innovátorok (A) nagy értéket tulajdonítanak a kalandos-ságnak. Szívesen próbálnak ki új dolgokat, még akkor is, ha egy bizonyos kockázat is társul ezek-hez. Világvárosi beállítottságúnak tartják magukat. A korai befogadók (B) számára az elismertség szerepel az elsı helyen. Ezek az emberek irányítják közösségük véleményét, és az új ötleteket bár hamar, de megválogatva fogadják be. A korai többségbe (C) tartozó egyének az elıvigyázatosságra helyeznek hangsúlyt. Habár az új ötleteket átlagosan még ık is korán fogadják el, ritkán számíta-nak azonban véleményirányítóknak. A kései többségbe (D) tartozók szkeptikusak. Egy innovációt csak akkor fogadnak el, ha a többség véleménye alátámasztani látszik annak hasznosságát. A kései befogadók (E) nagy értéket tulajdonítanak a hagyományoknak. Gyanakvóan állnak szembe a válto-zásokkal, más hagyományokhoz ragaszkodó társaikkal tartanak össze, és csak akkor fogadnak el egy innovációt, ha egy bizonyos mértékben már az is hagyománnyá vált.

Annak a megállapításnak, hogy konkrét esetben mely egyént mely befogadó kategóriába kell so-rolni, igen nagy gyakorlati jelentısége van akkor, ha egy mezıgazdasági szaktanácsadó új termelé-si eljárást szeretne bevezetni a gazdák körében, vagy ha egy vállalat, amely új mezıgazdasági válla-lati eszközt állít elı, amilyen hamar csak lehet, el szeretné terjeszteni a gazdák körében ezeket az innovációkat. A szaktanácsadó, vagy a vállalat nem az innovátorokhoz fog fordulni, mert azokat éppen vidéken, ahol „mindenki ismer mindenkit”, gyakran kissé megmosolyogják. Ha ezek az emberek egy új innovációt alkalmaznak, akkor fennáll a veszély, hogy ezt az innovációt, mint „félig kész” ötletet elvetik. A megfelelı célcsoport sokkal inkább a korai befogadók. A többiek elfogadott véleményalkotóknak, illetve példaképeknek tekintik ıket. Ha ık egy innovációt alkal-maznak, akkor a termelési eljárásnak, vagy a termelıeszköznek magas hihetıséget kölcsönöznek, és ezzel elérik, hogy a többi gazda az innováció tekintetében magasabb szubjektív bekövetkezési valószínőséget tulajdonítson a cselekvési alternatíva sikerének.


16. oldal

2.3. AZ INFORMÁCIÓ GAZDASÁGI HASZNOSSÁGÁNAK MÉRHETİSÉGE

Azt már láttuk, hogy a menedzsment információs rendszerek jelentéseket készítenek, de ebbıl még nem következik az, hogy az így kapott új információk használhatóak is. Egy jelentés értéke a döntési folyamatban dıl el.

Az információval szemben támasztott követelmények: érkezzék idıben, legyen teljes körő, ne tartalmazzon pontatlanságot és legyen könnyen értelmezhetı. Az összes fontos információ hasz-nálhatatlan, amit ma kapunk, ha tegnap kellett döntenünk. A menedzsernek nincs ideje arra, hogy hosszú listákat nézegessen, és birkózzék a papírtengerrel. Az információs rendszerbıl származó jelentésnek csak azokat az információkat kell tartalmaznia, ami a döntés szempontjából fontos.

Az információ minıségét alapvetıen befolyásolja, hogy mennyibe kerül az elıállítása és az, hogy mennyire értékes a felhasználó számára. Meg kell vizsgálni a szervezeten belüli teljes információ-áramlást, és csak a legjobban használható információkat állítsa elı a rendszer.

2.3.1. Az információ, mint termelési tényezı

Termelési tényezınek nevezzük a termelés erıforrásait, amelyek megkülönböztethetıek egymás-tól aszerint, hogy milyen funkcióval vesznek részt a javak és szolgáltatások elıállításában.

Az egyes termelési tényezık és jövedelmeik:

─ Munka (munkabér) ─ Természeti tényezık (járadék) ─ Tıkejavak (kamat) ─ Vállalkozói szolgáltatás (gazdasági profit) ─ Információ (mőködési profit)

A termelési tényezık csoportosítása eredetük, keletkezésük szerint:

ELSİDLEGES (Primer) − Ember

− Munka − Vállalkozói képességek

− Természeti erıforrások − Megújuló (föld, szél, nap) − Nem megújuló (bányakincsek)

TİKETÉNYEZİK (Szekunder)

− Termelt tıkejavak − Humán tıke − Reál tıke

− Kölcsöntıke − Pénz − Értékpapír

INFORMÁCIÓ (Tercier)

Származtatott erıforrás, önmagában nincs jelen, az a megvalósulása számít, amivel hozzásegíti a többi tényezıt az értékteremtésben.

A közgazdaságtan egyik legfontosabb kérdése a szőkös erıforrásokkal való gazdálkodás. Adott döntési szituációban a döntéshozó nem rendelkezik az összes információval, azok szőkösen áll-nak rendelkezésre. A döntéshozó változókra gyakorolható hatása alapján megkülönböztetünk


17. oldal

döntési, perdeterminált és bizonytalan változót. Döntési változó esetében a változó értéke ismert döntés alapján befolyásolható. Perdeterminált változó értéke ismert döntéssel nem befolyásolha-tó. Bizonytalan változó esetében még az érték sem ismert.

2.3.2. A teljes körő információ értéke

Egy döntéshozó a döntés pillanatában nem rendelkezik teljes körő információval a várható kör-nyezeti viszonyokról, a döntést befolyásoló tényezık jövıbeli értékeirıl. Így döntését csak ahhoz a cselekvési alternatívához tudja igazítani, amely esetében – hosszabb idıtartam elteltével vizsgál-va – a legkisebb a tévedés nagysága. A kockázatra közömbös döntéshozó ezért azokat a cselekvé-si alternatívákat választja, melyek esetében az eredmények várható értéke a legmagasabb. Ez a döntés azonban azt is jelenti, hogy a hosszú távon átlagosan elért eredmény kevesebb lesz annál a pénzösszegnél, amelyhez a döntéshozó akkor jutna hozzá, ha a környezeti viszonyok változásait mindenkor elıre biztosan meg tudná mondani. Ebben az esetben mindenkor azt a döntési alter-natívát választaná, mely esetében a környezet biztos változásának hatására a legnagyobb ered-ményt lehet elérni.

Az 1. számú táblázatban található mintapélda segítségével megismerhetı az alapprobléma, és az a-posteriori valószínőségek segítségével hozható megoldás. A táblázat egy elképzelt döntési szitu-ációt tartalmaz, természetesen egyszerősített formában, hogy a lényeges részeket jobban ki lehes-sen emelni. A példában egy kukorica termesztı gazdának kell arról döntenie, hogy mekkora te-nyészidejő kukoricát vessen el – a1, a2, a3 cselekvési alternatívák – annak függvényében, hogy milyen idıjárással számolhat a kukorica fejlıdése alatt. A modell könnyebb megérthetısége okán a kukorica árát nem tesszük függıvé az idıjárás piacra gyakorolt hatásától, hanem biztos 22,00 Ft/kg-os árat alkalmazunk az eredményszámítás során (táblázat, 1-es blokk). Ezután csak az a1, a2, a3 cselekvési alternatívákat kell vizsgálni, amelyekhez a becsült termésátlagokat az éves csapa-dék (száraz, normál, csapadékos) diszkrét értékeinek függvényében adja meg a 2-es blokk. Az 1-es és a 2-es blokk adataiból jön létre a 3-as blokk eredménymátrixa. A különbözı környezeti állapo-tok bekövetkezési valószínőségeit u1, u2 és u3–al jelöljük, melyek az elmúlt ötven év tapasztalata alapján 0,16, 0,64 és 0,20 értékeket vesznek fel. A 3-as blokk utolsó sora az a1, a2, a3 cselekvési alternatívák LAPLACE-BAYES-elv alapján számított várható értékeit tartalmazza. A kockázatra közömbös döntéshozó az a3-as alternatívát választaná, mert ez a változat a 76,76 eFt/ha-os ér-tékkel a legmagasabb várható értéket nyújtja.

Hosszabb idıtáv átlagában is ezt a várható értéket, mint fedezeti hozzájárulást kapná meg a dön-téshozó, mivel a környezet állapotában megjelenne a gyakoriság, mely megfelel a bekövetkezési valószínőségek értékeinek. Feltételezzük tehát, hogy a gazda az a-priori környezeti viszonyainak bekövetkezési valószínőségeinek becslésénél figyelembe vette – természetesen egy elegendıen hosszú idı alatt – az a-posteriori környezeti viszonyainak bekövetkezési valószínőségeit.

A meghatározott cselekvési alternatívák közül a várható érték kritériuma alapján az a3-assal jelölt eredményezi a legnagyobb eredményt, így az ehhez tartozó átlagos fedezeti hozzájárulás értékek kerülnek a táblázat 4-es blokkjának „kezdeti INFO” oszlopába.

Ezzel ellentétben, ha a gazda a bekövetkezett környezeti viszonyokat mindenkor pontosan, még a mindenkori kukorica vetése elıtt elıre tudná jelezni, akkor többé-kevésbé gyakrabban váltogatná a cselekvési alternatívákat. A 3-as blokkból látható, hogy egy szárazabb évben (u1) a gazda az a1-el jelölt alternatívát választaná, mivel ez a 66,50 eFt/ha-os értékkel a legmagasabb fedezeti hozzá-járulást adja. Egy átlagos évben (u2) vagy az a2-vel vagy az a3-al jelölt alternatívát, egy csapadéko-sabb évben (u3) pedig az a3-al jelölt alternatívát választaná. A környezeti viszonyok mindenkori legjobb eredményeit a táblázat 4-es blokkjának „biztos INFO” oszlopa tartalmazza. Ha a környe-zeti viszonyok egy hosszabb idıtáv alatt 0,16, 0,64 és 0,20 gyakoriságokkal következnek be, akkor ebbıl az elérhetı fedezeti hozzájáruláshoz kiszámítható a 78,28 eFt/ha értékő súlyozott átlag (amely formálisan megfelel a várható értéknek). Ez az érték 1 520 Ft/ha-ral több mint a várható


18. oldal

érték, amely a nem teljes körő információk mellett érhetı el. A gazda tehát ebben az esetben egy teljes körő éves idıjárás-elırejelzésre 1 520 Ft/ha értékig fordíthatna rá, mielıtt a nem teljes körő információk mellett gazdálkodna tovább. Egy olyan gazda például, aki évente 100 ha kukoricát termeszt, ennek megfelelıen évente közel 152 000 Ft fordíthatna egy ilyen idıjárás-elırejelzésre. A teljes körő információ értéke tehát a termelés volumenével arányosan növekszik.

2.3.3. A pontosabb információ Bayes-tétel alapján számított értéke

Aligha valószínő, hogy valaha is rendelkezésünkre állhat egy biztos idıjárás-elırejelzési rendszer. Elképzelhetı azonban egy olyan elırejelzési eljárás, melynek elırejelzései bizonyos valószínőség-gel következnek be.

A döntési szituáció magyarázataként vizsgáljuk meg a táblázat 5-ös blokkját. Ezesetben azt felté-teleztük, hogy a gazda, miután még egyszer megvizsgálta 50 éves idıjárási feljegyzéseit megállapí-totta, hogy az áprilisi idıjárás, ha azt szintén a három kategóriába: „száraz” (z1), „normál” (z2) és „csapadékos” (z3) soroljuk, az éves idıjáráshoz viszonyítva, 50 év távlatában a mátrixban feltün-tetett módon viselkedik.

A mátrix elsı sorából például kiderül, hogy 8 száraz évet (u1) tekintve az április 5 éven át volt száraz, 3 évben normál, de egyetlen évben sem volt csapadékosnak mondható. 32 normál évet (u2) tekintve 16 évben volt az április normál, 7 éven keresztül száraz és 9 éven át volt csapadé-kosnak mondható. Végezetül a 10 csapadékos évben (u3) 6 éven át volt száraz, 4 évben volt normál és egyetlen évben sem volt csapadékos az április hónapja.

Ezekbıl az adatokból azonnal látható, hogy az áprilisi és az egymást követı évek idıjárásai kö-zött bizonyos összefüggést lehet felfedezni, mely összefüggést idıjárás elırejelzéshez lehetne felhasználni, mivel az áprilisi idıjárás egybeesik a kukoricavetéssel így gazdasági elıny származhat ezen információk felhasználásából. A gazda nyilván azt szeretné, ha az idıjárások közötti össze-függések még szorosabbak lennének, de mindenesetre jobbak, mint ha az áprilisi idıjárások min-den évben egyenletesen oszlanának meg a három kategória (zk) között. Természetesen kívánatos lenne, ha minden száraz / normál / csapadékos évben az áprilisi idıjárás szintén száraz / normál / csapadékos lett volna. Ebben az esetben a gazdának – feltételezve, hogy az összefüggés a jövı-re is vonatkozik – tökéletes idıjárás-elırejelzési eszköz lenne a kezében. Az áprilisi idıjárások ismeretében évrıl évre biztosan elıre tudná jelezni az éves idıjárást és ennek megfelelıen kivá-lasztani a megfelelı cselekvési alternatívát.

A mátrixban megadott értékek azonban szintén hozzá tudnak járulni az elırejelzés pontosságának növeléséhez. Egy ilyen elırejelzés kidolgozásához mindenekelıtt a feltételes valószínőségeket kell kiszámolni arra az esetre, hogy egy bizonyos környezeti állapot (zk) bekövetkezésének hatására következik be egy másik következı környezeti állapot (uj). Ezeket a valószínőségeket, melyeket a-posteriori valószínőségeknek is nevezünk, hogy egyértelmően megkülönböztessük az uj környeze-ti állapot bekövetkezését kifejezı a-priori valószínőségektıl. Értéküket a Bayes-tétel alapján szá-moljuk ([2] LIPSCHUTZ, S. 1976). A feltételes valószínőség általában azt fejezi ki, hogy egy uj állapot akkor következik be, ha egy zk állapot már bekövetkezett:

)z(p

)zu(p)zu(p

k

kjkj

∩=

(1)


19. oldal

1. táblázat: Az a-posteriori valószínőségek figyelembe vétele a környezeti állapotok jobb elırejelzése érdekében a BAYES tétel alapján [1] KUHLMANN, F. (2003)

ADATOK: Szemes kukorica ára (Ák) [Ft/kg]: 22,00 1

Hozamtól függı költségek k(H) [Ft/kg]: 12,50

5 ADATMÁTRIX az (uj) és (zk) környezeti állapotok valószínőségeinek kiszámításához

2 ADATMÁTRIX a kukorica különbözı érési fázisainak /korai (a1), középko-rai (a2), középkései (a3)/ hektáronkénti hozama különbözı idıjárású években (uj) [t/ha]

Környezeti állapotok (zk)

(áprilisi idıjárás)

Cselekvési alternatívák (ai) száraz normál csapad.

környezeti állapot (uj) a1 a2 a3 (uj) z1 z2 z3 ∑uj p(uj)

hideg év u1 7,0 6,8 6,0 u1 5 3 0 8 0,1600

normál év u2 7,6 8,0 8,0 u2 7 16 9 32 0,6400

meleg év u3 8,2 9,3 10,0 u3 0 4 6 10 0,2000

∑zk 12 23 15 50 ∑(E)

p(zk) 0,2400 0,4600 0,3000 S(p) 1,0000

3 A fedezeti hozzájárulások (FH) EREDMÉNYMÁTRIXA, a kukorica külön-bözı érési fázisaiban (ai) a különbözı idıjárású években (uj); FH=(Ák-k(H))*Q; [EFt/ha]

6 EREDMÉNYMÁTRIX a (feltételes) a-posteriori valószínőségekhez p(uj/zk)=[p(uj…zk)]/p(zk)

Cselekvési alternatívák (ai) (zk)

környezeti állapot (uj) a1 a2 a3 (uj) z1 z2 z3

száraz év u1 66,50 64,60 57,00 u1 0,4167 0,1304 0,0000

normál év u2 72,20 76,00 76,00 u2 0,5833 0,6957 0,6000

csapadékos év u3 77,90 88,35 95,00 u3 0,0000 0,1739 0,4000

Várható érték q 72,43 76,65 76,76

4 EREDMÉNYMÁTRIX:

kezdeti INFO

biztos INFO

jobb INFO

7 EREDMÉNYMÁTRIX: A cselekvési alternatívák várható értékei (ai) különbözı környezeti viszonyok között (zk) [EFt/ha]

u1 *** 66,50 71,25 (ai)

u2 *** 76,00 76,83 (zk) a1 a2 a3

Hosszú távon várt átl. FH-k különbözı szintő információk mellett

u3 *** 95,00 83,60 z1 69,83 71,25 68,08

Átl. fedezeti hozzájárulás >> 76,76 78,28 77,52 z2 72,45 76,66 76,83

2. oszloptól mért különbség >> -1,52 -0,76 z3 74,48 80,94 83,60

A p(uj ∩ zk) az az együttes valószínőség, hogy az uj és zk állapotok együttesen következnek be; a p(zk) pedig az a valószínőség, hogy egy zk állapot bekövetkezik.

A végsı mintavételi helyek meghatározásához, mint ahogyan azok a gazdasági problémák eseté-ben minden szabályban megtalálhatók, és ahogyan az a mátrix 5-ös blokkjában az 50 vizsgált év-vel megadásra került, az egyesített valószínőség a (2)-es egyenlet alapján nagyon egyszerően meg-határozható.


20. oldal

E

zu)zu(p

kj

kj Σ

∩=∩

(2)

Az ΣE a mintavétel összege, mely a mi példánkban 50 évet ölel át, a uj ∩ zk pedig az esetek száma, melyek esetében uj és zk együttesen következnek be. A mátrixból látható, hogy például u1 ∩ z1=5 vagy u2 ∩ z2=16 stb.

A p(zk) valószínőség az (1)-es egyenlet nevezıjében a következı képpen határozható meg:

E

z)z(p k

k ΣΣ

= (3)

Azáltal, hogy az (1)-es egyenletbe behelyettesítjük a (2)-es és a (3)-as egyenletet eljutunk a végsı mintavételi helyhez, hogy meghatározzuk a feltételes valószínőséget:

k

kj

kj z

zu)zu(p

Σ

∩=

(4)

A feltételes valószínőségi értékeket a táblázat 6-os blokkja tartalmazza. Például a p(u1z1) érték a következıképpen számítható ki:

p(u1z1)=(5/50)/(12/50)=5/12=0,4167.

A feltételes valószínőségek p(ujzk) segítségével kiszámítható az ai cselekvési alternatívák várható értéke. Egy cselekvési alternatíva várható értékét úgy kapjuk meg, hogy az egyes ai cselekvési al-ternatívák esetében a különbözı uj környezeti állapotok (éves idıjárás) által meghatározott eji eredményeket a p(ujzk) feltételes valószínőséggel súlyozzuk (multiplikáljuk), annak érdekében, hogy a már bekövetkezett zk környezeti állapot (áprilisi idıjárás) hatása a különbözı uj környezeti állapotok bekövetkezési valószínőségére megjelenjen a várható értékben.

µ(a1,z1)=e11 ⋅ p(u1z1)+e21 ⋅ p(u2z1)+e31 ⋅ p(u3z1)

µ(a1,z1)=66,5 ⋅ 0,4167+72,2 ⋅ 0,5833+77,9 ⋅ 0,0000=69,83

A várható értékek kiszámítására tehát általánosságban a következı érvényes:

∑=

⋅=µm

1ikjjiki )zu(p e)z,a(

j=1,…,n; k=1,…,q (5)

Az ezzel a módszerrel számolt várható értékeket a táblázat 7-es blokkja tartalmazza. Ezt a mátri-xot arra használja a döntéshozó, hogy a mindenkori legjobb cselekvési alternatívákat határozhassa meg. A példában, ha z1 állapot következik be, akkor az a2 alternatívát kellene választani, mivel ez az alternatíva a 71,25 eFt/ha értékkel a legmagasabb várható értéket hozza. A z2 állapothoz és a z3 állapothoz is az a3-at kellene választani. A sorok 3 maximális várható értékét a 4-es blokk „jobb INFO” oszlopa tartalmazza.

Ha számításba vesszük azt, hogy a z1, z2 és z3 állapotok z1=0,2400, z2=0,4600 és z3=0,3000 való-színőségekkel következnek be, akkor a sorok maximális várható értékeit ezekkel a valószínősé-gekkel súlyozhatjuk a 4-es blokkban, és az eredmények összegébıl a hosszútávú átlagos fedezeti hozzájárulást számíthatjuk ki, amely az áprilisi idıjárásról ismert információk következetes hasz-nálatával érhetı el. Az átlagos fedezeti hozzájárulás 77,52 eFt/ha-os értéke ugyan 760 Ft/ha-ral az uj környezeti állapotok biztos elırejelzésének értéke alatt van, de 760 Ft/ha-ral magasabb is annál az értéknél, amit akkor érnénk el, ha csak az a-priori valószínőségeket p(uj) használhatnánk. Abban az esetben, ha az áprilisi és az éves idıjárás között fennálló feltételezett kapcsolat valóban


21. oldal

helytálló, a gazda 720 Ft-ot adna hektáronként azért, hogy az áprilisi hımérsékleteket meghatá-rozzák. Ennek a jobb elırejelzésnek ez az értéke. Természetesen ez az érték is a termelés volu-menével arányosan nı. A nagyobb vállalatok tehát az információ használatában gazdasági elınyre tesznek szert.

A példából továbbá még azt is levezethetı, hogy a jobb elırejelzés annál értékesebb, minél szoro-sabb a kapcsolat a korábban ismert zk állapotok és az utólag bekövetkezett uj állapotok között.

2.3.4. A növekvı szabályozás-intenzitás értéke

A szabályozási folyamatok gazdasági értékelése során különbséget kell tenni eltérı gyakorisággal átfutó szabályozási köröket tartalmazó, azaz különbözı szabályozásintenzitással rendelkezı fo-lyamatokat. (KUHLMANN 1990, 41. old.). A gyakoribb és átfogóbb ellenırzések, a sőrőbb sza-bályozási átfutások hasznának értékeléséhez olyan becslési eljárás alkalmazható, amelyben a TÉNY értékek az output változók TERV értékeitıl való eltérései vagy termelıeszköz-pazarlást, vagy termékveszteséget jelentenek, tehát vagy a szükségtelenül üzembe helyezett vállalati eszkö-zök magasabb direkt költségeit, vagy az elmaradt termékmennyiség lehetıségi költségeit okozzák. Ezáltal, a szabályozásintenzitástól függıen különbözı nagyságú úgynevezett hibaköltségek kelet-keznek. Ezt az összefüggést a 3. ábra szemlélteti.

-80

-60

-40

-20

0

20

40

60

80

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160

Idı

B1

B2

Op

Anyagráfordítás

0

10

20

30

40

50

60

70

80

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160

Idı

B1

B2

Hibaköltség

3. ábra: Vállalati eszközráfordítás az idı és a szabályozásinten-

zitás függvényében 4. ábra: Hibaköltségek az idı és a szabályozásintenzitás függ-

vényében

Az 3. ábránál kiinduló pontnak kell tekinteni, hogy egy idıtáv alatt a termeléshez létezik egy bi-zonyos optimális anyagráfordítás, például a cukorrépa-ráfordítás a cukorgyártásban. Ezt az opti-mális anyagráfordítást az x-tengellyel párhuzamos Op egyenes adja. A cukorkivonó berendezés kezelıjének az általa irányított rendszer igen összetett input-output összefüggéseirıl való hiányos ismeretei, továbbá a cukorrépa, mint nem szabványosítható biológiai termék változó cukortartal-mának hatása miatt a tényleges anyagráfordítás állandóan eltér az optimális anyagráfordítástól. Minél gyakrabban ellenırzik a rendszert, annál gyakrabban korrigálható az anyagráfordítás, és annál alacsonyabbak lesznek az anyagpazarlás és az elmaradt haszon miatt keletkezı hibaköltsé-gek.

Abban a leegyszerősített esetben, amikor az eltérések meglehetıs rendszerességgel alakulnak ki, a tényleges anyagráfordítás gyakoribb ellenırzése mellett a B1 görbe alakulhat ki (a felhasználásra


22. oldal

kerülı mennyiséget 10, 30, 50,…, stb. idıpontokhoz mérjük és viszonyítjuk), miközben ritkább ellenırzés mellett a B2 görbe léphet érvénybe (a felhasználásra kerülı mennyiséget 30, 90, 150, …, stb. idıpontokhoz mérjük és viszonyítjuk). Egy bizonyos idı elteltével mindkét szabályozás-intenzitás (B1, B2) esetében a 6. ábrában feltüntetett hibaköltségek merülnének fel.

Ezeket a hibaköltség-görbéket egy bizonyos idıintervallumban integrálva megkapható a szabá-lyozásintenzitástól függı hibaköltségek összege, mely 7. ábrában feltüntetett módon rajzolható fel. A hibaköltségek összege a szabályozásintenzitás növekedésével csökken.

0

10

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120

Idı

Hibaköltség

5. ábra: Hibaköltségek összege a szabályozásintenzitás függvényében

Egészen hasonló eredményekhez lehet jutni, feltételezve, hogy a döntéshozó tanul a folyamatel-lenırzésbıl, és ezáltal, a zavarkompenzációs szabályozás elvének értelmében javítja a szabályo-zott folyamat inputjainak értékét. A döntéshozó ebben az esetben a 8. ábrán feltüntetett tanulási görbék mentén mozog, melyek megadják a mindenkor elért pénzhasznot, és közelítenek a maxi-málisan elérhetı nyereségszinthez. A tanulási görbék annál meredekebben ívelnek fölfelé, minél magasabb szabályozásintenzitást választ a döntéshozó, mint ahogyan azt a 8. ábrán felrajzolt há-rom görbe szemlélteti. Ekkor a hibaköltségek a 9. ábrán látható módon, az idı függvényében mutatják a maximális nyereséghez képesti eltérést, azaz elmaradt haszonként ábrázolhatóak. Ezen hibaköltségek által leírt görbére illesztett függvény egy bizonyos idıintervallumon számított integ-rálja megadja a hibaköltségek összegét a szabályozásintenzitás függvényében. Ezt szemlélteti a 7. ábra.

A különbözı szabályozásintenzitások hasznának becslése érdekében azonban figyelembe kell még venni azt, hogy ezek pótlólagos direkt költségeket okoznak az ellenırzésben. Amennyiben feltételezhetı, hogy ezek a költségek arányban vannak a szabályozásintenzitással, akkor a teljes szabályozás költsége, melynek összegét a direkt ellenırzési költségek és a hibaköltségek adják, egy u-formájú alakzatot vesz föl. Ezt az összefüggést a 10. ábra szemlélteti. Az optimális kontrollin-tenzitást a szabályozás összköltségének minimumából közvetlenül leolvashatjuk. Ebbıl a határ-nyereségek is levezethetıek, melyek akkor keletkeznek, ha egy korábban nem optimális szabályo-zásintenzitást az optimum irányába változtatnak.

A 10. ábra költséggörbéibıl látható még továbbá, hogy az optimális szabályozásintenzitást a hi-baköltségek nagysága és a direkt ellenırzési költségek befolyásolják. Ezt az összefüggést a 11. ábra tartalmazza. Amennyiben az ellenırzési folyamatonként csökkennek a darab/részköltségek,


23. oldal

tehát a direkt ellenırzési költségek egyenese kevésbé lesz meredek, akkor a kiindulási helyzetet mutató SK1 görbéhez képest egy példának vett SK2 görbe fogja a szabályozás összköltségét leír-ni. Az optimális szabályozásintenzitás Op1-rıl Op2-re változik. Másrészrıl, ha a szabályozás össz-költségének növekedését a hibaköltségek összegének növekedése okozza, akkor az SK3görbe mutatja be a tárgyalt összefüggést. Az optimális szabályozásintenzitás Op1-rıl Op3-ra növekszik.

0

20

40

60

80

100

120

0 20 40 60 80 100 120 140 160 180 200

Idı

Nyereség

0

20

40

60

80

100

120

0 20 40 60 80 100 120 140 160 180 200

Idı

Hibaköltség

6. ábra: Realizált nyereség az idı és a szabályozásintenzitás

függvényében 7. ábra: Hibaköltségek (elmaradt haszon) az idı és a szabályo-

zásintenzitás függvényében

Egyes esetekben a szabályozási eljárások költségeinek konkrét megállapítása közben mindenkép-pen nehézségekbe ütközik, általánosságban mégis megállapítható, hogy a szabályozás költségté-nyezıinek az imént felvázolt változásaira fordított figyelem a jövıben tovább fokozódik. Egy-részrıl az információs-elektronikában tett további lépések eredményeként az ellenırzés direkt költségei tovább csökkennek. Másrészrıl a vállalatok termelési volumenének tartós növekedése érzékenyebbé teszi a gazdálkodást a vállalat eszközráfordításában keletkezett hibák okozta, nomi-nálisan mind magasabb nyereségveszteségek tekintetében. Ezért a szabályozásintenzitások szere-pe a jövıben fokozatosan tovább fog növekedni.

SK1

SK2

SK3

0

20

40

60

80

100

120

140

160

180

200

0 20 40 60 80 100 120 140

Idı

Op1 Op3Op2

Hibaköltség

HK

DK

SK

0

10

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120 140

Idı

Op

Hibaköltség

8. ábra: Az optimális szabályozásintenzitás meghatározása 9. ábra: Optimális szabályozásintenzitás a szabályozási

költségnemek változó értéke mellett


24. oldal

2.4. A VÁLLALATI INFORMÁCIÓS RENDSZEREK GAZDASÁGOSSÁGA

Az elmúlt idıkben a vállalatvezetık csodafegyverként kezelték az informatikai fejlesztéseket, más beruházásokhoz képest elınyt élveztek, kisebb erıfeszítéssel lehetett anyagi forrásokat biztosítani számukra. Mára ez a folyamat lendületét veszítette, elıtérbe került az IT fejlesztések beruházás-gazdaságossági vizsgálata, megtérülésüknek értékelése. Azonban e fejlesztések speciális költség-összetevıi és rendkívül sajátságos haszon elemei az átlagosnál nehezebb feladatot jelentenek.

A beruházások értékelésére számos módszer ismeretes. A legelterjedtebbek közé sorolhatóak a jelenérték számítások (present value analysis), melyek különbözı szempontok alapján meghatározott diszkonttényezık (discount rate) segítségével megadják egy beruházáshoz tartozó pénzáramlás je-lenértékét. Ezek közül nevezetes mutató a nettó jelenérték (net present value) (NPV), mely számítá-sa során a pénzáramlás kezdeti értékét csökkentjük a beruházás összegével. Az a megkülönbözte-tett diszkonttényezı, melynél a változatlanul hagyott pénzáramlás nettó jelenértéke nulla, az lesz a beruházás belsı kamatlába internal rate of return (IRR). A beruházások forgási mutatói közül kiemelendı a return on investment (ROI) analysis, mely megmutatja, hogy a beruházás élettarta-ma az eredménybıl hányszor térül meg a kezdeti beruházási összeg. A beruházás-gazdaságossági vizsgálatok során szintén nagy jelentıségőek a megtérülési idıre vonatkozó számítások.

Ezen mutatók értelmezése az információs rendszerekkel kapcsolatos beruházások során, így a farm információs rendszerek esetében is számos nehézséget vet fel. A 80-as évek tudományos jellegő publikációi megálltak e mutatók tételes bemutatásánál, és nem foglalkoztak az alkalmazás során fellépı problémákkal. [Whitten, 1986] A 90-es évek végén lehetett találkozni a projekt szemlélető megközelítéssel, amely már komplexebben kezelte a gazdaságosság kérdését. [Bıgel 2003] Az elmúlt idıszak írásaiban azonban már lehet találni az információs rendszerek gazdasá-gossági számításaihoz kapcsolódó tételes levezetésekkel. [Fehér, 2006]

1.1.1. Az információs rendszerek költség-haszon összetevıi

Az információs rendszerek költségszerkezetének meghatározásakor kettı jelentıs költségcsoport különíthetı el. Az elsı és könnyebben kezelhetı költségek köre a számvitel által jól lehatárolt területre esik: számlák, számviteli bizonylatok és belsı elıállítású dokumentumok alapján szám-szerő értékük meghatározása nem jelent kiemelkedıen nehéz feladatot. Tételesen ide tartoznak az informatikai rendszer hardver elemeinek költségtételei (szerver oldal, kliens oldal, adatgyőjtési és adatátviteli infrastruktúra, stb.), valamint a mőködtetésükhöz szükséges szoftverek beszerzése.

A hardverek alapfunkcióinak ellátásához szükséges szoftverek megvásárlása és nyilvántartása könnyen kezelhetı és menedzselhetı; azonban a rendszerek tartalmi funkcióinak megvalósításá-hoz szükséges elemek kezelése már okozhat problémákat.

Célszerő elkülöníteni az úgynevezett „dobozos”, kész megoldásokat és az egyedi fejlesztéseket. Az elıbbi esetében a szállító cég által kiállított számlák jó alapot képeznek a tényleges költségek feltárására, azonban nem elfelejthetı, hogy az ilyen típusú projektek nem csak és kizárólag az informatikát, hanem a vállalat egész mőködését érinthetik. Ebbıl adódóan nehézzé válhat a pusz-tán informatikai fejlesztést érintı költségek meghatározása. Segítséget jelenthetnek a számlákkal együtt mozgó bizonylatok, projektdokumentáció, teljesítésigazolások. Ezen felül, további nehéz-séget okozhat azon erıforrások költségeinek meghatározása, amelyeket maga a vállalat tesz hozzá a projekt sikeréhez, az effektív munkán túl az egyes projektszerepek „tükrözése”.

Másik megoldás az egyedi fejlesztéső szoftverek kialakítása, amelyet szintén két úton lehet elérni: egy külsı programozó cég megbízásával, vagy saját kivitelezésben. Értelemszerően a második esetben nehezebb az információs rendszer kialakításához kapcsolódó költségek meghatározása, de egy alapos, a tényleges költségek feltárására törekvı elemzés meglepıen nehézzé válhat a saját ráfordítások tekintetében az elsı esetben is.


25. oldal

A költségek meghatározásának másik jelentıs körébe az információs rendszerek sajátságos költ-ségelemei tartoznak, melyek bizonylattal nem határozhatóak meg. Ezek egy része az adott rend-szerhez való lekötöttségbıl állnak, és a vállalat által nehezen befolyásolható, hiszen a folyamatos mőködés fenntartásához meg „kell” vásárolnia a lekötöttségbıl adódó termékeket, szolgáltatáso-kat. Az átállás költsége jelenti azt a pénzösszeget, amelyet, ahhoz szükséges kifizetni, hogy az adott vállalat hasonló informatikai támogatottság állapotba kerülhessen egy másik rendszer beve-zetésével.

10. ábra: Az információs rendszerek költségeinek csoportosítása a számviteli nyilvántarthatóság

alapján.

A bevétel, haszon értékelése még az elızıekhez képest is nagyobb problémát jelenthet. Ritka az az informatikai rendszer, amelyhez direkt módon bevételek köthetıek, azaz maga a vállalatirányí-tási informatikai rendszer a termelıeszköz. Jellemzıen a vállalatirányítási információs rendszerek a vállalat egészének mőködését, szervezését segítik, és jelentenek ma már nélkülözhetetlen alapot a döntések meghozatalában. Ebbıl adódóan gazdasági jelentıségükhöz nem férhet kétség, ugyanakkor számszerő értékekben kifejezhetı hasznot csak áttételesen, a vállalat alaptevékenysé-gének megvalósulásán keresztül termelnek. Azonban e számszerő értékek meghatározásától még-sem lehet eltekinteni, hiszen az egyes megoldások, alkalmazások összehasonlíthatóságához elke-rülhetetlenek, és rendszer-kiválasztási szempontokat is megvalósíthatnak.

1.1.2. IT beruházások TCO elemzése (Total Cost of Ownership)

Az informatikai fejlesztések önmagukban is meglehetısen bonyolultak lehetnek. Ezen túlmenıen azonban a gazdasági értékelésük, beruházás-gazdaságossági vizsgálatuk is jelentıs számú problé-mát vet fel. Egy lehetséges megközelítési mód, a beruházás teljes élettartama alatt, a fejlesztéshez kapcsolódó összes költség definiálása és mértékének meghatározása. Ezzel a módszerrel a tulaj-donláshoz tartozó teljes költség határozható meg.

Az informatikai fejlesztések különbözı mélységben hathatják át a vállalat mőködését. Az egysze-rő eszközbeszerzésektıl kezdıdıen az integrált vállalatirányítási rendszereken keresztül megje-lenhet magában a termékben is, elérheti akár a vásárlót is. Az egyes megvalósulási szintek eseté-ben a TCO számítás tekintetében is különbséget kell tenni.

Számvitel által meghatározható:

- hardver

- szoftver

Saját ráfordí-tások

Analitika által nem meghatározható:

- lekötés

- átállás


26. oldal

11. ábra: A különbözı szintő informatikai fejlesztések vállalatra gyakorolt hatása

1.1.2.1. IT fejlesztés alapesetei

Az információs technológia fejlesztésének legegyszerőbb példája az informatikai eszközpark ele-meinek cseréje, bıvítése, korszerőbb megoldások beszerzése. Ezek a fejlesztési elemek természe-tesen megjelenhetnek szoftver oldalon is: a meglévı programok frissítése, kiegészítı modulok vásárlása, egyedi fejlesztések, melyek a napi rutinokat támogatják. Ide tartoznak még az informa-tikát érintı auditok lefolytatása, szabályzatok készítése. Ezen fejlesztések az információs techno-lógia hatékonyságát javítják.

Ekkor a jelenleg meglevı informatikai infrastruktúra fenntartási költségei vethetıek össze, az új eszközök létesítési és mőködtetési költségeivel.

1.1.2.2. Üzleti folyamatok fejlesztése

Abban az esetben, ha az IT fejlesztés során érintjük az üzleti folyamatokat is, a rendszer hatásos-ságának kérdésével is foglalkozni kell. Ezek a fejlesztések az egész vállalkozásra kiterjedı változá-sokat magukban foglaló, komplex projektek keretében valósulnak meg. Ekkor az informatikai fejlesztés célja az egész vállalati tevékenység átlátása, az egyes funkcionális területek integrált meg-jelenítése. Mivel ezen informatikai beruházások évekre jelentı elkötelezettséget kívánnak, ezért ezt megelızıen célszerő az üzleti folyamatok újraszervezése (BPR), hogy a kialakításra kerülı rendszer, már a következı idıszak kihívásaihoz, feladataihoz a lehetı legjobb vállalati mőködés leképezésére legyen képes. Ezek a projektek jellemzıen ERP (Enterprise Resource Planning) és BSC (Balanced Scorecard) rendszerek bevezetését szolgálják.

A gazdaságossági vizsgálat során el kell különíteni az integrált rendszer saját költségeit, melyek jól közelíthetıek TCO modell készítésével, és az IT fejlesztés a szervezet költség-haszon elemeire gyakorolt hatását. Ez utóbbi vizsgálata túl nyúlik a TCO keretein, de a TCO által képviselt értéke-lési szemléletmód segítséget jelent a további elemzések megalapozottságának biztosításában.

1.1.2.3. Termék és szolgáltatás-fejlesztés

A vállalatok jelentıs részének piaci pozíciójuk és gazdasági erejük megırzéséhez idırıl-idıre, vagy folyamatosan erıfeszítéseket kell tennie termékeik és szolgáltatásaik fejlesztésére. Ezen fej-lesztési projektek ma már nehezen képzelhetıek el informatikai támogatás nélkül, sıt gyakorta meghatározó erıforrásként szerepelnek benne. Adott esetben az innováció magára az informáci-ós technológiára irányul: új értékesítési csatornát teremt, vagy megjelenik magában a termékben, a szolgáltatás részévé válik.

IT fejlesztés:

HATÉKONYSÁG

Termék és szolgáltatás-fejlesztés:

INNOVÁCIÓ

Üzleti folyamatok fejlesztése:

HATÁSOSSÁG


27. oldal

Jelentıs különbség az eddigi elemzésekhez képest, hogy a gazdaságossági vizsgálatok során a be-vétel oldal alakulását is figyelembe kell venni, eljárásokat kell kialakítani számszerő értékük meg-közelítésére.

TCO

DIREKT KTG. INDIREKT KGT.

Beruházási ktg. Mőködési ktg. − szoftver − hardver − szolgáltatás

− karabantartás − bérleti díjak elı-

fizetések − személyi jellegő

− szolgáltatás leállás − végfelhasználói in-

formatikai költségek

12. ábra: A TCO elemei

1.1.3. Return on Investment (ROI)

Az informatikai projekt esetében az úgynevezett kemény ROI-t lehet könnyebben meghatározni. A kemény megtérülést – becsült vagy számított – megtakarított és megkeresett pénzösszegekkel lehet kifejezni. A megtakarítás a csökkenı költségekbıl, a megkeresett pénzösszeg a növekvı eladásokból ered. Tipikus kemény megtérülésnek tekinthetı, ha egy dolgozó kevesebb munkával tud ugyanannyi vagy több munkát elvégezni, ezáltal kevesebb új munkaerıt kell felvenni, ha csökkennek az utazási költségek a rendszerbe épített interaktív csoportmunka miatt, vagy ha a portál infrastruktúrája csökkenti az IT üzemeltetési költségeket. A megtérülés másik típusa, a pu-ha ROI esetében már nincs törekvés az összegek pontos meghatározására. A puha megtérülésnek csak indirekt módon kifejezhetı haszna van, és ezt sajnos nehéz számokkal kifejezni, pedig a vállalati IT projektek hatásának jelentıs része indirekt. Ide tartozik a növekvı alkalmazotti elége-dettség, a csoportmunkából eredı nehezen mérhetı hatékonyságnövekedés vagy például a cég belsı image-ének a fejlıdése. Amennyiben a kemény megtérülési számítások pozitív értéket ad-nak a projekt gazdaságossága nem kérdéses, ugyanakkor a puha megtérülésben további nehezen feltárható elınyök rejtıznek. A nyugati IT projektek egy része csak puha ROI elvárásokra épül, mert a stratégiai célok elérését nem tehetik a kemény ROI függvényévé.

13. ábra: A kemény és a puha ROI

1.1.4. Net Present Value (NPV), Internal Rate of Return (IRR)

Ugyanakkor a ROI számításnak is megvannak a hiányosságai. Pénzügyi szempontból nem egyen-értékőek a különbözı idıszakokban jelentkezı azonos összegő pénzáramlások. Egy beruházás minden esetben rendelkezik, alternatívával, ahol minimális kockázattal lehet fix hozamot jelentı bevételt realizálni. Ez a pénzösszeg abban az esetben is megilleti a befektetıt, ha semmilyen más egyéb erıfeszítést nem tesz.

A pénzáramlások összehasonlíthatóságának feltétele, hogy azonos idıpillanatra számolt értékek kerüljenek összevetésre. Ez az idıpillanat gyakorlati és számítási megfontolások alapján többnyire

Puha

ROI

Kemény

ROI


28. oldal

a jelen, így minden pénzösszeg jelenértéke kerül kiszámításra. A diszkontálást a kalkulatív kamat-lábbal végezhetı el, melynek értékét befolyásolja az elıbb említett fix hozamú befektetés kamat-lába, de nem azonos vele, ezt más számos tényezık és a döntéshozó egyéni preferenciái is befo-lyásolhatják. A pénzáramlás jelenértéke csökkentve a beruházás összegével adja az NPV-t. Amennyiben az NPV értéke negatív, a beruházás gazdaságilag nem indokolt, azonban az sem jelenti a projekt feltétlen megvalósítandóságát, ha az NPV pozitív. Ebben az esetben célszerő további elemzéseket tenni, például ROI számítással megvizsgálni az egyes befektetési lehetıségek egységnyi beruházásra esı hozamát.

Az NPV számítása mellett lehetıség nyílik egy másik mutató értékének a meghatározására is. Amennyiben a döntéshozó elemzési célból folyamatosan változtatja a kalkulatív kamatláb értékét, találhat egy olyan pontot, ahol az NPV értéke nulla. Számítástechnikai eszközök használatával ez a pont egy úgynevezett iterációs eljárás keretében nagy pontossággal meghatározható. Ez a speci-ális kalkulatív kamatláb a beruházás belsı kamatlába lesz (IRR). A fenti összefüggésbıl adódóan, ha a belsı kamatláb kisebb, mint a kalkulatív kamatláb a beruházás megvalósítása célszerőtlen, míg ellenkezı esetben lehetıség nyílik az egyes befektetési alternatívák belsı kamatlábának ösz-szehasonlítására.

Az információs rendszerek beruházás-gazdaságossági vizsgálatai során csak akkor használhatóak megfelelıen a hagyományos mutatók, ha a költségoldalon teljes körően – a megszokott költség-elemeken túlmenıen – feltárásra kerül az összes összetevı, illetve a bevétel (benefit) oldal esetében is alkalmazza a döntéshozó a költségek elemzésére kialakított szemléleti megközelítés.

2.5. A VÁLLALATI INFORMÁCIÓS RENDSZEREK SAJÁTSÁGOS KÖLTSÉGEI

Az információ elıállítása meglehetısen sajátságos költségszerkezettel rendelkezik. Egy vállalati információs rendszer mőszaki feltételeinek a biztosítása mindig nagy beruházást jelent a vállalatok költségvetésében: biztosítani kell a központi adattároláshoz szükséges szervereket, az adatok vé-delmét, ki kell építeni az egyes munkaállomásokat, valamint az adatforgalomról is gondoskodni kell. Mindezek mőködtetéséhez természetesen beszerzendıek a megfelelı alkalmazások, illetve a használatukhoz szükséges oktatások lebonyolítása. Ebbıl adódik, hogy egy vállalati információs rendszer bevezetésének magas költségei vannak, ugyanakkor ennek a nagy értékő eszköznek a változó költségei elenyészık. Egy-egy információnak az elıállításának a költsége lényegében meg-egyezik az ezzel foglalkozó dolgozó idıarányos bérével. Abban az esetben, ha az információs rendszert jól alakították ki, akkor ez az idıtartam is csekély. Ugyanannak az információnak az ismételt elıállításához tartozó változó költsége pedig gyakorlatilag nulla. A fentiekbıl látható, hogy a sajátos költségszerkezet jellemzıje a magas beruházási igény, ami az amortizáción keresz-tül magas állandó költséget jelent, valamint az alacsony változó költség.

Megfigyelhetı jelenség, hogy az ilyen módon olcsónak nevezhetı információk elöntik a vállalato-kat, hiszen anyagi megfontolások nem késztetik a dolgozókat arra, hogy csak a ténylegesen szük-séges információkat állítsák elı, illetve a döntések jobb elıkészítésének az igénye készteti ıket esetleg felesleges információk elıállítására, valamint a bizonyítási kényszer kollégái és természete-sen a fınöke elıtt. Kellemetlen helyzet ez, hiszen a mennyiségi gyarapodás könnyen vezet a mi-nıség, az értelmezhetıség rovására. Herbert Simon Nobel-díjas közgazdász tette az alábbi kije-lentést: „az információgazdagság figyelemszegénységet szül.” A probléma tehát már nem az in-formáció elıállításával van, hanem annak feldolgozásával, a megfelelı szőrésével. Valódi értéket ezen a ponton teremthetı az által, hogy az információk özönébıl csak a hasznos információk jutnak el a döntést végzı személyhez.


29. oldal

2.5.1. A lekötés és az átállási költség

Az informatika területén fantasztikus fejlıdés tapasztalható napjainkba. A felhasználóknak alig marad idejük megismeri az új terméket máris napvilágot látnak a fejlettebb verziókról szóló hír-adások. Azonban tévedés volna azt gondolni, hogy ezzel a dinamikus fejlıdéssel minden esetben együtt jár a választási lehetıségek Kánaánja. A múltban hozott döntések nagy mértékben behatá-rolják a jövı választási lehetıségeit. Különösképpen így van ez egy vállalatnál bevezetett informá-ciós rendszer esetében. A legalapvetıbb probléma már a dolgozók által használt gépek operációs rendszerének megválasztásánál jelentkezik. Egy-egy ilyen rendszernek a kiismerése meglehetısen nagy energiát kíván. A kiegészítı programok is az adott operációs rendszerhez lettek vásárolva. Már ebbıl is jól látható, hogy egy technológia- vagy márkaváltáshoz magas átállási költségek tar-toznak, amelyek zömét természetszerőleg – egyelıre – a fogyasztónak kell viselnie.

Az információs rendszerek esetében döntıen fontos, hogy lássuk a jövıbeni átállás költségeit. A megvásárolt termékbıl adódó lekötés nagy gondot okoz annak, aki használja, viszont jelentıs nyereséget biztosít annak, aki eladja.

Eddig a fogyasztók magas átállási költségei kaptak hangsúlyt. Azonban ezzel tisztában vannak azok a cégek is, akik új szállítóivá szeretnének válni egy adott vállalatnak, ezért felvállalnak, illetve átvállalnak bizonyos költségeket. A felvállalt költségek jó része marketing jellegő kiadás, ami a felhasználó költségeit nem érintik. Viszont az új megbízásokban reménykedı szállító készíthet tanulmányt magukról a termékekrıl, az átállás lehetıségeirıl, akár annak költségösszetevıirıl. Ezek pedig csökkenthetik a fogyasztó döntés-elıkészítéssel kapcsolatos költségeit. Hiszen a fo-gyasztónál is jelentkeznek hasonló tartalmú feladatok az esetleges átállást megelızıen. Végig kell gondolnia üzleti folyamatait, a jelenlegi rendszer erısségeit és gyengeségeit, a piacon található más termékeket, az azokban rejlı lehetıségeket és veszélyeket. Ilyen komplex vizsgálatot csak ritkán tud saját szakember gárdával egy vállalat elvégezni. Máris érzékelhetı, hogy a döntés megalapozá-sának is jelentıs költségei lehetnek. Valamint a szállító vállalat árengedménnyel, valamilyen speci-ális ajánlattal is kedveskedhet a vevınek. Elemzésre méltó, hogy az így elmaradt árbevétel meny-nyiben vesztesége a szállítónak. Egyáltalán befolyással van-e az átállás teljes költségére? Hiszen, ha nem tesz ilyen tartalmú kedvezményt akkor ez a költség forintra pontosan jelentkezett volna a vevınél. Ilyetén formán csak a költségek átcsoportosításáról lenne szó? Látni kell, hogy ez az engedmény jelentıs mértékben befolyásolhatja a vevıt. Ha az engedmény nem elég csábító lehet, hogy elmarad a teljes megrendelés. Ha azt a logikát követjük, hogy az árengedménnyel nem csök-kent az átállás teljes költsége, akkor jelen esetben azt kellene mondanunk, hogy az elmaradt egész üzletnek az árbevétel kiesése növeli a szállító költségeit a meg sem történt átállás kapcsán. Ebbıl oda juthatnánk, hogy az átállásnak állandó a költsége függetlenül attól, hogy megtörténik-e vagy sem. Érezhetı ennek következtetésnek a sutasága.

Legyen egy az átálláshoz szükséges szolgáltatásnak vagy jognak a piaci értéke 100 Ft. Szolgálta-tónk erre a termékre kizárólag átállás esetén ad 50 % árengedményt, teheti ezt mert a nála jelent-kezı költségek 60 Ft-ba kerülnek. Ebben az esetben a szállítónak 10 Ft-ba került az az árenged-mény (100Ft x 50% - 10 Ft), amibıl a vevı annyit látott, hogy 100 Ft-ból 50-et elengedtek a szá-mára. A például hozott termékek felsorolásakor nem véletlenül maradtak ki tárgyiasult eszközök. Ugyanis minden olyan esetben, amikor a szállító magas haszonkulccsal dolgozik – jellemzıen szolgáltatások – tág tere nyílik az ilyen vevıcsalogató eszközök alkalmazásának. Képzeljük el azt a helyzetet, amikor az elıbb említett szolgáltatás csak 30 Ft-ba került a szolgáltatónak.


30. oldal

Az átállás teljes költsége: A fogyasztó költségei:

+a döntés elıkészítésével kapcsolatos költségek +a tényleges átállás költségei

Az új szállító költségei: +felvállalt marketing költségek +átvállalt döntést segítı költségek +árengedménybıl származó költségek.

A régi szállító, mint árcsökkentı tétel

Annak az átállásnak a teljes költsége, hogy C fogyasztó A szolgáltatótól átpártoljon B szolgáltató-hoz, az a költség, amelyet C fogyasztónak és B szolgáltatónak közösen kell fizetnie ahhoz, hogy C fogyasztót azonos helyzetbe hozzák B szolgáltatónál, mint, amilyen helyzetben A szolgáltatónál van.

Azonban az, hogy azonos helyzetbe került az nem elégséges elvárás az átállással szemben, tehát egy magasabb szint elérése a kívánatos ebben az esetben. Ez azonban a teljes átállási költségen felül többlet ráfordításokat igényel. Tehát a fenti átállásnak a bruttó költsége az a költség, amelyet C fogyasztó és B szolgáltató közösen fizet, azért, hogy C fogyasztó magasabb megelégedettségi szintet érjen el B szolgáltatónál, mint, amit jelen pillanatban A szolgáltatónál tapasztal.

Amennyiben ezt a szintet A szolgáltatónál is elérhette volna, akkor, ezzel a költséggel csökkenteni kell az átállás bruttó költségét, ahhoz, hogy megkapjuk annak nettó költségét. Tehát az átállás nettó költsége úgy adódik, hogy összeadjuk C fogyasztó és B szolgáltató azon költségeit, amelyek azt a célt szolgálják, hogy C fogyasztót jobb helyzetbe kerüljön B szolgáltatónál, mint, amilyenben A szolgáltatónál van, ugyanakkor levonjuk azt a költséget, amelyet C fogyasztó és A szolgáltató fizetetne, ahhoz, hogy C fogyasztó olyan helyzetbe kerüljön A szolgáltatónál, mint amilyen hely-zetbe kerülne az átállással B szolgáltatónál.

2.5.2. A lekötés fajtái

1.1.4.1. Tartós vásárlás

A drágán megvásárolt eszközök gyakorta úgy vannak kialakítva, hogy más rendszerekkel vagy rendszer-eszközökkel nem tudnak kapcsolatot teremteni. Ezzel a rendszer forgalmazója arra ösz-tönzi a felhasználót, hogy a további bıvítésekhez szükséges elemeket is nála vásárolja meg. Ezzel továbberısítve a szállító felé a lekötöttségét. Nem ritkán ezek a szállítók az úgynevezett utópiaci eladások során éri el a nagyobb profitot (HP tintapatron). Ennek a kényelmes állapotnak az eléré-séhez pedig akár hajlandó beáldozni az elsıdleges eladásoknál érvényesíthetı nyereséget is.

Tartós berendezések, technikák esetén az átállási költségek általában csökkenek. Adódik ez abból, hogy ezen a területen meglehetısen gyors a technikai avulás. A lekötés tehát általában önmagát korlátozza. A gyors technológiai változások mérséklik az információs rendszereinkhez való lekö-töttséget.

Nehezíti a helyzetet, ha rendszerünk jól elkülöníthetı nagy részekbıl áll, márpedig abból áll, és ezeknek a részeknek az avulása jelentısen eltér. Ez az eltérés adódhat abból, hogy különbözı idıpontokban történt a beszerzés, fokozatosan vontuk be a vállalat funkcionális részeit az integ-rált rendszerbe. Könnyen lehet, hogy az információs rendszer szállítója tudatosan törekszik arra a stratégiára, hogy folyamatosan fejlesszük rendszerünket, ezáltal jelentısen megdrágítva az egysze-ri kiugrás lehetıségét. Természetesen a vevık is hajlamosak belemenni ebbe a fejlesztési stratégi-ába, hiszen ezzel csökkenteni lehet az egyidejő befektetések összegét, mindig arra a szegmense koncentrálva, ami valamilyen szempontból fontos a vállalatvezetés számára. A szállítót a minimá-lis lekötöttségi pontnál fenyegeti leginkább az elpártolás veszélye. Ezt felismerve még arra is tehet


31. oldal

próbálkozást az eladó, hogy remek ajánlatokkal rávegye a vevıt az egyes területek idı elıtti fej-lesztésére.

Értelemszerően a legtöbb tartós berendezés késıbbi vásárlásokat eredményez, valamint rengeteg kiegészítı termékre lehet szükség az elindított rendszer használata közben. A termékek továbbfej-lesztése és korszerőbb technológiák beépítése gyakorta kizárólag az eredeti szállítónak a joga. A számítógépes rendszereken túl figyelemre méltók a következı példák is, amelyekre szintén jel-lemzı ez a jelenség: a nagysebességő nyomtatók és másolók, a távközlési berendezések, a gépko-csik, a repülıgépek, az orvosi berendezések és a fegyverrendszerek.

1.1.4.2. Márkaspecifikus ismeretek

A tartós vásárláshoz hasonló jellegő lekötés jelentkezik a vállalati információs rendszerekhez tar-tozó márkaspecifikus ismeretekbıl. A betanítás, a felhasználáshoz szükséges ismeretek többnyire márkákhoz kötıdnek, ahhoz, hogy azonos színvonalon lehessen mőködtetni egy másik rendszert jelentıs erıfeszítésekre van szükség. Ebben az esetben az információs rendszer és a hozzá tarto-zó speciális oktatás jelentik az egymást kiegészítı termékeket. Márkaspecifikus oktatás esetén az idıvel emelkedik az átállás költsége, hiszen a dolgozók egyre jobban megismerik a rendszert, melynek segítségével jobban kihasználják lehetıségeit, fokozzák a termelékenységet.

1.1.4.3. Adatok és adatbázisok

A lekötés negyedik formájában az adatok és adatbázisok tárolására és kezelésére szolgáló hardver és szoftver elemek okozzák a lekötést, másrészrıl pedig maguk az adatatok és adatbázisok, mint kiegészítı termékek fejtik ki ezt a hatást. Az információs rendszerekben speciális formátumban tárolt, nagy tömegő adatok kiszolgáltatott helyzetet teremthetnek abban az esetben, amikor új berendezésre van szükség vagy a szoftver cseréje vált esedékessé. Lényeges kérdés, hogy a tárolt adatok milyen nehézségek árán vihetıek át másik rendszerbe, illetve az átvitel során felléphet-e adatvesztés és ez mely adatokat veszélyezteti. Az adatbázisok mérete idıvel növekszik, ami a le-kötöttség mértékének növekedésével jár együtt. Ennek a problémának a kivédésre célszerő szab-ványosított formátumokhoz és felületekhez ragaszkodni, illetve széles körben hozzáférhetı mő-szaki leírással rendelkezı interfészek alkalmazása.

1.1.4.4. Szakosodott szállítók

A lekötés másik fontos formája, amikor a vevı hosszabb idın keresztül vásárol speciális termé-keket ugyanattól a szállítótól. Ha egyetlen szállító biztosítja ezeket az eszközöket, a jövıben füg-gıségi helyzet kerülhet a vevı. A termékek megvásárlása és a késıbbi megrendelések között szo-ros összefüggés van, hiszen, ha azonos márkát vásárolunk egyszerőbb a szervizelés, olcsóbb a fenntartás. Érdekessége a szakosodott szállítók körének, hogy lehetetlenné teheti az átállást abban az esetben, ha a kiválasztott speciális termék esetében megrendelés hiányában megszőnnek azok a vállalkozások, amelyek hasonló területen mozognak. Minél speciálisabb termékrıl van szó annál nagyobb az elızı helyzet kialakulásának a veszélye.

1.1.4.5. Keresési költségek

Ezen kategória költségei az egyszerőbb költségek közé tartoznak. Itt szerepelnek azok a terhek, amelyek az egymásra találáshoz szükségesek. Különbözı mértékben és formában, de mind a ve-vıt, mind az eladót érintik ezek a tételek. Meglehetısen komoly döntések közé tartozik egy válla-lat életében, az amikor úgy dönt, hogy korszerősíti információs rendszerét, új technológiát kíván alkalmazni. Ez alapos elıkészítést kíván, ami nem biztos, hogy a vállalaton belül megoldható, így külsı segítség igénybevétele válhat szükségesé, ami nem tartozik az olcsó szolgáltatások közé.


32. oldal

Az eladó költségvetésében is érezhetı nyomokat hagyhatnak azok a marketing költségek, amelyek nehezen elkerülhetıek az ismertség és elismertség eléréséhez. Valamint további költségeket jelent egy-egy megrendelésre kiírt pályázaton való részvétel, személyre szabott ajánlatok megtétele.

2. táblázat: A lekötés fajtái és a hozzá tartozó lekötési költségek

Lekötés fajtája Átállási költségek

Tartós beszerzések Beszerzés költsége, avulással csökken.

Márkaspecifikus ismeretek Az új rendszer megtanulása, közvetlen költségek és terme-lékenységromlás egyaránt jellemzı; az idıvel emelkedik.

Adatok és adatbázisok Az adatok átvitele új formátumba; az adatmennyiség növe-kedése miatt az idıvel általában emelkedik.

Szakosodott szállítók Az új megtalálása; az idıvel emelkedhet, ha nehéz kapacitá-sokat találni vagy megtartani.

Keresési költségek A szállító és a vevı összesített költségei; magukban foglal-ják az alternatívák minıségének tanulmányozását.

33. oldal

3. AZ INFORMÁCIÓ-GAZDÁLKODÁS

Amikor a vállalatirányítási információs rendszerek kapcsán feltesszük magunknak a kérdést, mi-lyen tudományterületrıl is beszélünk, akkor sok rokon értelmőnek tőnı fogalommal találkozha-tunk, úgy mint információ-technológia (informatika), vállalatgazdaságtan, vezetéstudomány.

A felsorolt területek mindegyike egzakt definícióval rendelkezik:

− Az információ-technológia (Information Technology, IT), más néven informatika a számítás-technika és telekommunikáció együtteseként megvalósuló szakterület. Az IT magában foglalja az adatgyőjtéshez, adatfeldolgozáshoz, adattároláshoz szükséges eszközöket, technikai eljárásokat, algoritmusokat és ismereteket; az ezekhez szükséges infrastruktúrát, mint hardvert, szoftvert, hálózatot.

− A vállalatgazdaságtan a vállalat rendelkezésre álló összes erıforrással történı gazdálkodást jelenti, méghozzá a vállalati céloknak megfelelı módon. A vezetéstudomány szintén a válla-lati célokkal megegyezı tevékenység, méghozzá a vállalat kormányzása, azaz tervezés, szabályozás, szervezés, döntés, koordinálás, ellenırzés, teljesítményértékelés, tájékoztatás, hatalomgyakorlás, munkatársak kiválasztása, veszély- és kárelhárítás.

− A vállalatirányítási információs rendszerek tehát ezen tevékenységeket összesítı funkciót látnak el, amelynek az elıbbiekbıl kialakult tudományterülete az információ-gazdálkodás.

− Az információ-gazdálkodás adott vállalati erıforrásokkal, vagyis az IT infrastruktúrával, pénzügyi eszközökkel, emberi erıforrásokkal, üzleti folyamatokkal és a vállalati érintettek érdekeivel történı gazdálkodás annak érdekében, hogy a vállalati célok eléréséhez szük-séges információk és adatok elıálljanak. Azaz az információ-gazdálkodás egyszerre jelent technológiát és ökonómiát, alapvetı célja pedig a vállalat számára releváns információk és adatok megszerzése.

3.1. A VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK MEGHATÁROZÁSA

Sem a gyakorlatban, sem a szakirodalomban nem egyértelmő a vállalatirányítási információs rendszerek elnevezés használata. A fogalmat több értelmezésben is használják. Egyaránt a vállalatirányítási információs rendszer elnevezés található a következı fogalmak esetében:

− Vállalatirányítási információs rendszer, mint az irányítást segítı információs rendszer jelenti a fogalom legtágabb értelmezését. Hatékony, a vállalati célok elérésének támogatása céljából ki-alakított és felhasznált információs rendszer. Ebben az értelemben vállalatirányítási informá-ciós rendszernek tekinthetı a vállalatnál mőködı kontrolling rendszer is.

− Vállalatirányítási információs rendszer, mint a legkorszerőbb számítógépes technológián alapuló információs rendszer, mely szerkezetében, a kialakítás módjában, és a felhasználásban jelen-tısen különbözik a hagyományos rendszerektıl. Ez a definíció tehát a számítógépes techno-lógiák alapján tesz különbséget az információs rendszerek között.

− A legelsı meghatározás leszőkítésének tekinthetı az a definíció, mely szerint a vállalatirányítá-si információs rendszer a számítógépes információs rendszerek egyik típusa, amely a vállalati menedzsereket strukturált, összefoglaló, rendszeres idıközönként publikált beszámolók elıál-lításában támogatja. Így a különbözı célú információs rendszerek közül azok tartoznak ebbe


34. oldal

a kategóriába, amelyek a vezetés irányítási tevékenységét a szükséges információk alaprend-szerekbıl történı strukturált kinyerésével és megfelelı prezentálásával segítik.

A továbbiakban néhány további értelmezési, meghatározásbeli különbségre mutatunk rá.

Az információs rendszerek olyan formalizált számítógépes rendszerek, amelyek különbözı forrá-sokból adatokat győjtenek, azokat feldolgozzák, tárolják és jelentéseket készítenek, melyekkel információt szolgáltatnak a menedzserek döntéshozatalához.

Vállalatirányítási információs rendszernek tekinthetı minden olyan rendszer, amely gondoskodik arról, hogy az emberek az adatokkal vagy az információkkal együtt kapcsolatban legyenek egy adott szervezet operatív irányításával. A vállalatirányítási információs rendszerek felkínálják azt a lehetıséget, hogy a dolgozókkal, a tulajdonosokkal és az ügyfelekkel kapcsolatos adatokat feldol-gozza, így segítse az egyes szereplık közötti ügyletek lebonyolítását, valamint információkkal lássa el az erre illetékes vezetıket.

Az olyan információs rendszert, amely információkat szolgáltat a vállalat érintettjei számára és használatának célja a vállalati célok elérése, azt vállalatirányítási információs rendszernek (Enterprise Management Information System, EMIS) nevezzük. Eleinte a vállalatirányítási információs rendszer egy egyszerő alkalmazás volt, amelyen keresztül a menedzserek meg tudták osztani az informáci-ókat a saját hatáskörükbe tartozó területekrıl. A modern vállalatirányítási információs rendszerek számítógépet használnak, adatbázisból jelentéseket generálnak a napi mőködésrıl, és információ-ról gondoskodnak a vezetık számára, hogy segítsék a döntéshozatalban.

A vállalatirányítási információs rendszerek olyan számítógép-alapú rendszerek, amelyek informá-ciókat állítanak elı hasonló szükségletekkel rendelkezı menedzserek számára. Az információk leírják, hogy a vállalatnál vagy annak egy fontos területén mi történt, mi folyik most és mi várha-tó. Az információk megjelenési formái lehetnek a rendszeres jelentések, speciális jelentések és matematikai szimulációk eredményei. Az így elıállított információt menedzserek használják dön-téseik meghozásában, a problémák megoldásában.

Speciális alkalmazások is léteznek, ilyenek például a tudományos vállalatirányítási információs rendszerek (Management Science Information Systems) olyan eljárásokat tartalmaznak, amelyek biztosítják a felhasználók számára a különbözı tudományterületek által igényelt menedzsment tudományok, az operációkutatási- és a informatikai kutatásokban alkalmazott kvantitatív módszerek alkalmazá-sának lehetıségét.

3.2. A VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK EVOLÚCIÓJA

Több mint harminc éve, mióta a vállalatirányítási információs rendszer fogalma a szakirodalom-ban fellelhetı, még nem sikerült olyan definíciót találni, amely minden szakember igényét kielégí-tette volna. A menedzsment tudomány fejlıdése során megjelent új kifejezések, mint például a „döntéstámogató rendszer”, vagy a „szakértıi rendszer” megfogalmazások sem segítettek közelebb hoz-ni az álláspontokat, sıt újabb tudományos viták kiindulópontjaivá váltak.

A szakirodalom alapján három szemléletmódot különböztetünk meg:

Az elsı szerint a „vállalatirányítási információs rendszer” helyett a „döntéstámogató rendszer” kifejezés használandó, a következı szemlélet szerint a vállalatirányítási információs rendszer magába fog-lalja az összes számítógépes alkalmazást, végül van olyan nézıpont, mely úgy definiál, hogy „a vállalatirányítási információs rendszer egy számítógép alapú erıforrás”.

Az 1960-as évekig a nagyszámítógépeket kizárólag adatfeldolgozásra használták, és csak ekkor jelentek meg a menedzserek döntéshozatalát támogató elsı információs rendszerek. A 70-es évekre tehetı a döntéstámogató rendszerek és az irodaautomatizálási rendszerek megjelenése, majd a felsı vezetés igényeit kielégítı felsıvezetıi információs rendszerek az 1980-as években

Információ-gazdálkodás

35. oldal

kerültek a piacra. Az utolsó évtizedben az integráció révén a rendszerek stratégiai szerepe vált jellemzıvé.

A történetiséget követve legfontosabb információs rendszer típusok a következık:

Tranzakció-feldolgozó rendszerek (Transaction Processing System - TPS) − napi üzletmenettel kapcsolatos adatokat győjt és tárol, − a magasabb szintő rendszerek adatbázisául szolgál, − mindennapos üzleti eseményeket (számlák kiegyenlítése, eladások, bérkifizetések, meg-

rendelések, nyersanyagvásárlások) felügyel.

Vezetıi információs rendszerek (Management Information System - MIS) − elıre definiált jelentéseket készít rendszeres idıközönként, igény szerint vagy különleges

események bekövetkezésekor, − a menedzserek információigényére összpontosít, − jól meghatározott, strukturált problémák megoldásához nyújt segítséget, − fıleg operatív, esetleg taktikai szinten hatékony.

Irodaautomatizálási rendszerek (Office Automation System - OAS) − irodai rutinfeladatok, szövegszerkesztés, táblázatkezelés, e-mail, telefax, képfeldolgozás,

kiadványszerkesztés automatizálása, − az ügyviteli folyamatok integrálása és menedzselése.

Döntéstámogató rendszerek (Decision Support System - DSS) − a MIS természetes továbbfejlesztése, − egy adott problémára koncentrál, − interaktivitást, ad hoc lekérdezéseket tesz lehetıvé, − félig- vagy egyáltalán nem strukturált problémák megoldásában segít, − modellalkotási és problémaanalizáló képességekkel rendelkezik, − fıleg taktikai szinten hatékony.

Csoportos döntéstámogató rendszerek (Group Decision Support System - GDSS) − a DSS továbbfejlesztése, amely nem egyszemélyes, hanem egy kisebb csoport által közö-

sen meghozott döntéseket támogat, − nagy hangsúly van a kommunikáción: E-mail, közös hozzáféréső állományok, videokon-

ferencia lehetısége.

Felsıvezetıi információs rendszerek (Executive Information System - EIS) − legfelsı vezetıi réteg igényeit elégíti ki, − összegzett, grafikus, a legfontosabb tényezıkre koncentráló információt nyújt, de lehetı-

séget ad a részletek megtekintésére is, − döntést nem hoz, csak az annak meghozatalához szükséges információval látja el a mene-

dzsert, − könnyen kezelhetı, felhasználóbarát.

Szakértı rendszerek (Expert System - ES) − speciális, szők szakterületen hoz döntést, vagy javasol megoldást olyan nem strukturált

problémák megoldására, melyeket máskülönben magas szakmai felkészültségő szakértık-re bíznánk,

− a mesterséges intelligenciák egy speciális felhasználási területe, − tényeket és szabályokat tárol, és ezek alapján következtetéseket von le, − minden vezetıi szinten lehetnek alkalmazásai,


36. oldal

Felsıvezetıi döntéseket támogató rendszerek (Executive Support System - ESS) − nem minden felosztásban megjelenı kategória, amely tulajdonképpen bizonyos funkciók-

kal kibıvített EIS-t takar, − a hagyományos EIS funkciókon kívül tartalmaz analitikus, modellezési képességeket

(DSS), esetleg mesterséges intelligenciát és szakértıi képességeket (ES), valamint kom-munikációs lehetıségeket (GDSS) is.

Az alábbi ábra az elızıekben ismertetett vállalatirányítási információs rendszerek történeti fejlı-dését mutatja be.

TPS

MIS

~ 1960 OAS

DSS~ 1970

~ 1980

~ 1990

ES

Rendszerek integrációja és specializációja

~ 1950

14. ábra: A vállalati információs rendszerek fejlıdése

Az EIS és a MIS közötti rokonság abban rejlik, hogy mindkettı a vállalat általános teljesítményé-vel kapcsolatos jelentéseket készít, míg a DSS ezzel szemben egy adott problémára koncentrál, és egy adott döntés támogatásához szolgáltat információt. Másrészt az EIS is felfogható egyfajta döntéstámogató rendszernek, amely speciálisan a felsıvezetıi döntéshozatalhoz igazodik.

Alter munkájában a menedzsment információs rendszerek alrendszereit a rendszer típusa, tipikus felhasználója, a támogatott funkciók és a feladataik szerint csoportosítja fejlıdésük, kialakulásuk figye-lembe vételével.

Az információs rendszerek csoportosítása után következtetésként megállapítható, hogy a me-nedzsment információs rendszer (MIR) magában foglalja az összes vállalati számítógépes alkalmazást, beleértve a közvetlen termelésirányító rendszerekhez, az irodai alkalmazásokhoz és a többi in-formáció feldolgozó egységhez tartozó alrendszert.

A következı táblázat a három leginkább elterjedt rendszer összehasonlító elemzését tartalmazza.

Információ-gazdálkodás

37. oldal

3. táblázat: A menedzsment információs rendszerek funkcióinak összehasonlítása

MIS DSS EIS

Alkalmazási terület

Fıként operatív, részben taktikai szintő döntésekhez.

Fıleg taktikai, részben stra-tégiai szintő döntésekhez.

Fıleg stratégiai szintő dön-tésekhez.

Döntési képes-ség

Strukturált döntésekhez. Fıleg félig strukturált prob-lémákhoz.

Nem strukturált döntések meghozatalához.

Információ lekérdezés

Elıre definiált formátumú jelentések periodikusan, kivételes események bekö-vetkezésekor, vagy igény szerint.

Interaktív lekérdezések és válaszok rugalmasan módo-sítható formátumban, a döntéshozó igényei szerint.

A felhasználó igényei szerint változtatható formátumú je-lentések periódikusan és igény szerint, valamint ad hoc le-kérdezések.

Problématerü-let

Általános, gyakran elıfor-duló problémákhoz nyújt segítséget, személytıl füg-getlenül.

Egyedi problémák meg-oldásában segít az adott döntéshozó stílusához és igényeihez igazodva.

Általános a vállalat egészét érintı problémák felismerésé-ben és megoldásában nyújt se-gítséget.

Információ típusa

Fıleg belsı információkat használ

Belsı és külsı informá-ciókat használ

Belsı és külsı információkat használ.

Idıhorizont Múltra vonatkozó infor-mációk

Múltra, jelenre, jövıre egy-aránt vonatkozó in-formációk

Múltra, jelenre, jövıre egy-aránt vonatkozó információk.

Modellezési képesség

Nincsenek modellezési ké-pességei.

Fejlett modellezési képes-ségekkel rendelkezik.

Limitált modellezési képes-ségekkel rendelkezik.

Felhasználói interfész

Kezelése nehézkes, a szol-gáltatott információk között nehéz eligazodni.

Felhasználóbarát, de bi-zonyos elıképzettséget igé-nyel a használata.

Felhasználóbarát, könnyen kezelhetı, grafikus prezentá-ciós jellegő kimenet.

3.3. A VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK FELADATAI

Egy vállalatirányítási információs rendszer alkalmazásának elsırendő feladata, hogy a vállalati mőködés során dedikált elınyöket eredményezzen. A korszerő vállalatirányítási információs rend-szereknek a következı területeken kell üzleti elınyöket eredményeznie:

− csökkenteni a vezetıhöz jutó információk mennyiségét, − ugyanakkor lehetıvé tenni a tetszıleges mélységő hozzáférést, − növelni a vezetıhöz érkezı információk lényegszerőségét, idıszerőségét, használhatósá-

gát, és aktualitását, − összpontosítani a vezetés figyelmét a cég kritikus sikerfaktoraira, − segíteni kell a vezetık irányítói munkáját, a folyamatok nyomon-követését és a vállalati

kommunikációt, − megtalálni a változtatáshoz szükséges legkorábbi jelzı tényezıt, − figyelni a versenyhelyzet változásait, fogyasztói igényeket stb.

Az ideális információt továbbító és feldolgozó rendszernek nagy kapacitásúnak, gyorsnak, olcsó-nak, megbízhatónak és könnyen kezelhetınek kell lennie. A vállalatok többsége mára már túl van elsı számítógépes rendszereinek bevezetésén, a könyvelést, a bérelszámolást már különbözı számviteli programok végzik és az egyes termelési folyamatok irányításába, nyomon követésébe is besegít a számítógép. Az alkalmazott rendszerek azonban elszigeteltek, nem egyszerre kerültek bevezetésre, sokszor más-más gyártó termékei, így az integritás csak nagy nehézségek árán való-sítható meg.


38. oldal

39. oldal

4. INTEGRÁLT VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK

4.1. AZ INTEGRÁLT VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK ALAPJELLEMZİI

A vállalatirányítási információs rendszerek tehát a vállalati mőködés adott területeit támogatják. Céljuk, hogy a vállalati mőködés során keletkezı, releváns adatokat, információkat strukturáltan a szervezet rendelkezésére bocsássák, aminek segítségével a vállalat elérheti kitőzött céljait.

Ma már a menedzsmenttudományokban konszenzus figyelhetı meg a tekintetben, hogy a vállalati mőködés területén az integráltság, a különbözı üzleti folyamatok és szervezeti egységek egység-ben kezelése elhanyagolhatatlan részét képezi az optimális vállalati gazdálkodásnak. Gondoljunk csak bele, hogy mit eredményezne, ha például egy autógyár motorokért és gumiért felelıs beszer-zıinek munkája nem lenne összehangolva egy központi termelési tervezés keretében.

Az üzleti integráltság iránti igény természetesen megjelent a vállalati információ-gazdálkodás terü-letén is. A vállalati rendszerek evolúciója következtében ma már a legtöbb rendszerszállító ter-mék-portfoliójában kizárólag integrált megoldások szerepelnek.

Az integráció a következı szinteken valósul meg:

− a vállalati mőködés üzleti területei között (lásd következı fejezetben), − a tranzakció-feldolgozás és a vezetıi információtámogatás között, − iparági megoldások között.

Azaz egy integrált vállalatirányítási információs rendszer (Integrated Enterprise Management Information System, IEMIS, hasonló elnevezés a szakirodalomban: Integrated Corporate Information System, ICIS) egyesíti a vállalati üzleti területek mindegyikét, méghozzá úgy, hogy egyszerre szolgálja ki az operatív adatfeldolgozást, a vezetıi információellátást és a vezetıi döntéstámogatást. Ezt kiegészítve olyan iparági üzleti és informatikai tapasztalatokat is magában foglalhat, amely az általános iparági gya-korlatot kínálja a felhasználó számára.

Ezek az integrált megoldások valóban „termékesültek”, azaz standard megoldások formájában vehe-tık igénybe a piacon. A standard megoldások a következı elvre alapulnak: ahogyan a vállalati üzleti mőködés egy-egy üzletágban és vállalati méret mellett sablonizálható, úgy az azt kiszolgáló informatikai megoldások is standardizálhatók. A standard megoldások szakítottak az egyedi rend-szerkialakítás elveivel, és egy bizonyos szintő elıkészítettségi, elıkonfiguráltsági állapottal állnak a felhasználók rendelkezésére. Ezek az elıkészített funkciók, tranzakciók a bevezetés során para-méterezésre kerülnek, és így vállnak a vállalat számára használhatóvá.

Egy egyszerő példán keresztül megvilágítva: egy vevıi számla formátumának kialakításakor az egyedi fejlesztés során a vállalat által megjelölt összes számlára kerülendı adatot, információt definiálják és ehhez egy szintén definiálandó formátumot, számlasablont alakítanak ki. A standard megoldásokban már megtalálható egy olyan számlaformátum, amelyet alapvetıen átrendezéssel és a cégspecifikus adatok hozzárendelésével lehet használni. Könnyedén beláthatjuk, hogy a vevıi számla a vállalati gyakorlatban alapvetıen kis eltéréseket mutat, így egy jól sablonizálható üzleti elem. A két eljárás között releváns munka, idı és fiskális ráfordításbeli különbség mutatható ki a standard megoldás javára. A vállalati informatika ezen evolúcióját talán a ruházati szokásokhoz lehet leginkább hasonlítani: évszázadokon keresztül az egyetlen ruházkodási lehetıség a szabóság volt, ahol az ügyfél méreteire és a választott fazon alapján készült el az adott ruha. Ma már kérdés sem fér ahhoz, hogy a konfekció a legelterjedtebb ruházkodási mód, azaz a ruhagyártók a sok-sok


40. oldal

eladott ruha méret és ízlés tapasztalatai alapján kvázi „elırekonfigurált” termékekkel szolgálják ki a különbözı mérető és ízléső fogyasztókat. A titok nem más, mint hogy az esetleges szárfelhaj-tásból (testreszabás) eredı „veszteség” jóval kisebb, mint az árcsökkenésbıl, megbízható minı-ségbıl és felkínált jó ízlésbıl eredı „nyereség”.

Természetesen releváns különbség mutatkozik a standard megoldások között is, mivel már létez-nek olyan megoldásszállítók is, amelyek rengeteg rendszerbevezetés után, és így rengeteg vállalati tapasztalat birtokában olyan megoldásokat kínálnak, amelyek nagy biztonsággal lefedik az adott régióban, üzletágban mőködı és adott vállalati mérettel rendelkezı vállalatok igényeit. Ezen meg-oldásoknál megvalósulhat a 80% körüli elıkonfiguráltság is. Az elıkonfiguráltság elınyeit legin-kább azok a vállalatok élvezhetik, amelyek pénzügyi és szervezeti korlátaik miatt nem tudják megengedni maguknak azt, hogy külön szervezetoptimalizálás után vezessenek be informatikai megoldásokat. A nagymértékben elırekonfigurált megoldások elsıdleges elınye ezen vállalatok számára az, hogy a szállító korábbi üzleti tapasztalatait kvázi opcióként felkínálja a bevezetı válla-lat számára, ellátva így a szervezetoptimalizálás (lásd késıbb) feladatait.

Az egyedi rendszerfejlesztések ma már egyre kevésbé alkalmazott eljárások a gyakorlatban, mivel a vállalatok által támasztott korábban bemutatott integráltság iránti igényeket egy egyedi fejlesztés csak igen nagy munka, idı és fiskális ráfordítások árán tudja csak kielégíteni. Azok a vállalatok, amelyek a vállalati méretek és/vagy specializált üzleti mőködésük miatt nem elırekonfigurált standard megoldásokat választanak, azok sem az egyedi fejlesztések, hanem a nem elırekonfigu-rált, de standard megoldások irányába mozdulnak el.

4.2. AZ INTEGRÁLT VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK FELÉPÍTÉSE

Az integrált vállalatirányítási információs rendszerek alapvetıen kétféle funkciót töltenek be:

− A vállalati mőködés során keletkezı üzleti tranzakciókat feldolgozzák, Tranzakció feldolgozás (On-line Transaction Processing, OLTP). Az ezt megvalósító alrendszer a Tranzakció feldolgozó rendszer (TPS).

− A feldolgozott tranzakciókból keletkezı adatokat, információkat aggregálják a vállalatvezetés számára, és hozzájárulnak a vezetıi döntéshozatalhoz: (On-line Analytical Processing, OLAP). Az ezt megvalósító alrendszer a Vezetıi információs rendszer (MIS).

Integrált vállalatirányítási információs rendszerrıl (IEMIS) kizárólag akkor beszélhetünk, ha e két alapvetı alrendszer megléte egyaránt jellemzi egy információs rendszer mőködését.

Az integrált vállalatirányítási információs rendszerek a tranzakció feldolgozás során a vállalati mőködés üzleti tranzakcióit dolgozzák fel. A feldolgozás különbözı elıre szabályozott algoritmu-sok segítségével történik. Ilyen algoritmus, amikor például egy értékesített termék után vevıi számlát állít ki a vállalat. Ez a vevıi számla több üzleti paramétert tartalmaz, úgy mint a vevı és a szállító nevét és címét, cikk megnevezést és cikkszámot, árat, darabszámot, értéket, adókulcsot stb. Ezen paramétereket a vállalatirányítási információs rendszer egy elıre meghatározott algo-ritmus-rendszer alapján összeválogatja és szintén egy elıre definiált rend alapján elkészíti a nyom-tatható vevı számlát. Ezt a tranzakciót (számla kiállítás) több más üzleti tranzakció elızte meg, mint a vevıi, szállítói, ár, cikk, adózási törzsadatok rögzítése, ezek kalkulálása, a késztermék elıál-lításához szükséges anyagok raktárra vétele, stb.

Integrált vállalatirányítási információs rendszerek

41. oldal

A vezetıi információs rendszer feladata a vállalati menedzsment támogatása a számára szükséges információval. Természetesen a vállalati menedzsment feladatait megfeleltethetjük a klasszikus vállalatvezetési feladatokkal, azaz:

− tervezés, − szabályozás, − szervezés, − döntés, − koordinálás, − ellenırzés, − teljesítményértékelés, − tájékoztatás, − hatalomgyakorlás, − munkatársak kiválasztása, − veszély- és kárelhárítás.

A vezetıi információs rendszerek ezen feladatokat támogatják a megfelelı mélységő és részletezettségő információkkal. Ahogy a vállalati gyakorlatban is háromféle vezetıi szint létezik:

− stratégiai, − taktikai, − operatív,

úgy a vezetıi információs rendszerek is e három szintet különböztetik meg támogatási irányként. Az operatív szintő vezetési feladatokat a vezetıi információs rendszerek részletezett informáci-ókkal támogatják, míg a stratégiai szintő vezetés felé aggregált információkat továbbítanak.

Funkcionálisan a vezetıi információs rendszerek két fajtáját különböztetjük meg:

− vezetıi információkat elıállító rendszerek, − vezetıi döntéstámogató rendszerek.

Ezen rendszerekrıl késıbb részletesen olvashat.

4.3. AZ INTEGRÁLT VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK FUNKCIONÁLIS TE-

RÜLETEI

Az integrált vállalatirányítási információs rendszerek a vállalati mőködés fıbb területei alapján több egységre bontható. Ezeket az egységeket vállalatirányítási területeknek hívjuk. A vállalatirányí-tási területek szintén feloszthatók további egységekre úgynevezett vállalatirányítási modulokra és azok alegységére a vállalatirányítási szerepkörökre.


42. oldal

4.3.1. Vállalatirányítási területek

A vállalatirányítási területek felosztása megfelel a vállalati mőködés alapvetı felosztásával, misze-rint:

4. táblázat: A vállalatirányítási területek felosztása

Vállalati mőködési terület Vállalatirányítási terület

Alapvetı ügyvitel, backoffice Vállalati erıforrás tervezés (Enterprise Resource Planning, ERP)

Ügyfélkapcsolatok, frontoffice Ügyfélkapcsolat menedzsment (Customer Relationship Management, CRM)

Vállalatközi, illetve szervezetközi együttmőködés, collaboration

Kollaboratív megoldások (Collaborating solutions)

Az ERP rendszerek tehát az alapvetı ügyviteli mőködési folyamatokat támogatják. Ezek a folya-matok a vállalat - az angolszász elnevezésben, backoffice is tükrözıdı - „háttér” mőködését írják le. Az ERP rendszerek által végzet feldolgozás kizárólag azokat a folyamatokat érinti, amely a vállalat piaci interakciójához szükséges, úgy mint pl. pénzügyek, logisztika, termelés, értékesítés. Az ERP rendszerek egy pólusú rendszerek, azaz felhasználói csak egy vállalathoz tartoznak. (Funkciókat késıbb lásd részletesen.)

A CRM rendszerek kizárólag a vállalat piaci interakcióira koncentrálnak, alapvetıen az ERP rendszerek által feldolgozott adatokból táplálkoznak. A CRM rendszerek egy pólusú rendszerek, azaz felhasználói csak egy vállalathoz tartoznak. (Funkciókat késıbb lásd részletesen.)

ERP/CRM 1. ERP/CRM 2.

Kollaboratívmegoldás

Az ERP/ CRM 1. által felhasznált adat (input)

Az ERP/ CRM 2. által előállított adat (output)

15. ábra: Kollaboratív megoldások

Kollaboratív megoldások elnevezésükben is mutatják heterogenitásukat. Ehhez a vállalatirányítási területhez több megoldás is besorolható. Közös jellemzıjük, hogy több pólusú rendszerek, azaz felhasználóik több vállalatból, vagy több különbözı vállalatirányítási információs rendszerbıl adódnak, alapvetı céljuk a szervezetek, szervezeti egységek közötti adat és információ csere. A kollaboratív megoldások egyedi, specifikált üzleti adatok, információk cseréjére hivatottak. Az adatcsere folyamata a következı: egy ERP, vagy CRM rendszer egy kollaboratív megoldás segít-ségével szerzi meg a mőködéséhez szükséges specifikált adatot, amit egy másik ERP, vagy CRM rendszer állított elı. Természetesen a konnektor két- vagy többirányú adatkommunikációra is lehetıséget biztosíthat.

Az adatforgalom technológiája legtöbbször egyedileg kialakított üzleti konnektor (interface), amely két, vagy annál több különbözı vállalatirányítási információs rendszert köt össze. Az egye-


43. oldal

di kialakítás oka az, hogy a különbözı vállalati rendszerek általában eltérı alkalmazás és adatbázis jellemzıkkel bírnak. Ezek összehangolása az n*n hozzárendelés miatt igen sokrétő feladat lehet. Az összehangolásnak alapvetıen két útja létezik:

1. Az egyik kitüntetett rendszer által támogatott adatformátumba való konvertálás

2. Egy a kapcsolódó rendszereken kívüli adatformátum kialakítása, amely standardként sze-repel. Ilyen a gyakorlatban gyakran alkalmazott standard például az xml- formátum.

Ezen rendszerek további sajátossága, hogy az általuk végzett tranzakció feldolgozás általában igen specifikált, így további egységekre funkcionálisan csak ritkán oszthatók. Könnyen belátható, hogy a kollaboratív megoldásoknak rengeteg különféle megvalósulása lehetséges, mivel bármely üzleti tranzakcióhoz, adathoz kialakítható ilyen üzleti konnektor. A következıkben bemutatjuk a gya-korlatban legsőrőbben használt kollaboratív megoldásokat:

─ Elektronikus adatcsere rendszerek (Electronic Data Interchange, EDI): az ERP és CRM adatok, tranz-akciók bármelyikének összekapcsolására szolgáló eszköz. Széles körő felhasználhatósága mö-gött igen komoly egyedi technológiai fejlesztési igények rejlenek, így egyedisége és magas elı-állítási és üzemeltetési költségei miatt széles körben nem elterjedt.

─ Elektronikus kereskedelmi megoldások (e-commerce): a vállalat értékesítési tevékenységének össze-kapcsolása a vevıkkel az interneten keresztül. Megvalósulásai között megtalálhatóak a végfel-használók (Business to Customer, B2C), illetve a viszontértékesítık felé publikált, azaz B2B értékesítési portálok. A piaci trendek alapján egyre gyakrabban találhatóak meg az e-commerce funkcionalitások a standard vállalatirányítási információs rendszerek ERP vagy CRM „felszereltségei” között, amely azt jelenti, hogy ezzel átkerülnek a kollaboratív megoldá-sok közül az ERP, vagy CRM kategóriába.

─ Az elektronikus beszerzési – értékesítési megoldások egy speciális megvalósulása a marketplace, ahol a marketplace-ben résztvevı vállalatok beszerzési és értékesítési tevékenységet végeznek párhuzamosan. A marketplace üzemeltetıje alapvetıen elszámoló funkciókkal bír, azaz az egyik tagvállalat által értékesítésre felkínált termék egy másik tagvállalat általi megvásárlása (beszerzése) során egyrészt megteremti az adásvétel informatikai és jogi környezetét, másrészt a felek által különbözı ERP rendszerekben nyilvántartott értékesítési és beszerzési tranzakci-ókat egy közös platformot kialakítva végrehajtja. A marketplacen történı megjelenés tagság-hoz kötött, amely általában egy belépési díj és üzemeltetési költség típusú finanszírozással pá-rosul.

─ Banki tranzakciós konnektor: a vállalat ERP rendszerének összekapcsolása a bank ERP, vagy CRM rendszerével.

─ Bérszámfejtı, humán erıforrás gazdálkodó tranzakciós konnektor: a vállalat ERP rendszerének össze-kapcsolása egy saját vagy alvállalkozó által üzemeltetett másik ERP rendszerrel.

─ Mobil eszközökkel történı kereskedelem (m-commerce): a vállalat ERP rendszerének összekapcsolása mobil eszközökkel, mint például notebook, mobiltelefon, PDA (Personal Digital Assistant) eszközök. Ezen technológia felhasználása általában a vállalati értékesítés területén jellemzı, azonban egyéb üzleti tranzakció támogatására is alkalmasak, mint például beszerzés, raktáro-zás, termelés.

─ Iparági megoldások üzleti konnektorja: olyan speciális iparági, jellemzıen mőszaki alkalmazások-nak a konnektálásáról van szó, amelyek a vállalat ERP, vagy CRM rendszeréhez szolgáltatnak


44. oldal

input adatokat. Gyakorta használt konnektorok a CAD (Computer Aided Design, Számító-géppel támogatott tervezés), a CAM (Computer Aided Manufacturing, Számítógéppel támo-gatott gyártás), CAPP (Computer Aided Process Planning, Számítógéppel támogatott folya-mat-tervezés) alkalmazásokhoz kapcsolódnak.

4.3.2. Vállalatirányítási modulok és szerepkörök

A fentiek alapján tehát vállalatirányítási modulokról beszélni csak az ERP és CRM rendszerek esetében van értelme. A kollaboratív megoldások esetében az adott rendszer specifikált funkciói általában további funkcionális egységekre nem oszthatók.

A vállalatirányítási modulok kialakításánál a vállalati mőködés fıbb területei szerepeltek ismérv-ként. Természetesen minden vállalatirányítási információs rendszer szállító más és más termino-lógiát használ a rendszer moduljainak elnevezéséhez. Mi azt a modellt mutatjuk be, amely a legin-kább elterjedt a mai gyakorlatban.

A vállalatok mőködése ERP szempontból alapvetıen négy területre osztható: logisztikai folyama-tok, pénzügyi folyamatok, emberi erıforrás gazdálkodási folyamatok és projektgazdálkodási fo-lyamatok. A vállalatirányítási ERP modulok is ezen elv alapján épülnek fel:

4.4. ERP MODULOK

− Pénzügyi modulok

− Pénzügy-számvitel (Financial) − Eszközgazdálkodás (Asset Management) − Kontrolling (Controlling)

− Logisztikai modulok

− Anyaggazdálkodás (Material Management) − Termeléstervezés (Production Planing) − Karbantartás (Plant Maintenance) − Értékesítés (Sales and Distribution) − Minıségmenedzsment (Quality Management)

− Emberi erıforrások modul

− Projekt rendszer modul

4.5. CRM MODULOK

− Marketing modul − Értékesítés-támogatás modul − Szolgáltatások modul − Call center modul

A modulok gyakorlatilag lefedik az ügyviteli mőködés teljes spektrumát. A modulok funkcionális „felszereltsége” természetesen differenciálhatja a vállalatirányítási információs rendszerek képes-ségeit.

A modulok gyakran használt analógiával a vállalat szervezeti egységeinek, osztályainak, csoportja-inak felelnek meg. Ahogy a vállalatoknál megtalálhatóak pénzügyi, beszerzési osztályok, úgy elkü-löníthetık hasonló tartalmú modulok is. Ezzel a felosztással azonban felmerül az a probléma, hogy az adott vállalat által használt vállalatirányítási információs rendszer modul-felosztása nem biztos, hogy megfelel a vállalat szervezeti tagoltságával. Ez a probléma hatványozottan jelentkezik


45. oldal

a kis- és középvállalatok életében, amelyek legtöbbször egyáltalán nem tagozódnak osztályokra, csoportokra, hanem személyek, munkatársak határoznak meg egy-egy üzleti tevékenységet, azaz munkakört. Ezen vállalatok számára egy komplett modul bevezetése sokszor túl tág határokat teremt, így a vállalatok egyre inkább törekednek informatikai szállítóiktól a számukra szükséges alkalmazás keretek megvásárlására. A vállalatirányítási információs rendszerek egyes szállítói fel-ismerve ezt az adottságot, alkalmazásaikat olyan irányba fejlesztették, hogy az egyes modulok alkalmassá váljanak kisebb funkcionális igények kiszolgálására is. Kialakították az úgy nevezett szerepkör alapú felépítést, amely a vállalati munkakörök analógiájára szerepkörökre osztja az al-kalmazás tranzakcióit.

A vállalatirányítási modulokkal a késıbbiekben bıvebben foglalkozunk.

Megjegyezzük, hogy az integrált vállalatirányítási információs rendszereknek gyakran kizárólag az ERP rendszereket feleltetik meg. A fenti ismertetésbıl azonban kitőnik, hogy a modern rendszer-terminológia alapján az ERP, CRM és kollaboratív megoldások összessége alkotja az integrált vállalatirányítási információs rendszerek funkcionális portfólióját.

Ez idáig kizárólag a vállalaton belüli információgazdálkodásra koncentráltunk, de a kollaboratív megoldásoknál láthattuk, hogy vállalaton belül mőködı informatikai rendszerek szoros kölcsön-hatásban lehetnek a vállalat érintettjeinek informatikai rendszereivel is.

A következı ábra sematikusan mutatja be ezen kölcsönhatás lehetséges megvalósulásait:

Üzleti folyamat térkép-Belsı vállalati struktúra

Pénzügy

Számvitel

Kontrolling

Eszközgazdálk

odásHR

Beszerzés

Készletgazdálko

dásTerme

lésÉrtékes

ítés

Projektgazdálko

dás

Marketing

Értékesítés

Szolgáltatások

Call center

Onlineértékesítés

Web Information

Center

B2B konnektorok

Mobil megoldások

ERPCRMKollaboratív

16. ábra: Üzleti folyamattérkép


47. oldal

Piaci struktúra

Vállalatunk

Tulajdonos

Vevı

SzállítóVersenytárs

17. ábra: Paci struktúra

49. oldal

5. AZ IGÉNYBEVÉTEL FORMÁI

Ahhoz, hogy egy vállalatirányítási információs rendszer a vállalat számára használhatóvá váljon, ahhoz minden esetben – a rendszer típusától függetlenül – a következı rendszerelemekre van szük-ség:

5.1. BEVEZETÉSHEZ KAPCSOLÓDÓ ELEMEK

− Szoftver licensz (alkalmazás, adatbázis, operációs rendszer) − Hardver környezet

− Vállalatirányítási információs rendszerhez: adatbázis és alkalmazás szerver(ek), mentıegység, esetlegesen hálózati kapcsolat végpontok vállalatok között (WAN), adatközpont infrastruktúra

− Irodai: helyi hálózat (Local Area Network, LAN), hálózati szerver, aktív esz-közök (router, hub, modem), munkaállomások

A továbbiakban hardver környezeten a vállalatirányítási információs rendszerhez szükséges elemeket ért-jük.

− Tanácsadói szolgáltatás az adott alkalmazás vállalatra történı konfigurálásához és a felhaszná-lók oktatásához (implementáció).

Üzemeltetési elemek

− Alkalmazástámogatás (napi operatív problémák megválaszolása). − alkalmazás verzióváltás, − alkalmazáshoz kapcsolódó üzleti támogatás, − adatbázis-menedzselés, − hardver- és hálózatüzemeltetés (javítások, cserék, bıvítések).

Ezen rendszerelemek tehát minden vállalatirányítási információs rendszert használó vállalat életé-ben szükségszerően megjelennek. Ma már a vállalat menedzsmentjének több lehetısége is van arra, hogy eldöntse milyen módon kívánja finanszírozni, illetve üzemeltetni vállalatirányítási in-formációs rendszerét. Az igénybevétel formái alapján két alapvetı formát különböztetünk meg:

− a vállalat által tulajdonolt és üzemeltetett (tradicionális) vállalatirányítási információs rendszereket,

− egy megbízott szolgáltató által üzemeltetett (outsourcing) rendszereket.

5.2. TRADICIONÁLIS MODELL

A tradicionális modell esetén - amelyet in-house megoldásnak is neveznek - a bevezetéshez kapcso-lódó rendszerelemeket a vállalat megvásárolja, és saját költségén üzemelteti, vállalva ezzel a vásár-lás és üzemeltetés technikai, üzleti és pénzügyi kockázatát. A vásárlás általában egyösszegő ráfor-dításként jelentkezik, számvitelileg a vállalat egy eszközt aktivál a bevezetés során. Az üzemeltetés folyamatos ráfordításként jelentkezik, ennek egy része költségként számolható el, az eszközökhöz kapcsolódó javítások, cserék, bıvítések pedig szintén eszközként aktiválódnak.

Felmérése szerint egy 4 éves idıszakot figyelembe véve a vállalatok a 4 éves vállalati informatikai összköltség 40 %-át költik el a bevezetéshez kapcsolódó rendszerelemek beszerzésére és a fenn-maradó 60 %-ot a bevezetett rendszer üzemeltetésére fordítják. Ez az arány igen fontos megálla-


50. oldal

pítást tesz lehetıvé, miszerint egy vállalatirányítási információs rendszer bevezetése még közel sem egyezik meg annak összköltségével, hanem a statisztikák alapján ennek az összegnek 2,5-szerese lesz egyenlı a vállalat 4 éves informatikai összköltségével.

5.3. OUTSOURCING MODELL

A tradicionális modell mellett megjelent az ún. outsourcing modell, amely alapvetıen a tradicionális modell gyengéit hivatott kiküszöbölni. A megoldás a közgazdasági gyakorlatban jól ismert és be-vált erıforrás kihelyezésre épül. Ennek keretében egy az adott feladattípusra specializált szolgálta-tó nagyobb szakértelemmel, koncentráltabb kapacitásokkal és ezekbıl következı relevánsan ma-gasabb minıséggel és jelentısen alacsonyabb fajlagos ráfordítással képes ellátni azt a feladatot, amelyet a tradicionális modellben a vállalat önmaga végez és finanszíroz.

Az outsourcing modellnek két olyan megvalósulása létezik, amelyik a gyakorlatban is már bizo-nyítottan komoly eredményeket mutatott fel: az egyik a Hosting, a másik az alkalmazásszolgáltatás (ASP).

5.3.1. Hosting

A Hosting angol kifejezés alkalmazása ezen modell azonosítására igen gyakori, magyar megfelelı-je a gyakorlatban nem honos. A kifejezés a host, azaz gazda szóból ered, amely jól jellemzi a mo-dell mőködését: A hosting szolgáltatás során a host, azaz a szolgáltató üzemeltetésre átveszi a megbízó vállalat által tulajdonolt vállalatirányítási információs rendszert. Az üzemeltetés a szolgál-tató adatközpontjában zajlik, ahol a szolgáltató folyamatos hardverüzemeltetést végez, amelybe a hardver infrastruktúra és adatbázis környezet menedzsmentje tartozik bele. A hosting szolgáltatás tehát nem terjed ki az alkalmazás menedzselésére, ennek biztosítása továbbra is a vállalat feladata. A szolgáltató adatközpontjában elhelyezett szerverek egy bérelt vonali, vagy internetes adatkom-munikációs kapcsolattal csatlakoznak a vállalat helyi hálózatához, így a felhasználók munkaállo-másaihoz.

Adatközpont Szolgáltató telephelye

ManagementConsole

Management hálózat

Front EndServer

Back EndServer

Backup device

Bérelt vonal / Internet

DevelopmentServer

Tûzfal

Tûzfal

Telephely 2

MunkaállomásMunkaállomásMunkaállomás

Tûzfal

Telephely 1


Tûzfal


Telephely 3

18. ábra: A hosting és ASP architektúrája

A hosting szolgáltatás alapvetı elınye, hogy a hardverüzemeltetéshez szükséges szakértelmet koncentráltan a szolgáltató biztosítja; illetve a hardverüzemeltetés fajlagos költsége redukálható.

Az igénybevétel formái

51. oldal

5.3.2. Alkalmazásszolgáltatás - ASP

Az alkalmazásszolgáltatás (Application Service Provision, ASP) a hosting szolgáltatáson túlmuta-tó megoldás, miszerint a szolgáltató nemcsak a vállalatirányítási információs rendszer hardver üzemeltetését, hanem az alkalmazás menedzselését is vállalja. Az ASP modell alkalmazása során az összes mőködéshez szükséges rendszerelem a szolgáltató által kerül kialakításra és beruházásra: Egy központi adatközpontban kerül elhelyezésre a rendszer alapját képezı hardver környezet, amelyen a szolgáltató által megvásárolt és üzemeltetett adatbázis-kezelı és alkalmazási szoftver mőködik. Az adatközpontban elhelyezett rendszerelemek és a vállalat telephelye, illetve telephe-lyei közötti kapcsolatot egy dedikált sávszélességő adatkommunikációs csatorna biztosítja. Az ASP szolgáltató a kívánt rendszer kiválasztásától kezdve teljes egészében vállalja a vállalati meg-oldás bevezetését és üzemeltetését, méghozzá úgy, hogy az összes ehhez szükséges erıforrást ı szerzi be és ügyfeleinek ezt a komplex szolgáltatást havi fix bérleti díjért teszi elérhetıvé. A mo-dell másik fontos üzenete, hogy az alkalmazás-szolgáltató koncentrált rendszer-bevezetési és üzemeltetési tudása lehetıvé teszi a megbízó vállalat számára, hogy a vállalatirányítási információs rendszerrel kapcsolatos összes problémát egy erre specializálódott szolgáltatóra hárítsa át, megte-remtve ezzel a cég alaptevékenységére történı koncentrálás lehetıségét.

Az ASP szolgáltatás elemei

− Szoftver licenszek (alkalmazás, adatbázis, operációsrendszer) − Kliens szoftver − Bevezetési tanácsadás − Oktatás − Fejlesztıi, teszt és éles szerverek rendelkezésre bocsátása − Szerver összeszerelés − Szervertároló összeállítás − Készlet ellenırzés és készlettartás a szerzıdésbe foglalt elemekre − Távoli nyomtató adminisztráció − Biztonsági felügyelet − Hardverkarbantartás és bıvítés − Adatbázis adminisztráció − Háttér feladatok és interfészek adminisztrálása − Biztonsági másolat és szükség esetén teljes vagy részleges helyreállítás − Archiválás − Alkalmazás verzióváltás − Fájl rendszer nyomon követés − Minıségbiztosítás − Projekt menedzsment − Válaszidı ajánlás − Tábla kihasználtság ellenırzés − Szoftver, operációs rendszer és hardver verzióváltás menedzsment − Havi szolgáltatási riport − 7 * 24 órában felügyelt adatközpont üzemeltetés − Hardver és adatbázis teljesítmény felügyelet − Teljes körő ügyfélszolgálat és Help Desk szolgáltatás − Teljes körő alkalmazás és technológiai támogatás

Az ASP modell használata releváns üzleti elınyöket jelenthet azon gazdálkodók számára, amelyek ezen IT megoldást választják. Az ASP modell üzleti elınyei csoportosítva a következık:


52. oldal

Bevezetéshez kapcsolódó elınyök

− nincs hardver-beruházási igény, − nem kell megvásárolni az alkalmazás licencét, − nem kell megbízni külsı tanácsadót a rendszer bevezetéséhez, − a bevezetés idıtartama az elıre konfigurált alkalmazások esetén jóval gyorsabb, szemben

a hagyományos implementációkkal, amelyek több hónapot, akár éveket is igénybe vettek, és a vállalatra komoly költséget róttak a munkavégzés alacsony hatékonyságából, valamint a munkakiesésbıl adódóan,

− alkalmazás-szolgáltatás megoldásoknál a vállalat üzleti folyamatainak optimalizálásához nem kell külön gazdasági tanácsadókat alkalmazni,

− az elızetes beruházás kiküszöbölése által felszabaduló források a vállalaton belül egyéb befektetésekben tıkésíthetık.

Üzemeltetéshez kapcsolódó elınyök

− nincs utólagos, pótlólagos hardverbıvítési igény a vállalattal szemben, − a szoftver verzióváltásokat a szolgáltató átvállalja a vállalattól, − nem kell alkalmazni számítástechnikai szakember gárdát, − nem kell súlyos tanácsadói díjat fizetni az on-line ügyfélszolgálat igénybevételéért.

Számviteli elemek

− Mivel a bérleti konstrukcióban a szolgáltatás havi díjért vehetı igénybe, így a vállalatok költségeik között tarthatják nyilván ezen kiadásaikat, amely többek között adómegtakarí-tásra ad lehetıséget.

Szolgáltatás-minıségi elınyök

A vállalat magasabb szintő, integráltabb szolgáltatáshoz jut a következık által:

− az eddig csak nagyvállalatok által megengedhetı világszínvonalú alkalmazások a kis- és középvállalatok számára is elérhetıvé válik,

− az internet általi mobilitással bárhonnan elérhetıvé válik a rendszer, − a szolgáltatás méretezhetısége, − a mindenkori legfrissebb alkalmazás-verzióhoz való hozzáférés, − a mindig megfelelı hardverpark biztosítása az ASP által, − magas szintő adatbiztonság, − csatlakozási lehetıség kollaboratív alkalmazásokhoz.

Felmérések alapján a tradicionális modellel szemben az ASP modell alkalmazásával a vállalatok 5 év alatt 30 %-os összköltség csökkenést érhetnek el. Az ASP modell alapvetıen a kis- és közepes vállalatok információgazdálkodását segíti, de nem ritka a gyakorlatban az sem, hogy nagyvállalat-ok alkalmazzák az ASP modellt információ-gazdálkodásuk támogatására.

A következı táblázat összefoglalja a vállalatirányítási információs rendszerek igénybevételének megismert modelljeit. A táblázatban függılegesen szerepelnek a vállalatirányítási információs rendszerek rendszerelemei, vízszintesen a különbözı modellek. Az egyes keresztcellákban szerep-lı jellemzık azt írják le, hogy az adott rendszerelem az adott modellben ki által menedzselt (kinek a felelıssége ezen elem mőködése, ki finanszírozza közvetlenül az elem rendelkezésre-állását):

Az igénybevétel formái

53. oldal

5. táblázat: A tradícionális és az outsourcing modell összehasonlítása

Outsourcing modell Tradicionális mo-dell Hosting ASP

BEVEZETÉS

� Szoftver licensz Vállalat Vállalat Szolgáltató

� Hardver Vállalat Szolgáltató Szolgáltató

� Adatközpont Opcionálisan a vállalat Szolgáltató Szolgáltató

� Béreltvonal Opcionálisan a vállalat Szolgáltató Szolgáltató

� Implementáció Vállalat Vállalat Szolgáltató

ÜZEMELTETÉS

� Alkalmazástámogatás Vállalat Vállalat Szolgáltató

� Alkalmazás verzióváltás Vállalat Vállalat Szolgáltató

� Alkalmazáshoz kapcsolódó üz-leti támogatás

Vállalat Vállalat Szolgáltató

� Adatbázis-menedzselés Vállalat Szolgáltató Szolgáltató

� Hardver- és hálózatüzemeltetés Vállalat Szolgáltató Szolgáltató

55. oldal

6. VÁLLALTIRÁNYÍTÁSI MODULOK

Jelen fejezetben a Magyarországon legelterjedtebb rendszer példája alapján (SAP) részletesen be-mutatjuk a különbözı vállalatirányítási modulok tartalmát, funkcionalitását. Bemutatjuk azokat az ERP modulokat, amelyek a vállalati gazdálkodás területén a legnagyobb hangsúlyt kapják.

Az utóbbi években egyre többet beszélnek az informatikai cégek a CRM-rıl, amelynek célja az ügyfélkapcsolatok minél hatékonyabb ápolása. Ezen általában a marketing-, értékesítés- és szerviz területek informatikai támogatását értik, esetlegesen kiegészítve bizonyos „call center” funkciona-litással. A fejezet utolsó részében tehát a CRM modulok kerülnek röviden bemutatásra.

Az alábbi összefoglaló a gyakorlatban leggyakrabban alkalmazott szoftvermegoldások elemzése alapján készült el. Célunk többek között az, hogy az egyes moduloknál bemutassuk mindazon képességeket, amelyeknek rendelkezésre kell állni ahhoz, hogy egy alkalmazott vállalatirányítási információs rendszer valóban integrált és minden üzleti területen kielégítı funkcionalitást bizto-sítson.

6.1. PÉNZÜGYI MODULOK

6.1.1. Pénzügy-számvitel – Financial (FI)

A pénzügyi könyvelési rendszer feladata, hogy megfeleljen a számvitel külsı, valamint belsı kö-vetelményeinek. Amíg a külsı nézet a (törvényileg szabályozott) beszámoló készítésre és az in-formációellátásra (tulajdonosok, hitelezık, alkalmazottak, nyilvánosság) irányul, az ellenırzési és diszponálási feladatok lefedése a hatékony vállalati kontrolling elıfeltételét teremti meg.

Integráció

A beszámoló készítés törvényileg szabályozott keretek között történik. Az FI-modul garantálja a magyar és a nemzetközi jogi elıírások betartását, amely egyben egy rendszer nemzetközi alkal-mazhatóságának elıfeltétele.

Integrált rendszerekben a beszámolás, illetve számadás csaknem teljesen automatizált aktualizálá-son keresztül történik. A logisztikai üzleti folyamatok (pl. árubeérkezés, kiszállítás) automatikus könyveléseket váltanak ki (a társasági jogi és pénzügyi határokat figyelembe véve). Az üzletfelek-kel lebonyolított adatcsere (vevı, szállító, bank, biztosítás, hitelinformáció) is nagyrészt elektroni-kus úton történik.

Workflow segítségével definiálhatók az idıszakosan visszatérı feladatok, amelyeket eloszthatunk a feldolgozó helyek között és a határidı-felügyelet is megvalósítható.

Bizonylati elv

A gazdasági események rögzítése a bizonylati elv alapján történik és ezáltal teljes egészében ellen-ırizhetı az egyedi bizonylattól a mérlegig vezetı képzeletbeli útvonal. Közvetlenül a könyvelés után már feldolgozható kell, hogy legyen a képernyın a számlamegjelenítés, az egyenleg- és ösz-szeglista, valamint a mérleg- és eredménykimutatás-kiértékelés.

Dokumentáció

A teljes dokumentáció egyben az átfogó és integrált számviteli rendszer lényeges alapköve. A gazdasági folyamatok hiánytalan kimutatása biztosítja ugyanis az összes operatív és stratégiai üzle-


56. oldal

ti/ügyviteli szint párhuzamos felügyeletét. Az FI-rendszeren keresztül a vállalat kontrolling-területei is egyidejőleg hozzáférhetnek a mindenkor releváns alapinformációkhoz.

19. ábra: Külsı számvitel

Analitikák

A logisztika és a számvitel integrációja mellett hangsúlyos szerepet kap az analitikák összekapcso-lása a fıkönyvvel. A szállítói és vevıi, valamint az eszközszámlák analitikus számláin történı mozgások közvetlenül megjelennek a hozzájuk rendelt fıkönyvi számlákon (egyeztetı könyvelés) is. Ezáltal az analitikák folyamatosan összhangban állnak a fıkönyvvel az egyeztetést illetıen.

Az éves és havi zárások elıkészítésére automatikus funkciókat kell biztosítani: pl. idegenpénz-nem-értékelés, átcsoportosítások, a követelések és kötelezettségek csoportosítása a maradvány-futamidı alapján.

6.1.2. A pénzügyi könyvelés funkciói

− Fıkönyvi könyvelés, − szállítókönyvelés, − vevıkönyvelés, − eszközkönyvelés, − speciális ledger-ek (speciális könyvelések), − konszolidáció.

A Fıkönyv

Elvárt fıbb jellemzık:

− Több számlakeret párhuzamos használata, − tetszıleges számú mérleg és eredmény-kimutatás készítése, − analitikák, − többféle pénznem párhuzamos használata, − zárás automatizálása, − rugalmas beszámoló-készítés, felhasználói felületen elıállítható riportvariánsok.

Külsı számvitel

konszolidáláskonszolidáláskonszolidáláspénzeszközgazdálkodáspénzeszközgazdálkodáspénzeszközgazdálkodás

vevıkvevık

tárgyitárgyieszközökeszközök

anyaganyag vagyon-vagyon-gazdálkodásgazdálkodás

személyzetszemélyzet

szállítókszállítók

fıkönyvfıkönyv

raktárraktárraktár

Vállaltirányítási modulok

57. oldal

A fıkönyvi könyveléshez szükséges számlakeret cégspecifikusan, vagy a konszernben egységesen alkalmazható. Amennyiben a teljes vállalat igényei mellett az országspecifikus követelményeket is figyelembe kell venni, párhuzamos számlakeret alkalmazandó.

Az egyes nemzeti társaságok könyvvezetése történhet több párhuzamos pénznemben is, azaz minden gazdasági esemény leképezhetı kell legyen a helyi nézet, a konszernnézet és egy ún. ke-mény valuta nézete alapján is.

A mérleg különféle típusok szerint (egyenlegmérleg, mozgási mérleg) és célok alapján (határnapi mérleg, éves zárás) készíthetı el. Az FI-rendszerben a különféle mérlegverziók biztosítják a mér-legkészítés sokoldalúságát.

Vevı-, szállító – Könyvelés

Elvárt fıbb jellemzık:

− Valósidejő integráció a fıkönyvhöz, − számlaiktatás, elızetes rögzítés, kontírozás teljes folyamata, − workflow, vállalaton belüli bizonylatáramlás, − hitelmenedzsment (vevık), − egyenlegek kezelése a magyar sajátosságok szerint, − váltókezelés, − automatikus átutalások készítése, Home-Banking kapcsolat, − nyitott tételek követése, bankszámlakivonat automatikus beérkeztetése, − automatikus felszólítások, − automatikus kamatszámítás, − automatikus levelezés (számlakivonat egyenlegközlı stb.), − archiválás.

Vevıkönyvelés

A vevıállomány ésszerő felügyeletét és vezérlését a pénzügyi rendszerben a vevıkönyvelés látja el. A nyitott tételek követése áttekinthetıbb a számlaelemzésekkel, figyelmeztetı riportokkal, esedékesség korosításával, valamint a felszólítási rendszerrel. Az ezzel kapcsolatos levelezés egye-dileg kell, hogy konfigurálható legyen, amely a fizetésközléseket, az egyenleg-jóváhagyásokat vagy a számlakivonatokat is érinti.

A beérkezı fizetések külön e célra kialakított rögzítési funkciókkal, vagy adatátvitellel automati-kusan rendelhetık hozzá az esedékes követelésekhez. A fizetési program automatizálja a beszedé-si megbízásokat és a kifizetéseket is.

Léteznek ún. értékesítési és cash-menedzsment interfészek, valamint a felhasználó-specifikus nézetek, amelyek összekötik a mővelet pénzügyi és eredményoldalát. A hitelmenedzsment, likvi-ditástervezés és fedezetszámítás rendszere így folyamatosan aktuális és egyeztetett információk-hoz jut.

Szállítókönyvelés

A szállítókönyvelés kezeli a szállítók könyvviteli adatait, amely egyben a beszerzési folyamat in-tegrált része is. Fontos információs forrás a beszerzés számára a szállítások, számlák és fizetések adatait illetıen.

A fizetés őrlap formájában vagy elektronikus úton történik a maximális skontó kihasználásával. A rendszernek támogatnia kell a nemzetközileg is elfogadott fizetési módokat. A nyitott tételek kö-vetésére számos lehetıséggel kell, hogy rendelkezzen a felhasználó: számlaelemzések, esedékes-ség-elırejelzés és kockázati elemzések (idegen pénznemek).


58. oldal

A szállítókönyvelésben egyenleglistákkal, számlaellenırzésekkel vagy naplókkal dokumentálhatók a folyamatok.

20. ábra: A pénzügyi könyvelés

6.2. ESZKÖZGAZDÁLKODÁS – ASSET MANAGEMENT (AM)

A rendszer rögzíti, számítja és feldolgozza a vállalat rendelkezésére álló eszközökkel kapcsolatos növekedéseket, csökkenéseket, átkönyveléseket, az értékcsökkenést és a helyesbítéseket. Az esz-közértékelésre vonatkozó törvényi elıírások mellett a felhasználó definiálhat értékcsökkenési és értékelési módszereket a kontrolling számára. A rendszert rugalmassá kell tenni az egyéni értéke-lési területek definiálása irányában is, amelyek az értékcsökkenési leírás, a kalkulatív kamatok, a biztosítási értékek és a támogatások meghatározására és megjelenítésére szolgálnak. A beszámolói rendszerben a kötelezı beszámolók kiegészülnek a mutatók belsı kiértékelésének és a „figyelem-reméltó adatok ranglistáinak” lehetıségével. Az üzemgazdasági tervezés optimalizálásához járul hozzá az értékelési paraméterek szabad szimulációja. A szimulációs számítás tehát rugalmas jövı-beni tervezést biztosít a tervezett és realizált beruházások bevonásával.

6.2.1. Az eszközkönyvelés néhány funkciója

Számítási célok

Egy vállalat eszközvagyona számos különbözı vagyontárgyból tevıdik össze. Ezeket a mérleg szerinti fıkönyvi számlához való hozzárendelésük alapján a befektetett eszközök megfelelı mér-legsorához lehet hozzárendelni.

Alapvetı számadásként az eszközkönyvelésé a feladat, hogy az eszközök adatait célirányosan készenlétben tartsa a sokféle külsı és belsı információigény számára. Ehhez szükség van arra, hogy az eszközvagyon különbözı kritériumok szerint hierarchikusan strukturálható legyen. Ilyen kritériumok pl. a mérlegsorok, az eszközosztályok és az eszközök a speciális üzleti eseményeikkel.


59. oldal

Az AM rendszer az eszközvagyon párhuzamos strukturálását teszi lehetıvé a következı nézı-pontokból:

− mérlegtechnikai (számla-hozzárendelés, illetve eszközfajták) − osztályozó (eszközosztály, rendezı fogalmak) − eszközfüggı (eszközcsoport, eszköz-fıszám és alszám, egyedi tételek)

Értékelések

Az integrált eszközgazdálkodás keretében az eszközkönyvelés állapítja meg a vagyoneszközök ÉCS-leírását és értékét. A számítás célja szerint alkalmazhatók

− speciális ÉCS-leírási módok (tervszerinti ÉCS-leírás, különleges ÉCS-leírások stb.) − különféle ÉCS-leírási paraméterek (ÉCS-leírási módszer, használati idıtartam stb.) − különféle értékadatok (beszerzési és elıállítási költségek, újrabeszerzési értékek stb.).

Az értékelések kívánatos sokfélesége érdekében az AM rendszerben az eszközvagyont a teljes életcikluson keresztül egymással párhuzamosan, tetszılegesen sok különbözı értékvetületben kell vezetni. Az ehhez szükséges értékelési elıírásokat és ÉCS-leírási kulcsokat az ún. értékelési tervek tartalmazzák. Az értékelési terv az értékelési területek üzemgazdasági szempontok szerint felállí-tott jegyzéke.

Az AM és a pénzügyi könyvvitel közötti interfész lehetıvé teszi, hogy egy vagy több értékelési terület értékeit párhuzamosan feladják a megfelelı fıkönyvi számláknak. A feladott értékek alap-ján így a számviteli törvény szerinti mérleggel párhuzamosan, egy ettıl eltérı adójogi mérleget, vagy számviteli konszern-mérleget is létre lehet hozni az FI rendszerben.

Könyvelési technika alapja

Az AM rendszer minden mozgást ún. mozgásnemekkel azonosít. A mozgásnem meghatározza, hogy

− a számla-hozzárendelés mely számláit, − mely értékelési területeket, − mely értékmezıket

kell aktualizálni. Ezen túlmenıen a mozgásnem kiértékelési kritériumként mőködik a mozgáslis-tákon és az eszköztükörben. A standard mozgásnemek mellett saját mozgásnemek is definiálha-tók.

Ha a könyvelés során eszközre kontíroznak, az AM rendszer az úgynevezett számla-hozzárendelés útján meghatározza azokat a fıkönyvi számlákat, amelyekre könyvelni kell. A számla-hozzárendelést az eszköz-osztályban kell lerögzíteni. Ezekben az osztályokban értékelési terüle-tenként és mindenféle üzleti eseményre szabadon definiálhatók a hozzátartozó számlák.

Ha az eszközkönyvelést a CO és FI rendszerével integrálva vezetik be, akkor a könyvelendı üzle-ti események függvényében a következı kiegészítı kontírozások lehetségesek:

− Belsı rendelés/projekt − Költséghely/profit center − Mennyiségek és szöveges adatok.

Mindenekelıtt a kis értékő tárgyi eszközöket szokás győjtıeszközként vezetni. Ezért engedi meg az AM rendszer, hogy az eszközökre vonatkozóan mennyiségeket és mennyiségi egységeket kezelje-nek. A könyvelés során a mennyiség elıjelhelyes aktualizálása az eszközmozgás Tartozik/Követel kódjának megfelelıen történik.


60. oldal

Szabadon definiálható érvényességi feltételekkel a gazdasági események könyvelésénél a standard el-lenırzések mellett egyéni, adott esetben felhasználó-specifikus ellenırzéseket is meg lehet hatá-rozni. Minden mozgásnem-csoporthoz hozzá lehet rendelni egy érvényességi feltételt. Ez a felté-tel ellenırzi a rendszert, ha a felhasználó a mozgásnem-csoporttal szeretne könyvelést végrehaj-tani.

A sztornírozás

Minden olyan eszközmozgást, amelyhez elıáll egy könyvelési bizonylat, javítás esetén az FI rend-szerben, vagy közvetlenül az eszközkönyvelésben sztornírozni lehet.

Általánosan megjegyezhetı, hogy az AM modul az üzleti esemény típusától függıen azzal támo-gatja a felhasználót, hogy integrált könyvelést végez a kapcsolódó alkalmazásokkal, automatiku-san generálja a könyvelést, tömeges könyveléseket végez, standard és egyénileg definiálható mozgásnemeket használ, és ezáltal állandóan és biztosan aktuális és teljes információt nyújt az eszközgazdálkodás folyamataihoz.

6.3. KONTROLLING – CONTROLLING (CO)

A kontrolling egy vállalat összes folyamatát koordinálja, felügyeli és optimalizálja. Ehhez rögzíteni kell a belsı erıforrások felhasználását és a hozott teljesítményeket. A tényleges eredmények do-kumentálása mellett a tervezés a kontrolling egyik fı feladata. A ténylegesen elért eredmények és a tervek összehasonlításával megállapíthatók az eltérések. Ezek képezik az üzemi folyamatokba való beavatkozás alapját.

Az eredményességi számítások, mint pl. a fedezetszámítás, az egyes részterületek, valamint a teljes vállalat gazdaságosságának ellenırzését szolgálják és információt szolgáltatnak a menedzsment döntéseihez. Ezen keresztül támogatja a kontrolling az operatív és a stratégiai célok elérését.

21. ábra: A kontrolling modul tipikus felépítése

A CO-modul architektúrája

A költségszámítási szempontból fontos adatok automatikusan átkerülnek a pénzügyi könyvelés-bıl a kontrollingba. A költségek és az árbevételek különbözı objektumokhoz rendelhetıek. Ilyen objektumok például a költséghelyek, folyamatok, projektek, vevıi és gyártási rendelések. A pénz-


61. oldal

ügyi könyvelés vonatkozó számláit költségnemenként vagy árbevétel-fajtánként a kontrolling is önálló adatállományként vezeti. Ezáltal a kontrollingban szereplı értékek összehasonlíthatók és egyeztethetık a pénzügyi könyveléssel.

A CO-modul komponensei

A CO-modul több komponensbıl tevıdik össze, amelyek különbözı feladatok feldolgozására alkalmasak. A kontrollingban felmerülı tipikus kérdések és a megválaszolásukra szolgáló kompo-nensek a következık:

Milyen költségek merülnek fel a vállalatnál?

A költség-, és árbevétel-számításban győjtik a kontrolling számára a költségeket és az árbevételeket. A legtöbb érték automatikusan kerül a pénzügyi könyvelésbıl a kontrollingba. A költség-, és árbevé-tel-számításban csak azokat a költségeket határozzák meg, amelyek a pénzügyi könyvelésben egy-általán nem, vagy más ráfordítással szerepelnek.

Hogyan kezeljük a közvetett költségeket?

Sok vállalatnál jelentıs mértékben növekszik az a költséghányad, amely az elıállított termékekre vagy szolgáltatásokra közvetlenül nem terhelhetı. Amíg a termelés területén a költségellenırzés és optimalizálás igen fejlett, addig a közvetett költségek gyakran csak csekély mértékben láthatók át. A közvetett költségek felügyelete és továbbterhelése a következı két komponens feladata.

Gazdaságosan dolgoznak-e azokon a területeken, ahol a közvetett költségek felmerülnek?

A költséghely-számítás segítségével megvizsgálható, hogy a vállalatnál hol és milyen közvetett költ-ségek merülnek fel. Ezért a vállalatnak azon részterületeihez rendelik a költségeket, ahol azok keletkeztek. A lekönyvelt összegek és mennyiségek elszámolására számos eljárás áll rendelkezésre. Különösen a teljesítményszámításnál van arra lehetıség, hogy a költségeknek a nagy részét - amely eredetileg nem volt hozzárendelhetı a termékekhez - az okozati elvnek megfelelıen szá-molják el a termékekre.

Milyen költségkihatásai vannak az üzemi intézkedéseknek? Betartják-e a költség-kereteket?

Az általánosköltség-rendelésekkel a költségek intézkedés orientáltan győjthetık és ellenırizhetık. Az intézkedésekhez költségkeretek rendelhetık, amelyek betartását a rendszer automatikusan figyeli. Ha a költségkövetés mellett egy átfogó és komplex intézkedés (mint pl. vállalat részeinek újrater-vezése) logisztikai lebonyolítását is támogatni kell, akkor a projekt alkalmazását kell elınyben részesíteni a rendeléssel szemben.

Mennyibe kerül a termékem elıállítása?

A termékköltség-kontrolling meghatározza azokat a költségeket, amelyek egy termék elıállításánál vagy egy teljesítmény teljesítésekor keletkeznek. Ezen kívül megállapítható az ár alsó határa, ame-lyért érdemes a vállalatnak a készletét értékesítenie. Szimulálható, hogy a termelési eljárásban be-következett változások milyen hatással vannak az elıállítási költségekre.

Mennyire nyereségesek az egyes vállalati területek?

Napjainkban sok vállalatnál a vezetés decentralizált. A vállalat önálló területekre való felosztásá-val, ahol az adott terület felelıs a költségeiért és az árbevételeiért, áttekinthetıvé válik a teljes vállalat és növelhetı a hatékonyság.

A területek vezetıi bizonyos mértékig önálló vállalkozóként tevékenykednek. Eredményességük kiértékelésére szolgál a profitcenter-számítás, amely egy jól mőködı vállalati rendszerben különálló kontrolling számításként valósul meg. Ez azt jelenti, hogy a tényleges elszámolással párhuzamo-san statisztikailag vezetik.


62. oldal

Egy valóban fejlett rendszer esetében a profitcentereknél a költségek és az árbevételek mellett mutatószámok, mint pl. Return on Investment, Working Capital, és egyéb elemzések pl. Cash Flow stb. is kiszámíthatók.

Költségszámítási eljárások

Általánosságban elmondható, hogy a fejlett ERP rendszerek valamennyi használatos költségszá-mítási eljárást támogatják:

− Standardköltség-számítás / tényköltség-számítás

− Az elszámolt mennyiségek tetszés szerint értékelhetık terv- vagy ténytarifával.

− Teljesköltség-számítás / részköltség-számítás

− A teljes elszámolási láncon keresztül a költségek vezethetık fix és változó részként. Ez a teljesköltség-számítás mellett a részköltségek vizsgálatát is lehetıvé teszi.

− Közvetlenköltség- és fedezetszámítás

− Egy olyan eljárásmód is alkalmazható, amelynél a közvetett költségek kulcsok alapján tör-ténı szétosztása helyett, azokat döntési objektumokhoz rendelik az okozati elv alapján.

− Forgalmiköltség-eljárás / összköltségeljárás

− Az eredményszámítás végezhetı a forgalmiköltség-eljárás vagy az összköltségeljárás alap-ján. A forgalmiköltség-eljárásnál a periódus árbevételeivel a forgalom költségeit állítják szembe. Az összköltségeljárásnál a periódus árbevételeivel az összes költséget, a félkész- és késztermékek állományában bekövetkezett változásokat, a befejezetlen termelést és a saját gyártású termékeket állítják szembe.

Tervezés

Az interaktív tervezéshez a CO-modul valamennyi komponensében általában számos funkció áll rendelkezésre. A különbözı tervezési verziókban különbözı szcenáriók képezhetık le. Ezek a tervverziók másolhatók és átértékelhetık.

A fejlett rendszerek általában támogatják a kontrolling-osztály által végzett központi tervezést és az egyes munkatársak decentrális tervezését is.

Ahhoz, hogy a tervezés a legkisebb ráfordítással legyen elvégezhetı, a manuális adatbevitelt sok helyen automatizálják. A tervadatok átvehetık a logisztika és a számvitel más részterveibıl.

Az automatikus elszámolások a tervezés további könnyítését szolgálják. A tervezés összhangját és a más résztervekkel való egyeztetést a rendszerek általában automatikusan biztosítják.

Információs rendszerek

A Kontrolling modul nagy teljesítıképességő információs rendszerekkel rendelkezik. A kivételfi-gyelés és az adatállományban való interaktív navigálás az információ elıkészítését támogatja.

A szokásos vizsgálatokhoz standard beszámolók és elemzési útvonalak állnak rendelkezésre, me-lyek egyszerően kiegészíthetık cégspecifikus beszámolókká. A beszámoló megjelenítésébıl to-vábbi beszámolók hívhatók fel. Egy áttekintı beszámolóból legtöbbször egy érték például több közbensı lépésen keresztül egészen az egyedi tételekig vagy a könyvelési bizonylatokig követhetı.


63. oldal

22. ábra: Példa az elemzési útvonalra: egy eredmény-kimutatási tétel elemzése egészen bizonylatszintig.

6.4. LOGISZTIKAI MODULOK

6.4.1. Anyaggazdálkodás – Material Management (MM)

Az integrált logisztikai rendszer egyik fontos komponense az Anyaggazdálkodás, azaz angolul Material Management. Ez a modul támogatja a beszerzés optimális lebonyolítását, a korrekt kész-letvezetést, a pontos anyagszükséglet-tervezést, az átgondolt raktárgazdálkodást, a gondos szám-laellenırzést és egy átfogó információs rendszert biztosít a felhasználóknak.

A modul funkcióin keresztül segíti a leggazdaságosabb beszerzési forrás kiválasztását, naprakész információt nyújt a készletekrıl, a múltbeli és a várható felhasználásról, a tervezett készletnöve-kedésekrıl.

Áttekintés

SDSD

AlapadatokAlapadatok� Vevõk

� Szállítók

� Anyag

� Darabjegyzék CAD/KI

� Mûveletterv, karbantartásiterv, vizsg. terv, CAP

� Munkahely

� Gyártási segédeszköz

� Nagyvonalú tervezési terv

� Berendezés

� Dokumentum

� Osztályozás

�� MUNKAFOLYAMATOKMUNKAFOLYAMATOKSZERVEZÉSESZERVEZÉSE

�� SzövegfeldolgozásSzövegfeldolgozás�� LEVELEZÉSLEVELEZÉS�� KommunikációKommunikáció�� TELEFAX, EDI, ...TELEFAX, EDI, ...

�� TermékkalkulációTermékkalkuláció �� Kiszállítás, számlázás,Kiszállítás, számlázás,transzporttranszport

�� Vizsgálandó sorozat nagyságVizsgálandó sorozat nagyság�� Vizsg.rendelésVizsg.rendelés

SDSDVevõi rendelésekVevõi rendelésekkezelésekezelése

Vevõi igényVevõi igény

PPPPQMQM

Rendelés:Rendelés:- megnyitás- megnyitás- engedélyezés- engedélyezés- visszajelentés- visszajelentés

Gyártás-irányításGyártás-irányításKapacitás kiegyenlítésKapacitás kiegyenlítés

CAMCAM

�� HelyreállításHelyreállítás�� TMKTMK

PMPM

MMMM

KészletvezetésKészletvezetésÁrubeérkezésÁrubeérkezésKiértékelésKiértékelés

SzámlaellenõrzésSzámlaellenõrzés

RaktárgazdálkodásRaktárgazdálkodás

Tervren-Tervren-delésekdelések

MegnyitásiMegnyitásihorizonthorizont

ProgramtervezésProgramtervezésSzükségl. tervezésSzükségl. tervezés

Nagyvonalú kapacitásNagyvonalú kapacitástervezéstervezés

Közvetlen igénylésKözvetlen igénylés

�� HálótervHálóterv�� ProjektekProjektek

ProjektsystemProjektsystemEredménytervezésEredménytervezés

SOPSOPTerv-szükségletTerv-szükségletPrognózisokPrognózisok

Értékes.tervezésÉrtékes.tervezés

BeszerzésBeszerzés

23. ábra: Az MM modul integrációjának áttekintése


64. oldal

Az anyaggazdálkodási folyamat mőködéséhez nélkülözhetetlenek a törzsadatok. Ilyen törzsadat pl. az anyag és a szállító.

Beszerzés

A beszerzés folyamatát különbözı tranzakciók segítik a beszerzési igény felmerülésétıl, a beszerzési megrendelésen keresztül a különbözı szerzıdések létrehozásáig. Függetlenül attól, hogy a beszerzési igény az anyagdiszpozícióból, egy költséghelyrıl vagy egy vevıi rendelésbıl származik, a beszerzı azonnal felismeri a beszerzési szükséglet eredetét. Ezen túlmenıen arra is lehetıség kell, hogy nyíljon, hogy a beszerzési bizonylatok további feldolgozását csak engedélyezés után folytassuk. A beszerzési igény beszerzési megrendeléssé való átalakításához a beszerzınek általában a hatékony beszerzés-lebonyolítás egész láncolata rendelkezésére áll: az ajánlatkérésektıl és ajánlatoktól egészen a keretszerzıdésekig. Minden megrendelési mőveletnél lehetıség nyílik automatikus árösszehasonlításra. A szállítók minısítése lehetıvé teszi a szol-gáltatások és a minıség szempontjából legjobb szállító kiválasztását. A megrendelés költségei így minimalizálhatóak. A rendeléstörténet folyamatosan nyújt információt a beszerzési folyamat aktuális állapotáról, pl. áruk és számlák beérkezésérıl.

Készletvezetés

Közvetlenül az árubeérkezésnél sor kerül a kiszállított és a megrendelt anyagok és mennyiségek összehasonlítására. Az adatok legtöbbször automatikusan kerülnek átadásra a készletvezetésbıl a minıségbiztosítás (QM) felé. Minden növekedés vagy csökkenés azonnal aktualizálja a készletmennyiséget. Egyidejőleg a növekedés/csökkenés értéke, beleértve a felmerülı mellékköltségeket, mint pl. fuvar vagy vám, a pénzügyi könyvelésben (FI) kerül aktualizálásra. Függetlenül attól, hogy a leltározást egy határnapra vonatkoztatva, vagy pedig folyamatosan akarja-e végrehajtani, teljes számbavételként, szúrópróbaleltárként, vagy a Cycle-Counting-eljárás szerint - a rendszer rögzítési segítséggel és automatikus kiértékelésekkel támogatja a felhasználót. Ahhoz, hogy a vállalat készletei helyesen kerüljenek be a mérlegbe, különféle értékelési eljárások használhatóak, mint pl. LIFO, FIFO, HIFO. Ezen túlmenıen a fejlett rendszerekben funkciók széles spektruma áll rendelkezésre a készlet-kontrolling területén belül. Ez lehetıvé teszi pl. ABC-analízisek végrehajtását.

Raktárkezelés

A helyes be-, illetve kitárolási stratégia megválasztásával biztosítható a cikkek optimális raktárforgalma és ilyen módon csökkenthetık a raktárköltségek. A raktárgazdálkodási modul még komplex raktárstruktúrák esetében is áttekinthetı leképezést ad. Az igényeknek megfelelıen blokk-, fix-, ill. tárhelyes magasraktár alkalmazásával kerül sor a cikkek hatékony kezelésére és a szállítási utak minimalizálásásra. Vonalkód alkalmazásával minimálisra csökkenthetı a hibák száma és így idı takarítható meg. A készletvezetés és az értékesítés szoros integrációja a raktárgazdálkodással az áru gyors és kényelmes be- és kitárolása miatt is elınyös.

Számlaellenırzés

A számlaellenırzésnél egy integrált rendszer javaslatot tesz a kiszámítandó mennyiségekre és összegekre éppúgy, mint a skontóra és az adókra vonatkozóan. A számlaellenırnek csak akkor kell beavatkoznia, ha a számla eltéréseket mutat. Az eltérés minden fajtájára (mennyiségi, ár-, határidı- eltérések) vonatkozóan tőréshatárokat állapíthat meg. Ha az eltérések túllépik a tőréshatárokat, akkor a számla zárolásra kerül. Automatikus bevétel-elszámolásnál a rendszer a számlákat az árubeérkezések alapján a rendelésre való hivatkozással idıszakonként készíti el. Így nincs szükség a számlák szállítókon keresztüli továbbítására. Egy számla könyvelésekor a rendszer automatikusan továbbítja az információkat a pénzügyi könyvelés (FI), az


65. oldal

eszközkönyvelés (AM), és a költségszámítás (CO) felé. A logisztika-számlaellenırzésnél az anyag-gazdálkodás ellenırzései és a pénzügyi könyvelés könyvelései külön kerülnek végrehajtásra.

Beszerzési információs rendszer

A beszerzési információs rendszer valamint a szállítók minısítése biztosítja a megfelelı információt a szállítókkal történı tárgyalások elıkészítéséhez. A szállítók beszerzési megrendelései, árubeérkezései és számlái létrehozás után azonnal visszatükrözıdnek az információs rendszerben. A szállítók minısítése további fontos kritériumokat is kínál. Ezek pl. az ártörténet, a határidı és mennyiség betartása, a szállítási feltételek betartása és a termékminıség. Legtöbbször saját minısítési kritériumok definiálására is lehetıség van. Árak, árucsoportok vagy anyagok szerinti részletes kiértékelések támogatják a döntéshozatalt.

6.4.2. Termeléstervezés – Production Planning (PP)

A termelésirányítási modul a termelı profilú vállalatok menedzsmentje számára olyan hatékony eszközrendszert biztosít, melynek segítségével mindennapi irányítási feladataik elvégzéséhez nél-külözhetetlen támogatást kapnak: a termelést bonyolító rendszer szervezéséhez, a termelıfolya-mat mőködésének tervezéséhez, a mőködés elıfeltételeinek megteremtéséhez, végül a folyamat terv szerinti megvalósulásának és eredményeinek ellenırzéséhez.

A termelési folyamatot egy olyan döntésrendszer indítja el, amelyben meghatározásra kerül, hogy milyen késztermékbıl mennyit és milyen határidıre kell elıállítani. Ennek a döntésrendszernek az alapját többek között a vállalati rendelésállomány képezi.

Anyag-Anyag-ererõõforrásokforrások

Logisztikai folyamatokLogisztikai folyamatok

SzállítóSzállító

TermelésTermelésEladásEladás BeszerzésBeszerzés

�� Anyag Anyag

�� Szolgál- Szolgál- tatás tatás

FolyamatFolyamatRendelésRendelés RaktárRaktár RaktárRaktár

VevıVevı

�� Termék Termék

�� Szolgál- Szolgál- tatás tatás

MegrendelésMegrendelés

Kapacitás-erıforrásokKapacitás-erıforrások

Tıke-erıforrásokTıke-erıforrások

HosszúlejáratúHosszúlejáratú RövidlejáratúRövidlejáratú

A modell mint integrált logikai lánc

24. ábra: A logisztikai modell

A termeléstervezés és -irányítás lebonyolítása bizonyos alapadatokra épül. Ezek pl. a termelendı alapanyagok, darabjegyzékek, mővelettervek, munkahelyek, dokumentumok, gyártási segédeszkö-zök, stb.


66. oldal

6.4.3. A termeléstervezési modul néhány funkciója

Gyártás tervezés (MPS)

A gyártástervezés (Master Production Scheduling – MPS) eszközeivel a gyártási folyamat idıigé-nyére és ütemezésére vonatkozó, szükséges részletezettségő információkhoz juthatunk. Az MPS a szükséglet-elırejelzéseket, ügyfélrendeléseket – az ezekbıl eredı anyagszükségletek meghatározá-sán keresztül – képes az egyes termékösszetevıkkel szembeni szükségleteket idı, és mennyiségi dimenzióban számszerősíteni.

A Just-In-Time (JIT) jellegő gyártási ütemezést ez utóbbi funkció is támogatja, minek során a felhasználónak készenléti ütemezés áll rendelkezésére a késztermék fı komponenseire.

Anyagszükséglet tervezés (MRP)

Az anyagszükséglet tervezés (MRP) a részletes tervezési szintet jelenti a PP modulban. Fı funk-ciója, hogy az anyagok megfelelı mennyiségben és idıben rendelkezésre álljanak mind termelési, mind értékesítési szempontból.

Két fı típusát különböztethetjük meg. Egyik a készletfigyelésen alapuló ún. fogyasztásalapú szük-séglettervezés, mely vagy újrarendelési pont alapú vagy prognózis alapján dolgozó eljárást jelent. A másik a darabjegyzékek felbontásán alapuló ún. terv alapú szükséglettervezés, mely a készter-mékre vonatkozó független igényeket bontja le a komponensek szintjére.

Kapacitástervezés

A kapacitástervezés mindazon lépések összességét jelenti, amelyek a szabad kapacitás és a kapaci-tás-elosztás tervezéséhez szükségesek. A kapacitástervezés két szakaszra: a kapacitásértékelésre és a kapacitáskiegyenlítésre osztható fel.

A kapacitásértékelés felméri a szabad és a szükséges kapacitásmennyiséget, majd a két adatot ösz-szeveti. A kapacitáskiegyenlítés a munkahelyek kapacitásainak kihasználatlanságát vagy azok túl-terhelését korrigálja.

Karbantartás – Plant Maintenance (PM)

Az ERP rendszerekben a PM modul foglalja magába bármely iparág technikai rendszereinek üzemeltetését és karbantartását. A karbantartási tevékenység egyrészt irányulhat a saját technikai berendezésállomány karbantartására, másrészt vevık számára kínálható fel, mint áruhoz kapcso-lódó szolgáltatás.

Az alábbi karbantartási tevékenységeket támogatja a PM modul:

− Ellenırzés (a rendszer aktuális állapotának vizsgálata) − TMK (az optimális állapot fenntartása) − Javítás (az optimális állapot helyreállítása) − Módosítás (bár nem igazán karbantartási feladat, de a folyamat hasonlósága miatt szintén

kezelhetı a PM modullal)


67. oldal

25. ábra: A PM komponens funkcionális felépítése

6.4.4. Mőszaki rendszerek strukturálása

A PM rendszer lehetıvé teszi, hogy a mőszaki rendszereket/eszközöket a mőszaki helyek (funk-cionalitás, hely vagy folyamat szerint), berendezések, hozzátartozó szerelési egységek és alkatré-szek szerint – darabjegyzékek segítségével – egyszerő és áttekinthetı rendszerbe foglalja. Ez az alapja a karbantartási munkák tervezésének, végrehajtásának és késıbbi analízisének.

Karbantartás jelentések

A karbantartási jelentések lehetıvé teszik az üzemen belüli kivételes helyzetek egyszerő rögzítését és feldolgozását így azonnal megtehetık a szükséges intézkedések. Minden szükséges információ - mint például a meghibásodás helye és mőszaki objektum állapota - azonnal rendelkezésre áll a képernyın.

Karbantartási rendelések kezelése

A karbantartási rendelések tartalmazzák az elvégzendı tevékenység lépéseinek leírását, a szüksé-ges anyagok listáját az erıforrásokkal, az ütemezési adatokat, a mőszaki objektumokat amelyeken a karbantartást el kell végezni és a költségek lekönyvelésének szabályait.

Tervezhetıség szempontjából az alábbi karbantartás rendeléseket különböztetjük meg:

− TMK (tervezett megelızı karbantartás) karbantartás rendelések − Tervezett karbantartás − Nem-tervezett karbantartás rendelések

Erıforrások menedzselése

Karbantartási erıforrások alatt a munkahelyek által definiált szabad kapacitást, a tartalék alkatré-szeket és karbantartási anyagokat, a különbözı szerszámokat, rajzokat, speciális egységeket, szállí-tási eszközöket valamint a pénzügyi költségkereteket értjük, azaz mindazokat az erıforrásokat, amelyek szükségesek lehetnek a karbantartási munka elvégzéséhez és rendelkezésre állásuk ellen-ırizhetı.


68. oldal

Karbantartás információs rendszer

A Karbantartás Információs Rendszer (PMIS) egy rugalmas eszköz a karbantartási folyamatokból eredı adatok győjtésére, redukálására és analizálására. A PMIS célja, hogy a felhasználót ellássa az összes rávonatkozó és az általa használt alkalmazásokból eredı információkkal a legkülönfélébb vetületben.

6.4.5. Értékesítés – Sales and Distribution (SD)

Az SD-rendszer segítségével a vállalatok értékesítéssel szemben támasztott igényei gyorsan és célzottan kielégíthetık, valamint az adatok és információk a felhasználó számára könnyen elérhe-tıvé válnak.

Az értékesítési modul fıbb funkciói:

− Vevık nyilvántartása, − árajánlat kérések kezelése, − ajánlatok rögzítése, − megrendelések/szerzıdések kezelése, − szállítási ütemtervek készítése, − visszáruk kezelése, − dinamikus árképzés (különbözı kedvezmények kezelése), − számlázás (egyedi számla, győjtıszámla).

Eladás, Kiszállítás, Számlázás

Az értékesítés hatékonyságának növelése érdekében a megrendelések feldolgozását megbízhatóan kell végeznie az SD – Értékesítési és Disztribúciós modulnak. Az SD segítségével az összes érin-tett gazdasági terület adatai a megrendelés beérkezésével párhuzamosan aktualizálódnak.

Az eladások növelésének támogatása

Az SD értékesítés-támogatási összetevıje könnyen kezelhetı eszköz a telefonos, valamint a sze-mélyes érdeklıdık és a versenytársak tevékenységére vonatkozó információk nyilvántartásához. Ezek az információk felhasználhatóak az eladási tevékenységek tervezéséhez és kezeléséhez épp-úgy, mint új üzleti források feltárásához. Az erre jogosult személyek állandóan hozzáférhetnek a legfrissebb adatokhoz.

Megrendelés felvitel

A megrendelések feldolgozásához szükséges információhoz és értékeléshez automatikusan hoz-zájuthat a felhasználó a vállalat ügyfelei, az eladások és termékek adatait tartalmazó, részletes adatbázisból.

Az Anyaggazdálkodás (MM) és a Termelés-tervezés (PP) modulokkal való szoros kapcsolat révén az anyagok rendelkezésre-állása a megrendelés felvételének pillanatában ellenırizhetı. Azonnal ajánlatot lehet adni az ügyfélnek a lehetı leggyorsabb szállítási határidıvel. Az ügyfelek a meg-rendelés-visszaigazolást automatikusan kapják levélben, faxon vagy az EDI-n keresztül. Az ügyfe-lekhez igazodva választhatja meg a dokumentumok nyelvét és pénznemét. Az árazási eljárásokkal - amelyek automatikusan végrehajtódnak a megrendelés felvitelekor - még a legbonyolultabb ár-struktúrák is egyszerően definiálhatóak a rendszerben.


69. oldal

Ügyfél

AnyagDarabjegyzékÉrtékesítésicsoportokVálaszték

Vevõi anyaginformáció

Osztályozás

Szövegek

Feltételek

Értékesítési adók

Statisztikák

Ért

ékes

ítés

i inf

orm

áció

ren

dsze

r

FI

PS

PP

MM

MM

CO

FI

CO

MM

Törzsadatok

Anyaggazdálkodás

Termeléstervezés

Controlling

Pénzügyi számvitel

Projekt-rendszer

Készletnyilvántartás

Raktári nyilvántartás

Vevõfolyószámla-könyvelés

Eredményszámítás

VevõkapcsolatokLevelezés

KomissiózásCsomagolásSzállítás

Egyedi számlaGyûjtõszámlaSzámlajegyzékMegerhelés / jóváírás

AjánlatkérésAjánlatokRendelésfeldolgozás

Kiszállítás

Számlázás

Eladás

Értékesítési támogatás

26. ábra: Az értékesítés integráltsága egy ERP rendszerben

6.4.6. Minıségmenedzsment – Quality Management (QM)

Az ERP rendszerek a minıségbiztosítás átfogó feladatainak ellátását úgy oldják meg, hogy ezen feladatok rögzítését az érintett alkalmazásokon belül (pl. beszerzésben, raktározásban, gyártásban, értékesítésben) végzik el, ezáltal biztosítják az összetartozó adatok többszörös rögzítésének és mentésének elkerülését. Ezen kezdeményezés alapján a minıségi kézikönyvben lefektetett folya-matok az elektronikus adatfeldolgozó rendszeren hően leképezhetık és automatizálhatók.

Az integrált rendszerek általában átfogó módon támogatják az ISO 9000 szabványnak megfelelı minıségbiztosítási rendszer elemeit.

A logisztikai rendszeren belül elhelyezkedı QM modullal elsısorban a klasszikus minıségbiztosí-tási feladatokat, a minıségtervezést, a minıségvizsgálatot és a minıségirányítás feladatait tudjuk ellátni.

A minıségbiztosítás a logisztikai láncban

Árajánlat-kérés

Szállítókiválasztása

Megrendelés RendelésÁrubeérkezésMMMM

QMQM

Alapadatok- Vizsgálati tervek- Vizsgálati jellemzõk- Mûszaki szállítási feltételek- QS-egyezmények- . . .

PPPP

Lebonyolítás- Árubeérkezés ellenõrzése- Árukimenet ellenõrzése- A gyártást kísérõ ellenõrzések

QM-Controlling- Minõség-auditálás- Minõség-kódok- Szállítók megítélése- . . .

27. ábra: Minıségbiztosítás


70. oldal

6.4.7. A QM modul belsı funkciói

Minıségtervezés.

− A minıségtervezés és vizsgálattervezés alapadatainak kezelése, − Anyagspecifikációk, − Vizsgálattervezés, − Minıségvizsgálat,

− Vizsgálatok elndítása, − Vizsgálatok lebonyolítása vizsgálatterv kiválasztásával és szúrópróba számítással, − Munkapapírok nyomtatása próbavételhez és a vizsgálatokhoz, − Eredményrögzítés és hibarögzítés, − Felhasználási döntés és követı mőveletek.

Minıségirányítás.

− Dinamikus szúrópróba-meghatározás a minıségi helyzetnek megfelelıen, − Statisztikai folyamatirányítás, minıségellenırzı diagramok, − Minıségi mutatószámok a vizsgálandó sorozatokhoz, − Belsı és külsı problémákhoz kapcsolódó minıségi jelentések, korrekciós intézkedések, − A probléma-feldolgozás és a vizsgálandó sorozatok kezelésének rá kapcsolása a

workflow-komponensre, − QM információs rendszer vizsgálatokhoz és vizsgálati eredményekhez, − QM információs rendszer minıségi jelentésekhez.

Emberi erıforrások – Human Resources (HR)

A HR modul a nagyobb ERP rendszerek esetében két részmodulból áll:

− PA (személyügyi adminisztráció) − PD (személyügyi fejlesztés)

E két részmodul a humánpolitika területén belül más és más feladatokat fed le.

6.4.8. PA Modul (Személyügyi Adminisztráció)

Személyzeti törzsadat kezelés

A személyzeti törzsadat kezelı rendszerben rögzítheti, karbantarthatja, elmentheti és nyilvántart-hatja a személyekre vonatkozó adatokat. A rendszer minden munkatársat egyértelmően besorol a vállalati struktúrába, azaz hozzárendeli egy szervezeti egységhez.

Adattörténet

A HR-rendszerben az összes adat érvényességi dátummal tárolódik. Az aktuális adatok bevitelé-nél a már meglévı rekordok idıbeni érvényessége automatikusan lehatárolódik. Ezáltal az adatok idıbeni sorrendje mindenkor áttekinthetı marad, és a korábban érvényes információk, mint pl. a kereset alakulása, bármikor megjeleníthetık és kiértékelhetık.

Idıgazdálkodás

Az idıgazdálkodást általánosan két különbözı formában lehet kialakítani, ahol azonban vegyes formák is lehetségesek. A negatív rögzítésnél a munkarend alapján csupán a kivételek kerülnek rögzítésre: távollétek, helyettesítések vagy többletmunkák. A pozitív rögzítés kiegészíti a negatív rögzítést a tényleges érkezési/távozási idıkkel.


71. oldal

A munkarend optimális kialakítása

Az idıgazdálkodás mindegyik formájának alapja az ún. munkarend. A munkarend naptár szerint definiálja személyek (vagy gépek) munkaidejét. A munkarend moduláris felépítése megengedi a definiált napi munkaidık vagy idımodellek hatékony karbantartását és többszöri felhasználását.

Bérszámfejtés

A HR-bérszámfejtést országspecifikus verziók formájában kínálják, amelyek tartalmazzák a min-denkori követelményeket. A bérszámfejtés általános nemzetközi funkcionalitása lehetıséget biz-tosít a bruttó bér országfüggetlen meghatározására, az idıadatok adminisztrációjának figyelembe-vételével.

TB elszámolás

A TB számfejtés a Társadalombiztosítás által nyújtott ellátások számszerő összegének megállapí-tását végzi. Ehhez a rendszer egyrészt a dolgozó törzsadatait, másrészt a dolgozónak feladott távolléteket használja fel.

6.4.9. PD modul (Személyügyi fejlesztés)

Munkaerı gazdálkodás

− Vállalati általános és specifikus munkaköri leírások kezelése − Betöltött/üres pozíciókkal való gazdálkodás − Vállalaton belüli átcsoportosítás, áthelyezés − Pályázatok, álláshirdetés kiírása, pályázók kezelése − Pályagondozás

Vállalati személyügyi költséggazdálkodás

A HR modul PD részmodulja igen komoly segítséget nyújt a vállalati bérköltségek tervezésénél mind vállalati, mind pedig részegységi szinten. Természetesen nem csak a bér és bér jellegő költ-ségek tervezhetık, hanem minden egyéb, a dolgozóval kapcsolatos költségelem is bevihetı a rendszerbe.

Teljesítménytervezési és értékelési rendszer

− Tervezési rendszer kialakítása − A rendszer mőködtetésének biztosítása − Tervezési folyamat kialakítása, eredmények rögzítése − Értékelés lefolytatása, eredmények rögzítése

Oktatási, képzési tevékenység tervezése, hatékonyság mérése

− Oktatási igények és képzési lehetıségek felmérése, valamint egyeztetésük − Oktatási terv készítése − A megvalósuló oktatások lebonyolítása − A hatékonyság mérése − Az egyes munkavállaló összes képzettségének nyilvántartása, összevetése a pályagondo-

zási tervvel − Képesítés szerinti lekérdezés lehetısége − Az oktatás költségeinek nyilvántartása


72. oldal

Béren kívüli juttatások nyilvántartása

− Szociális kiadások nyilvántartása − Egészségügyi ellátás nyilvántartása − Étkezési térítések nyilvántartása

Rendezvény-menedzsment

− Konferenciák szervezése, lebonyolítása − Vállalati értekezletek szervezése, belsı erıforrás biztosítás, lebonyolítás

6.4.10. Projekt rendszer – Project System (PS)

A projekt szervezés kulcsfeladatainak (tervezés, kivitelezés, ellenırzés) gördülékeny ellátásához hatékony eszközöket biztosít a PS modul. Magában foglal a projektstruktúrától kezdve a hálóter-vezésen át a projektbeszámolóig minden részterületet. Ezzel segíti a döntés-elıkészítést és opti-malizálja a projekt végrehajtásának üzleti folyamatait.

A rendszerrel a projekt típusok széles köre kezelhetı:

− nagy volumenő saját beruházások − marketing kampányok − üzemi mérnöki fejlesztés, kivitelezés, − összetett egyedi gyártási folyamatok, − kutatás, és fejlesztés, − projektszerő szolgáltatások, − üzemgazdálkodás.

28. ábra: Projekt menedzsment


73. oldal

A PS modul igen részletes, több dimenzióban megvalósítható, pontos tervezhetıséget, tényadat-kezelést biztosít a következı területeken:

− kapacitástervezés, − erıforrás-tervezés, − idıtervezés, − költségtervezés, − bevételtervezés.

A PS modulban a projektstruktúra kétféle szempont szerint építhetı fel:

− szervezeti struktúra (projekt-struktúra terv), − idıbeli struktúra (hálóterv).

Az információs rendszer

A PS eszközeivel a projekt kiértékelésének szerkezetét, és részletességét szabadon lehet meghatá-rozni. Ezáltal a projekt állapotáról bármikor világos kép alakítható ki.

Az információs rendszerrel a tervezett és valós pénzügyi adatok (kiadások, bevételek) összeha-sonlíthatóvá válnak. A projektütemezés, kapacitás, és a határidık monitorozásával az azokra vo-natkozó tervezett és valós adatok szintén összehasonlíthatóak.

Kommunikáció a PS-ben

A PS-ben rögzített projekt adatok felhasználhatóak más projektek decentralizált tervezéséhez. A projektrendszert magas fokon integrált rendszerek esetében kommunikációs csatornák kötik ösz-sze az MS-Excel és az MS-Project programokkal. Az elektronikus adatcserét biztosító EDI lehe-tıvé teszi az értékesítési, és a beszerzési modulból történı adatok megosztását a partnercégekkel.

6.5. CRM – CUSTOMER RELATIONSHIP MANAGEMENT

Az utóbbi években egyre többet hallhatunk a CRM-rıl (ügyfélkapcsolat kezelés), amelynek tar-talmát mindenki máshogy értelmezi. Ha megkérdezzük különbözı vállalatok vezetıit szükségük van-e CRM-re, mindenki azt mondja, hogy igen, de egyrészt mindenki mást ért rajta, másrészt mindenki másképp indokolja a miértjét. Talán az alábbi fogalom megvilágítja azt, hogy miért is.

Customer Relationship Management (CRM) fogalma

A CRM olyan folyamatok és rendszerek együttese, amelyek a cég üzleti stratégiáját támogatják, hogy az képes legyen hosszú távú és profitábilis kapcsolatok kialakítására az egyedi ügyfelekkel.

A CRM kialakulását a következık tették szükségessé:

− Növekvı verseny (dereguláció, egységes piac, alacsony költségő versenytársak), − Csökkenı ügyfél lojalitás, − Csökkenı bevételek (több ügyfél, alacsonyabb árak), − Növekvı marketing és értékesítési költségek (több termék és szolgáltatás, rövidebb ciklus

idık, több érintkezési felület az ügyfélhez).

Az ügyfél elvárásai a beszállítóival szemben ezzel egyidejőleg megnıttek. Az ügyfélnek az lett a fontos, hogy kitőnı terméket és/vagy szolgáltatást, a lehetı legalacsonyabb áron, személyre sza-bott és gyors kiszolgálással, érdekes és személyre szabott marketinggel kapjon.

Annak érdekében, hogy ezeket az ügyfél elvárásokat a beszállítók teljesíteni tudják négy üzleti területen alakítottak ki megoldásokat az ügyfelekkel való kapcsolattartásra.


74. oldal

A CRM fı területei tehát:

− marketing, − értékesítés, − szerviz/szolgáltatások, − call center

A fenti feladatok elvégzésére természetesen már számos standard szoftver és sok saját fejlesztés áll rendelkezésre. Standard szoftvert tud biztosítani ezen a területen például az Oracle, a Peoplesoft és az SAP a nagy ERP szoftverszállítók közül, de vannak olyan cégek, akik ún. stand-alone terméket alakítottak ki, ilyen például a Marketforce vagy a Siebel.

6.5.1. A marketing modul funkcionalitása

A Marketing olyan eszközöket és funkciókat bocsát rendelkezésre, amelyeknek az értékesítési stratégia kidolgozásakor lehet különösen jó hasznát venni. Segítségével ugyanis nemcsak hatéko-nyan tervezhetık az értékesítési programok, hanem végrehajtásuk is ellenırizhetıvé és ezáltal értékelhetıvé válik, sıt az egész értékesítési stratégia mintegy beágyazódik, integrálódik a vállalat üzleti folyamatainak egészébe.

Ezzel a modullal végrehajtható szegmenselemzés, adatbázisra épülı piacelemzés és -kutatás. Ezeknek az elemzési eszközöknek a segítségével a termék- ill. termékcsoport-menedzserek pontosabban meg tudják határozni a megcélzott piacot és eredményesebben tudják kiértékelni az egyes értékesítési programok hatását. Egyszerő és gyors hozzáférést tesz lehetıvé a vállalat egészében az informá-ciókhoz, származzanak azok akár belsı, akár pedig külsı forrásból.

Integrálja a konszolidált adatokat az értékesítés adataival, így mindenkor áttekinthetı képet tük-röz az aktuális piaci részesedésrıl és az egyéb piaci pozíciókról. A termékmenedzserek éppen olyan pontosan tervezhetnek vele termékbevezetést, mint termékciklusra vonatkozó stratégiát. A tervezéskor figyelembe vehetı még az árváltozás, a prognózisok eredménye vagy a csomagolás és a termékcsalád módosulása is. A meglévı vevıi adatbázisok alapján a Marketing modul támogatja a kapcsolattartási tevékenységeket, megkönnyíti a tervezést, a költségkeret-tervezést, a reklámkampányok végre-hajtását, ill. sikerességük ellenırzését. A modul segítségével könnyebben exportálhatók ill. importál-hatók listák, létrehozhatók szórólapok, lebonyolítható telefonmarketing vagy e-mail-akció.

6.5.2. Az értékesítési modul bemutatása

Az értékesítési modul támogatja az összes értékesítés-fajtát, legyen szó személyes megbeszélésrıl, telefonos kapcsolatról vagy közvetett kapcsolatfelvételrıl az interneten keresztül. Fusson be bár-melyik csatornán is a vevıi rendelés, a rendszer megállapítja az adott esetben érvényes szabályo-kat, a hitelellenırzéstıl kezdve az egyes vevıkkel kötött külön megállapodásokon át a rendkívüli engedményekig, és egyúttal mindent megjeleníthetıvé is tesz.

A vállalat és ügyfelei három legfontosabb találkozási pontja:

− személyes (pl. ügyfélszolgálati iroda) − call Center − internet


75. oldal

Mobile Sales fogalma

A Mobile Sales olyan eszközöket biztosít, amelyek az „offline”, a vállalaton kívüli értékesítés igé-nyeire vannak szabva.

Cél:

− az ügyfelek, termékek, szolgáltatások, versenytársak, üzleti lehetıségek, értékesítési tevékeny-ségek, ajánlatok, megrendelések, stb. körében a teljes átlátás biztosítása.

− Egyszeri navigáció a teljes ügyfélnézetért.

A Mobile Sales funkcionális területei

Tevékenység - Naptár

Ügyfél információk, üzleti lehetıségek vagy kontaktszemélyek adatainak bárhonnan és bármikori elérése.

Biztosítja az értékesítési csapat számára az eszközt a tervezés, dokumentálás, nyomon kö-vetés, ügyféllátogatás, telefonhívások, levelezések, szemináriumok vagy egyéb események kézbentartásához.

Kontakt személyek

Active Contact Management -Értékesítési csapaton belüli információ megosztás.

Nagymérető címlista a külsı, belsı vagy privát ügyfelekrıl.

A kapcsolatokról mindennemő információ elérését biztosítja.

Promóció - Kampány

Kampányok megtervezése és eredményességének mérése.

Marketing akciók összeállításában, értékesítési kampányok vagy termék bevezetési kam-pányok megtervezésében nyújt segítséget.

Termék - Szolgáltatás

Termékek és szolgáltatások adatainak azonnali elérése.

Az értékesítés szempontjából releváns termék és szolgáltatás információk elektronikus adatbázisa.

Beszámoló - Elemzés

Naprakész beszámolók. Iparági specifikus és standard riportok felhasználása, saját ripor-tok szerkesztése online és offline.

Ajánlat - Megrendelés

Értékesítési munkatárs számára template dokumentumok készíthetık el, amelyek a min-dennapi értékesítést segítik.

Felhasználók személyre szabott ajánlatot készíthetnek felhasználva a már meglévı ajánla-tok, megrendelések, szerzıdések mintáit.

Workbench

Alacsony bevezetési költségek (TCO) a gyors implementálásnak köszönhetıen.


76. oldal

A Mobile Sales paraméterezésére szolgáló eszköz, a vállalat igényei szerinti beállítások lét-rehozása.

Termék/Szolgáltatás konfiguráció - Árazás

A termék/szolgáltatás konfigurációs és árazási modellek használata off-line környezetben, az értékesítés helyszínén saját laptopon.

Egy modell, több alkalmazási környezet.

Üzleti lehetıségek

Üzleti lehetıségek áttekintése, problémák gyors felismerése és a megfelelı lépések elkészí-tése.

A teljes értékesítési ciklus alatt az üzleti lehetıségek alakulásának nyomon követése.

Egyéni Infocenter (Marketing Encyclopedia)

Megfelelı információ a megfelelı helyen a megfelelı embernek.

Külsı és belsı vállalati információk központi tárháza, ahol az információk kategorizálva érhetık el.

Megállapodások

Ügyféllel kapcsolatos információk fontos forrása, „a szó elszáll, az írás marad”.

Az összes ügyféllel kötött jogi vagy akár csak üzleti megállapodások tárhelye, de bármilyen más partnerekkel, versenytársakkal kapcsolatos megállapodás is itt található meg.

Üzleti Partnerek

Az értékesítési csapat minden tagja számára biztosítja az ügyfelekrıl a naprakész informá-ciót.

Direkt és indirekt információk menedzsmentje az üzleti partnerekrıl, pl. vevık, potenciá-lis ügyfelek, disztribútorok, versenytársak, partnerek stb.

Szerviz / Szolgáltatások modul

Ez a modul mindenféle vevıszolgálati funkciót támogat, a telefonos tanácsadástól kezdve a pót-alkatrészek szállításán át a nyújtott szolgáltatás kiszámlázásáig.

Segítséget nyújt abban, hogy a vállalat a legmegfelelıbb vevıszolgálatot biztosíthassa a nap hu-szonnégy órájában. Az optimális kihasználhatóságot leginkább ugyanis az összes információ, hozzáférési és ellenırzési jogosultság rendelkezésre állása biztosítja.

Szolgáltatáskörébe tartozik továbbá az installálási segítség, a javítás lebonyolítás, a szolgáltatási keretszerzıdések, a külsı vevıszolgálat, az ügyfélkapcsolati központok távközlési integrációja, a külsı vevıszolgálati kommunikáció támogatása.

Call center modul

A call center modul alapvetı funkcionalitása az adott vállalatnál lévı call center-ben dolgozók munkájának támogatása. Sok esetben ezt Customer Interaction Center-nek (Ügyfélszolgálat) ne-vezik. Ebbıl a modulból (képernyırıl) általában elérhetı valamennyi olyan funkcionalitás, amely-re az ügyfélszolgálaton dolgozó munkatársnak szüksége lehet. Ilyen például az ügyfél alapadatai, amelyek a beazonosításhoz szükségesek (pl. név, cím, ügyfélszám, stb.), az ügyfélhez tartozó pénzügyi helyzet (pl. számlaegyenleg), a szolgáltatásokhoz tartozó tevékenységek (pl. szerviz), stb.


77. oldal

79. oldal

7. ADATBÁZISOK ÉS ADATTÁRHÁZAK – AZ INFORMÁCIÓS RENDSZEREK ADATKEZELİI

Az elsı adatfeldolgozó rendszerek néhány fájlban tárolt kis mennyiségő adattal dolgoztak, amely csak egyetlen számítógépen volt elérhetı. Késıbb az adatok mennyisége és bonyolultsága egyre növekedett, az adatokat használó felhasználók számával együtt. Az adatokat már nemcsak tárol-ták és visszakeresték, hanem különbözı alkalmazások segítségével feldolgozták, elemezték azo-kat. A számítógépes világhálózat létrejöttével pedig felmerült az igény, hogy a tárolt adatokhoz a világ bármely pontjáról hozzá lehessen férni. Ezek az elvárások egyre sokrétőbb adatkezelı esz-közök kidolgozását igényelték, így alakultak ki a ma széleskörően használt adatbáziskezelı rend-szerek, majd a különbözı adatforrásokból származó adatokat integráló adattárházak.

ADATBÁZISOK ÉS ADATBÁZISKEZELİ RENDSZEREK

A vállalati információs rendszerekhez tartozó nagymennyiségő adatot adatbázisokba szervezve tárolják a számítógépek háttértárain.

Az adatbázis együtt tárolt, egymással összefüggı adatok rendszere. Az adatok meghatározott szer-kezet szerint kerülnek tárolásra, ez a szerkezet az adatbázis struktúrája. A struktúra leírását szintén az adatbázisban tárolják, ezt az adatbázis sémájának nevezzük, a séma leírására szolgáló adatokat szokás metaadatoknak is hívni. Az adatbázisok fájlokból épülnek fel, de speciális szerkezetük miatt hagyományos fájlkezelı rendszerekkel nem lehet a bennük tárolt adatokhoz hozzáférni. Az adat-bázisok kezelésére adatbáziskezelı rendszereket fejlesztettek ki. Az adatbáziskezelı rendszer (ABKR) egy programcsomag (szoftver), amely tulajdonképpen egy bonyolult fájlkezelı rendszer. Ennek része a tényleges adatkezelést végzı program, az adatbázis motorja (engine). A korszerő adatbáziskezelı rendszerek nagyrészt interaktív módon mőködnek, vagyis párbeszédet folytatnak a felhasználóval, aki megfogalmazza kéréseit, és a program azonnal végrehajtja azokat.

A felhasználó, illetve azok az alkalmazások, amelyek segítségével a felhasználó az adatbázisban tárolt adatokat feldolgozza, csak az adatbáziskezelı rendszeren keresztül férhetnek hozzá az adatbázisban tárolt adatokhoz.

Egy adatbáziskezelı rendszer legfontosabb feladatai:

− az adatbázis létrehozása − az adatok karbantartása − az adatok lekérdezésének biztosítása − a felhasználók munkájának szinkronizálása − az adatok védelme

Az adatok karbantartásán az új adatok felvitelét, a meglévı adatok módosítását, vagy törlését ért-jük. A legtöbb adatbáziskezelı rendszer a karbantartó mőveleteket tranzakciókként kezeli. Egy tranzakció egy felhasználó által végzett karbantartó mőveletek sorozatából áll. A tranzakció során végrehajtott módosítások nem kerülnek be ténylegesen az adatbázisba egészen addig, amíg a fel-használó egy COMMIT utasítás segítségével meg nem erısíti azokat. Ezzel egyben lezárja a tranzakciót, a következı karbantartó utasítással egy új tranzakció kezdıdik. Amíg a felhasználó nem zárta le a tranzakciót, alapértelmezés szerint a többi felhasználó az adatok eredeti állapotát látja. Ha a felhasználó nem kívánja megerısíteni a tranzakció során elvégzett mőveleteket, akkor a ROLLBACK utasítás segítségével törölheti a tranzakció során végrehajtott adatváltoztatásokat.


80. oldal

Az adatbáziskezelı rendszerek lehetıvé teszik az AUTOCOMMIT beállítását, ekkor minden karbantartó utasítás után automatikusan megtörténik a COMMIT.

29. ábra: A felhasználók az adatbáziskezelı rendszeren keresztül érik el az adatbázisban tárolt adatokat

A felhasználók munkájának szinkronizálására akkor van szükség, ha az adatbázis adataihoz egy-szerre több felhasználó is hozzáférhet. Ekkor az adatbáziskezelı rendszernek biztosítania kell, hogy ne történjen adatvesztés, vagy hibás adatfelvitel. Ugyanazt az adatot egy idıben több fel-használó is kiolvashatja az adatbázisból, ez nem okoz semmilyen problémát. Az adatok módosítá-sa nem közvetlenül az adathordozón történik, hanem a módosítandó rekord beolvasásra kerül a felhasználó számítógépének memóriájába, ott megtörténik a módosítás, majd a rekord visszaíró-dik az adathordozóra. Ha ugyanazt az adatrekordot egy idıben két felhasználó is módosítaná, akkor elıször mindketten kiolvassák a rekordot, elvégzik a módosítást, majd az a felhasználó, aki elıbb végzett a módosítással, visszaírja a rekordot, ezután a másik felhasználó is visszaírja az álta-la módosított rekordot, ezzel felülírja az elsı felhasználó módosítását. Ezért nem lehet megen-gedni, hogy egy adatrekordot egyszerre többen módosítsanak. Ennek legelterjedtebb módszere a rekord zárolása. A módosítás elıtt a rekordot zárolni kell, a módosítás befejezése után pedig a zárolást fel kell oldani. Amíg egy rekord zárolva van, addig azt más felhasználó nem zárolhatja, így nem is módosíthatja, a tartalmát azonban bárki kiolvashatja. Szükség esetén egy adatbázisban nagyobb egységek is zárolhatók, akár a teljes adatbázis is. Kevésbé elterjedt szinkronizációs eljárás az, amikor a rekordok az adatmezıkön kívül tartalmaznak még egy kódmezıt is, amelynek tar-talma mindig megváltozik, ha a rekordot visszaírják. Ennek segítségével ellenırizhetı, hogy a rekord kiolvasása óta történt-e módosítás a rekordban. Itt az adatbáziskezelı rendszer nem aka-dályozza meg az egyidejő módosítást, hanem a rekord visszaírásakor ellenırzi, hogy az adathor-dozón levı rekord kódmezıje megegyezik-e a visszaírandó rekord kódmezıjével. Ha igen, az azt

Adatbázisok és adattárházak – az információs rendszerek adatkezelıi

81. oldal

jelenti, hogy a kiolvasás óta nem módosult a rekord, így engedélyezi a visszaírást, ha nem, a re-kordot újra ki kell olvasni, és újra el kell végezni a módosítást.

Az adatbázisban tárolt adatokat több szempontból is védeni kell. Ki kell szőrni az adatfelvitel során az esetleges hibás adatokat, védekezni kell az illetéktelen felhasználók ellen, valamint meg kell védeni az adatbázis adatait az adathordozók fizikai sérüléseitıl. Az adatbázisba bekerülı adatokra vonatkozó megszorításokat részben az adatbázis sémájában lehet leírni, részben pedig az adatkar-bantartásra szolgáló alkalmazásban. Ilyen megszorítások lehetnek például az értékhatárok, vagy az értékkészlet megadása, továbbá megkövetelhetjük az adatok közötti bizonyos összefüggések meg-létét is. Az adatbáziskezelı rendszer nem enged olyan adatot bevinni az adatbázisba, amely nem felel meg a sémában elıírtaknak (típus, méret, megszorítások), vagy nem teljesülnek rá az össze-függések, például egy dolgozó munkahelye csak olyan osztály lehet, amelyik a szervezeti felépí-tésben szerepel.

Az adatokhoz történı illetéktelen hozzáférések megakadályozására a felhasználók azonosítót kapnak, és csak jelszó segítségével férhetnek hozzá az adatbázisban tárolt adatokhoz. A felhasz-nálói névhez különbözı jogok rendelhetık, például lekérdezési jog, vagy módosítási jog. Az adatbázisban található objektumokhoz szintén rendelhetık jogok. A felhasználó tényleges jogát egy objektum esetén a felhasználóhoz rendelt jogok és az objektumokhoz rendelt jogok metszete adja, vagyis például csak akkor módosíthatja az objektumban tárolt adatokat, ha rendelkezik mó-dosítási joggal, és az objektumon is engedélyezett a módosítás. Az objektumokhoz rendelt jogok segítségével bizonyos objektumok elrejthetık a felhasználók elıl, így minden felhasználó az adat-bázisnak csak azon részét látja, amelyikre a munkájához szüksége van. Mivel az adatbázisok bo-nyolult belsı szerkezet szerint épülnek fel, operációsrendszer szintrıl többnyire nem értelmezhe-tı az adatbázis-állományok adattartalma, tehát azok a felhasználók, akik nem jogosultak az adat-bázisba történı belépésre, operációs rendszer szintrıl sem tudnak hozzáférni az adatbázis adatai-hoz.

Az adatbázisban tárolt adatokat meg kell védeni attól, hogy a számítógép valamely elemének meghibásodása, vagy programhiba miatt megsérüljenek, vagy akár teljesen megsemmisüljenek. Ennek legegyszerőbb módja az, ha az adatbázist alkotó fájlokról idırıl-idıre biztonsági másola-tot készítünk (teljes mentés). Ez a módszer azonban nem használható nagy adatbázisok esetén, és nem elegendı nagyon változékony adatbázisoknál sem (például banki alkalmazások). On-line mentés alkalmazása esetén a két teljes mentés között történı módosításokat egy külön állomány-ba mentik, párhuzamosan a módosítás elvégzésével. Egy esetleges meghibásodáskor vissza kell tölteni az utolsó teljes mentést, majd átvezetni rajta az azóta történt módosításokat. Így gyakorla-tilag a hiba bekövetkeztekor fennállt állapotot lehet visszaállítani, csak a le nem zárt tranzakciók módosításai vesznek el. Nagymértékben növeli az adatbiztonságot, ha az adatbázist több pél-dányban tároljuk, más-más adathordozókon. Ezt az adatbázis tükrözésének nevezzük. Ilyenkor a módosításokat mindegyik példányon át kell vezetni.

Nagyobb adatbázisok üzemeltetését nem lehet a felhasználókra bízni. Szükség van olyan személy-re, vagy személyek egy csoportjára, aki az adatbázis mőködéséért felelıs. İ az adatbázis-adminisztrátor (DataBase Administrator, DBA). Az ı feladatai közé tartozik az adatbázis létrehozá-sa, az adatbáziskezelı rendszer indítása, leállítása, a felhasználói jogok meghatározása és a fizikai adatvédelem.

A szoftver-piacon számos adatbáziskezelı rendszer található. Minden adatbázistípushoz saját adatbáziskezelı rendszer tartozik, egy adatbáziskezelı csak azokat az adatbázisokat tudja feldol-gozni, amelyeket ugyanezzel a típusú adatbáziskezelı rendszerrel hoztak létre, ugyanis a különbö-zı adatbázisok belsı szerkezete nagymértékben eltér egymástól. Sok esetben ugyanannak az adatbáziskezelınek a különbözı verziói sem egyforma felépítéső adatbázisszerkezetet hoznak létre, így ha át akarunk térni egy másik verzióra, az adatbázist át kell konvertálni. Az adatbázisok belsı felépítése, valamint az adatok elérési módja döntıen befolyásolja az adatbáziskezelés sebes-


82. oldal

ségét. A különbözı adatbáziskezelı rendszerek versenyének ez az egyik legfontosabb területe. A sebességek összehasonlítására úgynevezett benchmark teszteket végeznek, amelyek során nagy adatmennyiséggel nagytömegő tranzakciót és lekérdezést hajtanak végre.

A vezetı adatbáziskezelı rendszereket általában nemcsak egy platformra dolgozzák ki, hanem a legelterjedtebb operációsrendszerek mindegyikére (pl. Windows, UNIX, LINUX). Napjainkban a legelterjedtebb adatbázisok a relációs adatmodell szerint épülnek fel.

7.1. ADATMODELLEZÉS

Az adatmodellezés olyan eljárás, melynek során a valós világ tényeit és összefüggéseit tükrözı adatok lényeges sajátosságait és lényeges összefüggéseit emeljük ki. Eredménye az adatmodell.

Az adatbázisok mindig valamilyen adatmodellen alapulnak.

Az adatmodell elkészítésének elsı lépése, hogy meghatározzuk azokat a dolgokat, objektumokat, amelyeket a modellben le szeretnénk írni. Ezeket a dolgokat egyedeknek nevezzük. Egyedek lehetnek tárgyak, személyek, vagy akár események is. Például Hallgatók, Tantermek, Vizsgák. Az egyedek konkrét elıfordulásai például "Kiss Jolán", "112-es terem", "2007.01.22-i Információs rendszerek vizsga". Egy adott egyed által képviselt összes elıfordulás halmazát egyedhalmaznak nevezzük. Például a Hallgatók nevő egyedhalmaz az összes hallgatóból áll, a Terem nevő egyed-halmaz pedig az összes terembıl.

Az egyedeket tulajdonságokkal, attribútumokkal írjuk le. Az adatmodellezés fontos lépése, hogy az egyed számtalan tulajdonsága közül kiválasszuk azokat, amelyek számunkra lényegesek. Az adatmodellben csak ezek a tulajdonságok szerepelnek. Például egy hallgató tulajdonságai lehetnek a név, születési dátum, szak, évfolyam, testmagasság, szeme színe stb. Ha egy egyetemen hallgatói nyilván-tartást készítenek, úgy ezek közül a név, születési dátum, szak, évfolyam tulajdonságokkal fogják jelle-mezni a hallgatókat, míg egy rendırségi nyilvántartásban a név, születési dátum, testmagasság, szeme színe tulajdonságokat fogják használni.

Amennyiben egy tulajdonság, vagy a tulajdonságok egy csoportja egyértelmően meghatározza, hogy az egyed melyik értékérıl, vagyis az egyedhalmaz melyik elemérıl van szó, akkor ezeket a tulajdonságokat kulcsnak, vagy azonosítónak nevezzük. Elvileg minden egyedhalmaznak van kulcsa, hiszen az egyedeket úgy határoztuk meg, hogy egymástól megkülönböztethetık legyenek. Így legrosszabb esetben az összes tulajdonság együtt alkotja a kulcsot. Ha túl sok tulajdonságot kellene megadni az egyedhalmaz elemeinek egyértelmő azonosításához, akkor célszerő bevezetni egy olyan tulajdonságot - például sorszám, kódszám - amely lehetıvé teszi az egyszerő azonosí-tást. A Hallgatók egyedhalmazban például hallgatókódot rendelhetünk a hallgatókhoz, a terméke-ket pedig cikkszámmal látják el a könnyebb azonosítás végett. A hallgatónak a hallgatókód nem természetes tulajdonsága, épp így a cikkszám sem természetes tulajdonsága a terméknek. Ha a kulcs egyetlen tulajdonság, akkor egyszerő kulcsnak nevezzük, amennyiben több tulajdonság alkotja a kulcsot, akkor összetett kulcsról beszélünk.

A különbözı egyedhalmazok kapcsolatban állhatnak egymással. Például a Hallgatók és a Vizsgák egyedhalmazok közötti kapcsolat lehet az, hogy kik vizsgáznak az adott napon a megadott tárgy-ból.

A kapcsolatoknak három típusát különböztetjük meg.

♦ Egy-egy típusú kapcsolat (1:1 kapcsolat)

Az egyik egyedhalmaz egy eleméhez a másik egyedhalmaz legfeljebb egy eleme kapcsolódik. Például a vidéki önkormányzatok halmaza és a polgármesterek egyedhalmaza között egy-egy típusú kapcsolat van.


83. oldal

30. ábra: 1:1 típusú kapcsolat

♦ Egy-több típusú kapcsolat (1:N kapcsolat)

Az egyik egyedhalmaz egy eleméhez a másik egyedhalmaz több eleme is tartozhat, de a másik egyedhalmaz egy eleméhez az elsı egyedhalmaznak csak egy eleme tartozhat. Például a Raktá-rak és a Dolgozók közötti kapcsolatban egy raktárhoz több dolgozó tartozhat, de egy dolgozó csak egy raktárban dolgozhat.

31. ábra: 1:N típusú kapcsolat

♦ Több-több típusú kapcsolat (N:M kapcsolat)

Az egyik egyedhalmaz egy eleméhez a másik egyedhalmaz több eleme is tartozhat és ez a má-sik egyedhalmazra is igaz. Például az Áruk és a Szállítások közötti kapcsolat több-több típusú kapcsolat, hiszen egy szállítás során többféle árut is vihetnek, de egy áruféleséget több szállí-tással is szállíthatnak.

32. ábra: N:M típusú kapcsolat

Az adatmodell elkészítése során meg kell adnunk az adatokra vonatkozó megszorításokat is, ezek szintén a séma részei lesznek.


84. oldal

A legfontosabb megszorítástípusok:

• Kulcsok: a megszorítások között szokás megadni az egyedhalmazok kulcsát.

• Egyértékőségi megszorítások: megköveteljük, hogy egy egyedhalmazon belül egy adott tulajdonság értéke minden egyednél különbözı legyen. Ennek speciális esetei a kulcsok, de nem azonosí-tó tulajdonságnál is elıfordulhat ilyen megszorítás, például egy hallgató egyedhalmaz kulcsa a hallgatókód, de a személyigazolvány-számnak is minden egyednél egyedinek kell lennie.

• Hivatkozásépség-megszorítások (referenciális integritás): megköveteljük, hogy egy hivatkozott érték szerepeljen az adatbázisban. Például egy hallgató nem vehet fel olyan tantárgyat, amely nem szerepel a tantárgyak egyedhalmazában.

• Értékkészlet-megszorítások: egy tulajdonság értékeit csak egy meghatározott halmazból veheti fel, például az érdemjegy csak 1, 2, 3, 4, 5 lehet.

• Általános megszorítások: tetszıleges követelmények, amelyeket az adatokkal szemben támasz-tunk. Például, egy dátum nem lehet késıbbi az aktuális dátumnál.

Relációs adatmodell

A relációs adatmodell az adatok táblázatos ábrázolásán alapul. Ebben az adatmodellben a reláció egy névvel ellátott táblázat. Egy táblázat sorai egy egyedhalmaz egyedeinek leírását tartalmaz-zák. Az egyedeket tulajdonságaikkal írjuk le, ezek a tulajdonságok alkotják a táblázat oszlopait. Például a Hallgató táblázat egyik oszlopa a név, a másik a születési dátum, stb. Egy adatmodell-ben általában több egyedhalmaz szerepel (hallgató, oktató, tantárgy, terem, vizsga), így több táb-lázatban kell leírni ıket, ezek a táblázatok pedig kapcsolatban állnak egymással.

1.1.4.6. A táblázat struktúrájának leírása

Egy relációs adatbázisban meg kell adnunk minden táblázat struktúrájának leírását. Ennek során rögzíteni kell az egyes oszlopok nevét, típusát és méretét. Egy oszlopban csak a típusának megfe-lelı adat tárolható. A legfontosabb adattípusok:

− számok (numerikus adatok) − szövegek (karakteres adatok) − dátum, vagy idı adatok

Az oszlopok mérete rögzített, nem függ a benne tárolt adat méretétıl. Ha például a Név oszlop méretét 40 karakternek definiáljuk, akkor abban 0-tól 40 karakterig terjedı hosszúságú neveket tárolhatunk, de az oszlop mérete akkor is 40 karakter lesz, ha a leghosszabb név sem éri el ezt. Szintén a struktúraleírásban kell megadni az egyes oszlopokra vonatkozó megszorításokat.

Egy adatbázisban tárolhatók hosszabb összefüggı szövegek is, ezeket feljegyzés, vagy hosszú karakteres típusú mezıkbe lehet felvinni. Ennek az adattípusnak nincs meghatározott mérete. Multimédiás objektumokat – pl. képek, hang-fájlok – szintén elhelyezhetünk egy adattáblában, ezeket vagy hosszú karakteres mezıkben, vagy speciális OLE (Object Linking and Embedding) objektumokat tartalmazó mezıkben, vagy BLOB (Binary Large OBject) - nagymérető bináris objektum - típusú mezıben kell tárolni.

1.1.4.7. Kulcsok

Ahhoz, hogy a táblázatban szereplı egyedeket egyértelmően azonosítani tudjuk, a táblázatnak rendelkeznie kell kulccsal. Az adatmodell elkészítésekor rögzítenünk kell, hogy a lehetséges kul-csok közül melyiket fogjuk a tábla sorainak, vagyis az egyedeknek az azonosítására használni, ezt a kulcsot elsıdleges kulcsnak, vagy primary key-nek nevezzük.


85. oldal

Például a Hallgató táblában lehetséges kulcs a név és a születési dátum együttes megadása, de lehetséges kulcs a hallgató kód is. Az adatmodell készítésekor meg kell adnunk, hogy melyiket fogjuk elsıdleges kulcsként használni.

A táblák közötti kapcsolatot sok esetben az biztosítja, hogy az egyik táblázatban benne szerepel a másik táblázat elsıdleges kulcsa. Ezt a mezıt az elsı táblázatban idegen kulcsnak nevezzük.

Példa:

ANYAG tábla

Cikkszám Megnevezés Mennyiségi

egység Egységár

(Ft)

120306 Lemezcsavar db 5

302564 Facsavar db 4

523652 Alumínium lemez db 1500

212121 Vaspor kg 842

A példánkban a tábla neve ANYAG, a sorai egy-egy anyag leírását tartalmazzák, az anyagokat jellemzı tulajdonságaikkal – cikkszám, megnevezés, mennyiségi egység, egységár – írjuk le, ezek a tábla oszlopai. A tábla elsıdleges kulcsa a cikkszám.

KÉSZLET tábla

Raktárszám Cikkszám Mennyiség

2100 120306 1000

2200 302564 5000

2100 302564 3500

2300 120306 1200

A KÉSZLET tábla elsıdleges kulcsa a raktárszám és a cikkszám (összetett kulcs). Ebben a táblá-ban benne szerepel az ANYAG tábla elsıdleges kulcsa, vagyis a cikkszám. Itt a cikkszám idegen kulcs is, mert egy másik tábla elsıdleges kulcsa. Ez a mezı biztosítja a kapcsolatot a két tábla között, a KÉSZLET tábla adataiból nem tudjuk megmondani, hogy mi a 120306 cikkszámú anyag, és hogy a mennyiség miben értendı, csak az ANYAG tábla segítségével derül ki, hogy ez lemezcsavar és a mennyiségi egység darab. Az idegen kulcs általában nem része az elsıdleges kulcsnak, de – mint példánk mutatja -, az is lehet

1.1.4.8. Normál formák, normalizálási eljárás

Tekintsük a következı példát:

Egy raktári nyilvántartásban a raktárakban található anyagokról a következı adatok szerepelnek:

raktárszám, cikkszám, megnevezés, mennyiség, egységár.

Készítsünk egy Raktár táblát, amelynek oszlopai ezek a tulajdonságok. Az anyag megnevezése és az egységára annyiszor szerepel a táblázatban, ahány raktárban az adott anyag megtalálható. Ha egy anyag egységára megváltozik, ez minden olyan sort érint, amely erre az anyagra vonatkozik. Ha egy anyag kifogy a raktárakból, akkor ennek az anyagnak a megnevezése és egységára sehol sem fog szerepelni a táblában. Ha újra érkezik ebbıl az anyagból valamelyik raktárba, az anyag jellemzıit újra fel kell vinni valahonnan. Ezen problémák kiküszöbölésére célszerő a táblázatban


86. oldal

szereplı tulajdonságok összefüggéseinek elemzése, és a táblázatok átalakítása normál formájú táblázatokká.

Elsı normál forma

Azon relációkat, amelyek ábrázolhatók táblázatos formában és minden cellában csak egyetlen érték (elemi érték) található, elsı normál formájúnak (1NF) nevezzük.

Az elemi érték nem azt jelenti, hogy egyetlen szó, vagy egyetlen szám, hanem azt, hogy elemi tulajdonságérték. Például egy lakcím több részbıl áll (város, utca, házszám), de egyetlen hely meg-jelölésére szolgál, így ez tekinthetı elemi adatnak, a lakcím cellában tehát szerepelhet. Ugyanak-kor, ha valakinek van egy állandó, és egy ideiglenes lakcíme, ezek már nem szerepelhetnek ugyan-abban a cellában.

Függıségek

Ha egy A tulajdonság ismeretében meg lehet határozni a B tulajdonság értékét, akkor a B tulaj-donság függ az A tulajdonságtól.

Például egy felsıoktatási intézmény nevébıl egyértelmően következik az aktuális rektor, vagy fıigazgató neve, tehát az intézmény vezetıjének neve függ az intézménytıl. Ugyanakkor az in-tézmény nevébıl nem következik Kiss Jolán vizsgajegye, hiszen valószínőleg több félévben és több tárgyból is vizsgázott.

Lehet, hogy egyetlen tulajdonság értékének ismeretébıl még nem következik a másik tulajdonság értéke, de több tulajdonság értékének együttes ismeretébıl már igen.

Például egy élelmiszer-áruházban a vásárlásokról a következı adatokat tartják nyilván: a pénztárgép számát, a vásárlás dátumát és idıpontját, valamint a fizetett összeget.

A pénztárgép száma, a vásárlás dátuma és idıpontja együttesen egyértelmően meghatározza a fizetett összeget, azonban a pénztárgép száma önmagában nem határozza meg, hiszen egy pénztárgépen na-gyon sok vásárlást blokkolnak, a dátum és az idıpont sem határozza meg egyértelmően, hogy me-lyik vásárlásról van szó, mert egy adott idıpontban több pénztárgép is blokkolhat. Tehát a vásár-láskor fizetett összeg meghatározásához mindhárom tulajdonságérték ismeretére szükség van.

Egy relációban minden tulajdonság függ az elsıdleges kulcstól, hiszen az elsıdleges kulcs egyér-telmően meghatározza az egyedhalmaz egyedét, így ennek tulajdonságait is.

A B tulajdonság teljesen függ az A tulajdonságcsoporttól, ha az A tulajdonságcsoport minden elemének ismeretére szükség van a B tulajdonság értékének meghatározásához

Elıfordulhat, hogy egy tulajdonság egy harmadik tulajdonságon keresztül határozza meg a másik tulajdonság értékét, Vagyis az A tulajdonságból következik a C tulajdonság, abból pedig a B. Ek-kor a B tulajdonság tranzitíven függ az A tulajdonságtól.

Például:

A dolgozók napi munkadíj-elszámolását egy táblázatban tartjuk nyilván, melynek oszlopai (a tu-lajdonságok):

hónap, dolgozókód, órabér, dolgozott órák száma, fizetés

A kulcs a hónap és a dolgozókód. A fizetés azonban függ az órabértıl és a dolgozott órák számától, vagyis a kulcs meghatározza az órabért és az órák számát, amelyek meghatározzák a fizetést, így ez a reláció tranzitív függést tartalmaz. Nyilvánvaló, hogy fölösleges a táblázatban a fizetést tárolni, hiszen kiszámítható a rendelkezésre álló adatokból.


87. oldal

Második normál forma

Azon relációkat, amelyek elsı normál formában vannak és minden olyan tulajdonság, amely nem elsıdleges kulcs teljesen függ az elsıdleges kulcstól, második normál formájúnak (2NF) nevezzük.

Ez tulajdonképpen azt jelenti, hogy a lehetı legszőkebb tulajdonságcsoportot választottuk kulcs-nak.

Ha egy reláció elsı normál formájú, és minden kulcsa egyszerő kulcs, akkor második normál formájú is, hiszen az egyszerő kulcs egyetlen tulajdonságból áll, ezért itt nem fordulhat elı, hogy valamely tulajdonság csak a kulcs egy részétıl függ.

Harmadik normál forma

Azon relációkat, amelyek második normál formában vannak, és nem tartalmaznak tranzitív füg-gıséget (vagyis minden tulajdonság csak az elsıdleges kulcstól függ), harmadik normál formá-júnak (3NF) nevezzük.

Az adatmodellezés során minden táblázatot harmadik normál formára kell alakítani. A harmadik normál forma biztosítja, hogy a táblázathoz a lehetı legszőkebb kulcsot válasszuk, va-gyis a lehetı legkevesebb tulajdonság legyen a kulcs része, és a táblázat ne tartalmazzon fölösleges belsı függéseket.

Az elsı normál formájú relációk csak egy része teljesíti a második normál forma feltételeit, ezek-nek pedig csak egy része teljesíti a harmadik normál forma feltételeit.

33. ábra: Normál formák

Bebizonyítható, hogy minden reláció elıállítható 3NF relációk összességeként. Egy reláció normalizálását általában további relációkra történı bontással valósíthatjuk meg. Azt az eljárást, amelynek segítségével egy reláció harmadik normál formájú relációkká alakítható, normalizálás-nak nevezzük.

Egy reláció további relációkra történı bontásán azt értjük, hogy a kiinduló táblázat helyett kisebb táblázatokat alakítunk ki úgy, hogy a létrejövı táblázatok együttesen ugyanazt az információtar-talmat hordozzák, mint a kiinduló táblázat.


88. oldal

normalizálatlan forma

1NF

2NF

3NF

táblázatos formára hozás

a kulcs részeitıl való függıségek eltávolítása

a tranzitív függıségek eltávolítása

34. ábra: A normalizálás lépései

Példa egy normalizálási feladatmegoldására

A feladatunk a hallgatók eredményeinek nyilvántartása.

1. lépés

Elsı közelítésben adatainkat a következı táblázatban ábrázolhatjuk:

HALLGATÓ

(HALLGATÓKÓD, SZÜLETÉSI DÁTUM, NÉV, KAR, SZAK, ÉVFOLYAM, TAN-TÁRGYKÓD, TANTÁRGYNÉV, TANTÁRGY KREDITÉRTÉKE, JEGY, TANÁRKÓD, TANÁR NEVE, TANSZÉK NEVE)

Egy sor egy hallgató adatait és az átlagszámításnál figyelembe vett vizsgajegyeit tartalmazza.

A táblázat kulcsa a hallgatókód. A név nem lehet kulcs, mert egy oktatási intézményben elıfor-dulhatnak azonos nevő hallgatók és tanárok, ezért volt szükség a hallgatókód, és a tanárkód beve-zetésére. Két különbözı tanszék is meghirdethet azonos nevő tantárgyat, így célszerőbb a tantár-gyakat is kóddal azonosítani.

Mivel egy hallgató több tantárgyat tanul egy félévben, a táblázatban egy hallgatóhoz több tan-tárgyra vonatkozó tulajdonságérték (tantárgykód, tantárgy neve stb.) tartozhat. Tehát ez a tábla nem normalizált.

2. lépés

Bontsuk két táblázatra a kiinduló táblázatot, az egyikben csak a hallgató adatai szerepeljenek, a másikban pedig a tanulmányi eredmények!

HALLGATÓ-1

(HALLGATÓKÓD, SZÜLETÉSI DÁTUM, NÉV, KAR, SZAK, ÉVFOLYAM)


89. oldal

A tábla kulcsa a hallgatókód.

EREDMÉNY

(HALLGATÓKÓD, TANTÁRGYKÓD, TANTÁRGYNÉV, TANTÁRGY KREDITÉRTÉKE, JEGY, TANÁRKÓD, TANÁR NEVE, TANSZÉK NEVE)

Az így kapott tábla sorait már nem azonosítja egyértelmően a hallgatókód, ezért a hallgatókódot és a tantárgykódot választjuk kulcsnak. Mindkét táblában minden cellába elemi értékek kerülnek, tehát ezek a táblák már elsı normál formában vannak.

3. lépés

Vizsgáljuk meg, hogy a tulajdonságok az összetett kulcs teljes egészétıl függnek-e, vagyis máso-dik normál formában vannak-e a táblázatok!

A HALLGATÓ-1 táblának egyszerő kulcsa van, ezért második normál formájú. Az ERED-MÉNY tábla összetett kulccsal rendelkezik, itt meg kell vizsgálni, hogy minden tulajdonság a kulcs teljes egészétıl függ-e, vagy esetleg valamely tulajdonságot már a kulcs egyik eleme is meg-határozza.

A teljes kulcstól függ a jegy, azonban a tantárgynév, tantárgy kredit-értéke, tanárkód, tanár neve, tanszék neve tulajdonságok csak a tantárgykódtól függnek. Bontsuk további két táblára az EREDMÉNY táblát, az egyik táblába kerüljenek azok a tulajdonságok, amelyek csak a tantárgy-kódtól függnek, a másikba pedig a jegy, amely a kulcs teljes egészétıl függ.

EREDMÉNY-1

(HALLGATÓKÓD, TANTÁRGYKÓD, JEGY)

A tábla kulcsa a hallgatókód és a tantárgykód.

TANTÁRGY

(TANTÁRGYKÓD, TANTÁRGYNÉV, TANTÁRGY KREDITÉRTÉKE, TANÁRKÓD, TANÁR NEVE, TANSZÉK NEVE)

A tábla kulcsa a tantárgykód.

A kapott táblák második normál formában vannak, mert az elsı tábla kulcsa egyszerő kulcs, a második táblában a jegy tulajdonság pedig az összetett kulcs mindkét tagjától függ.

4. lépés

Vizsgáljuk meg, hogy a felbontásokkal kapott három táblánk harmadik normál formában van-e! A HALLGATÓ-1 és az EREDMÉNY-1 tábla harmadik normál formájú, a tulajdonságok csak a kulcstól függnek. A TANTÁRGY tábla azonban nem, mert a tanár neve és a tanszék függ a tanár kódjától, ami pedig nem kulcs.

A TANTÁRGY táblát bontsuk két újabb táblára, úgy, hogy a tanárra vonatkozó adatokat emeljük ki egy másik táblába:

TANTÁRGY-1

(TANTÁRGYKÓD, TANTÁRGYNÉV, TANTÁRGY KREDITÉRTÉKE, TANÁRKÓD)

A kulcs a tantárgykód.

TANÁR

(TANÁRKÓD, TANÁR NEVE, TANSZÉK NEVE)

A tábla kulcsa a tanárkód.


90. oldal

Az így kapott táblák már harmadik normál formában vannak.

A normalizálási eljárás eredményeként a kiinduló táblánkat négy táblára bontottuk:

HALLGATÓ-1

EREDMÉNY-1

TANTÁRGY-1

TANÁR

Most vizsgáljuk meg, milyen elınyök származnak ebbıl a felbontásból, a 3NF táblázatok haszná-latából!

Sokkal kevesebb adat kerül többszörösen tárolásra (minimális redundancia).

A tantárgyakat leíró adatok (név, kredit-érték) csak egyszer kerülnek tárolásra a TANTÁRGY-1 táblában, míg az eredeti táblánk esetén annyiszor tároltuk ıket, ahány hallgató felvette az adott tantárgyat.

Ha módosítani kell egy tantárgy valamely adatát, például a kredit-értéket, elegendı ezt egyetlen helyen elvégezni.

A kiinduló tábla esetén, ha minden olyan hallgatót törlünk a táblából, akik egy adott tantárgyat felvettek, akkor a tantárgy adatai is törlıdnek. Míg a harmadik normál formában levı tábláink esetén a TANTÁRGY-1 táblában benne maradhat az a tantárgy, amelyet abban a félévben nem oktatnak, így a rá vonatkozó adatok nem vesznek el a törlés során.

Rugalmasabb adatfelvitelt biztosít, hiszen ha egy új tantárgyat szeretnénk bevezetni, már akkor is felvihetjük az adatait a TANTÁRGY-1 táblába, amikor még egyetlen hallgató sem vette fel. Ezt a kiinduló tábla esetén nem tehetjük meg.

1.1.4.9. Mőveletek relációkkal

Ugyanazon adatbázis különbözı felhasználóinak az adatok más-más részhalmazára lehet szüksé-gük, ezért egyes felhasználók számára egy táblázatnak bizonyos oszlopait és sorait kell kiemelni, más felhasználók számára pedig a táblázatokat össze kell vonni. A relációs modell egyik nagy elınye, hogy a különbözı igényeknek megfelelı adatelemek matematikailag könnyen és jól defi-niálhatók a relációalgebra segítségével.

Relációalgebra

A relációalgebrai mőveletek relációkon végzett mőveletek, melyek eredménye szintén reláció. A legfontosabb relációalgebrai mőveleteket:

• Projekció, vagy vetítés

Egy táblázatból meghatározott oszlopokat kiemelünk, például a Hallgató táblából a Név, a Szak és az évfolyam oszlopot.

• Szelekció, vagy kiválasztás

Egy táblázatból bizonyos feltételnek megfelelı sorokat emelünk ki, például a Hallgató táblá-ból a 2. éves hallgatók adatait. A feltételek definiálásához a mezıneveket, konstansokat, ösz-szehasonlító operátorokat, logikai mőveleteket (és, vagy, negálás), továbbá a létezik (exists) és a minden (all) kitételeket lehet felhasználni.

Példa:


91. oldal

a) A Hallgató táblából válasszuk ki a 2. éves hallgatók sorait!

A feltétel: Évfolyam=2

b) A Hallgató táblából válasszuk ki azoknak a 2. éves hallgatóknak a sorait, akiknek minden vizsgajegye jeles.

A feltétel: Évfolyam=2 and all vizsgajegy=5

• Egyesítés

Két táblázat sorait egyesítjük egyetlen táblában. Ehhez a két táblázatnak azonos felépítésőnek kell lennie. Az egyesítés során az azonos sorok csak egyszer kerülnek az eredménytáblába, hi-szen egy táblázatban nem lehet két egyforma kulcsú sor.

• Metszet

Két táblázatból a közös sorokat emeljük ki.

• Összekapcsolás

Két táblázat sorait összefőzzük úgy, hogy az eredménytáblában szereplı sorok elsı része az elsı táblából származik, második része pedig a másodikból. Így az eredménytábla mezıinek száma a két tábla mezıszámának összege lesz. Összekapcsolhatjuk az elsı tábla minden sorát a második tábla minden sorával - ekkor az eredménytábla sorainak száma a két tábla sorszá-mának szorzata lesz -, vagy megadhatunk feltételeket, és csak a feltételnek megfelelı sorokat kapcsoljuk össze.

Speciális összekapcsolás a természetes összekapcsolás mővelete, melynek feltétele, hogy a két táblában szerepeljen azonos oszlop. Az összekapcsolás során azokat a sorokat főzzük össze, amelyek az azonos oszlopban azonos értéket tartalmaznak. Ezt a mőveletet használjuk, ami-kor két táblát az idegen kulcs – elsıdleges kulcs páros alapján kapcsoljuk össze.

Példa:

KÉSZLET tábla

Raktárszám Cikkszám Mennyiség

2100 120306 1000

2200 302564 5000

2100 302564 3500

2300 120306 1200

ANYAG tábla

Cikkszám Megnevezés Mennyiségi

egység Egységár

(Ft)

120306 Lemezcsavar db 5

302564 Facsavar db 4

523652 Alumínium lemez db 1500

212121 Vaspor kg 842


92. oldal

A természetes összekapcsolás során a két táblát a Cikkszám mezı segítségével kapcsoljuk össze:

Raktárszám Cikkszám Mennyiség Megnevezés Mennyiségi

egység Egységár

(Ft)

2100 120306 1000 Lemezcsavar db 5

2200 302564 5000 Facsavar db 4

2100 302564 3500 Facsavar db 4

2300 120306 1200 Lemezcsavar db 5

1.1.4.10. A relációs adatbázisok legfontosabb típusai

A legtöbb relációs adatbázis az alábbi két csoport valamelyikébe sorolható:

− dBASE típusú adatbázisok

− SQL alapú adatbázisok

A dBASE típusú adatbázisok egyszerőbb felépítésőek, az adatbáziskezelı rendszerük is kevesebb funkciót lát el, így például az adatvédelmet a felhasználói programokba kell beépíteni. Általában kis adatbázisok kezelésére használják ıket. A legelterjedtebb a dBASE III adatbázistípus.

A relációs adatbáziskezelı rendszerek (Relational Database Management System - RDBMS) dön-tı többsége SQL alapú adatbáziskezelı, vagyis az SQL (Structured Query Language) nyelvet használja az adatok karbantartására, lekérdezésére. SQL alapú az egyik legelterjedtebb relációs adatbáziskezelı rendszer az ORACLE, de ezt használják az IBM adatbáziskezelı szoftverei (DB2, Informix), valamint a SYBASE, a Microsoft SQL szerverei, és a Microsoft Access adatbáziskezelı rendszer motorjaként alkalmazott Microsoft Jet, vagy MSSQL szerver. is. Ezek az adatbáziskezelık általában fejlett adatvédelmi rendszerrel és számos, a felhasználó munkáját segítı, vagy a bonyolult adatrendszerek kezelését lehetıvé tevı funkcióval rendelkeznek.

Vannak olyan dBASE típusú adatbázisok is, amelyek az SQL nyelv segítségével kezelhetık, ilyen például a dBASE IV.

7.2. ADATBÁZISKEZELİ RENDSZEREK TÖBBFELHASZNÁLÓS KÖRNYEZETBEN

A nagyobb adatbázisok általában több felhasználó kiszolgálására jönnek létre. Ebben az esetben biztosítani kell, hogy az adatbázis adataihoz minden felhasználó hozzáférhessen. Ekkor az adat-bázist egy központi gép (szerver) merevlemezein helyezik el, a felhasználók pedig egy lokális há-lózaton keresztül érik el az adatbázisban tárolt adatokat. Az SQL alapú adatbáziskezelı rendsze-rek általában kliens-szerver architektúra szerint felépülı hálózatokon mőködnek, ami azt jelenti, hogy a központi gépen fut maga az adatbáziskezelı rendszer, a kliens gépeken pedig az alkalma-zások. Az alkalmazások SQL parancsokat küldenek a központi gépnek, ott az adatbáziskezelı végrehajtja azokat, és az eredményt visszaküldi a kliensnek. Egy módosítás eredménye például az, hogy a módosítás sikeresen megtörtént, egy lekérdezés eredménye pedig a feltételeknek megfelelı adatok csoportja.


93. oldal

35. ábra: Kliens-szerver architektúra

Alkalmazás szerver (Application server)

Nagy erıforrásigényő alkalmazásoknál célszerő több szintő hálózatot felépíteni. A legfelsı szint az adatbázis-szerver szintje, ennek feladata az adatok kezelése, megosztása, a következı szint az alkalmazás-szerver(ek) szintje. Ezeken a szervereken futnak azok az alkalmazások, amelyek a bonyolult, nagy számításigényes adatfeldolgozásokat megvalósítják, vagyis az alkalmazások prog-ramját osztják meg a kliensek között. A legalsó szinten, a kliensek gépein csak az adatok bevitele, illetve az eredmények megjelenítése történik (front-end alkalmazások). Ez egyrészt erıforrás megtakarítással jár, - mert a kliens oldalon nem követel meg erıs gépeket, - növeli a biztonságot, másrészt gyorsítja az alkalmazások végrehajtását. A klienseknek éppúgy felhasználói névvel és jelszóval kell bejelentkezniük az alkalmazás-szerverre, mint két szintő hálózatnál az adatbázis-szerverre. A felhasználókhoz hozzárendelhetı, hogy mely alkalmazásokat futtathatják. Az adat-bázisszerverre az alkalmazásszerveren futó alkalmazás jelentkezik be, ez a kliens elıl elrejtve tör-ténik. A front-end alkalmazásoktól megkülönböztetendı, a háttérben futó, a felhasználó számára láthatatlan alkalmazásokat szokás back-end alkalmazásoknak nevezni.

36. ábra: Több szintő hálózat adatbázis-szerverrel és alkalmazás-szerverekkel


94. oldal

Osztott adatbázisok

Nagy adatbázisok esetén elıfordulhat, hogy az adatok nem egyetlen számítógép merevlemezein helyezkednek el, hanem fizikailag különálló szervergépeken. Ezek a gépek egy-egy lokális hálózat központi gépei, és egymással is kapcsolatban állnak. Azok az adatbáziskezelı rendszerek, amelyek lehetıvé teszik az osztott adatbázisok kezelését, biztosítják, hogy bármelyik lokális hálózatba kap-csolt felhasználó a fizikailag különbözı gépek merevlemezein tárolt adatokat logikailag egyetlen adatbázisnak lássa.

Az osztott adatbázisok kezelésének egyik legnagyobb problémája a fizikailag különbözı adatbá-zisokban végzett egyidejő, összefüggı módosítások kezelése. Ugyanis elıfordulhat, hogy a módo-sítás sikeresen lezajlik az elsı adatbázisban, azonban hiba történik a második adatbázisbeli módo-sítás esetén. Ekkor az elsı adatbázisba a módosítások belekerültek, míg a másodikba nem. Így az adatok integritása már nem áll fenn. Ezért olyan megoldásra van szükség, amely garantálja, hogy az összefüggı módosítások minden adatbázisban megtörténjenek. Erre szolgál a két fázisú commit (two-phase commit) eljárás. . Az elsı fázisban a commit mővelet nem kerül ténylegesen végrehajtás-ra, csak az elıkészítése történik meg, melynek során az adatbáziskezelı rendszer meggyızıdik arról, hogy nincs akadálya az adatok tényleges módosításának. Ha a tranzakcióban résztvevı minden adatbázisban sikeres volt az elıkészítés, akkor a második fázisban megtörténik a tényle-ges commit végrehajtása. Ha az elıkészítés során valamelyik adatbázis hibát jelez, akkor a máso-dik fázisban a tranzakcióban résztvevı összes adatbázisban megtörténik a tranzakció visszagörge-tése, így az adatok konzisztensek maradnak.

37. ábra: Osztott adatbázis

Internetes adatbázisok

Az Internet használatának széleskörő elterjedésével megjelentek az Interneten keresztül elérhetı adatbázisok, biztosítva azt, hogy egy adatbázishoz a kliensek a világ bármely pontjáról hozzáfér-hessenek. Az adatbázis továbbra is egy központi szerver gépen helyezkedik el, kliens lehet bár-mely olyan számítógép, amely Internet-eléréssel rendelkezik. A kommunikációhoz valamely In-ternetes protokollt használják fel. Az alkalmazások vagy Web-es böngészı program felületén


95. oldal

futtathatók, vagy a JDBC (Java DataBase Connectivity) protokoll segítségével közvetlenül kom-munikálnak az adatbáziskezelı rendszerrel.. Az Internetes adatbázisok megjelenésével lehetıvé vált, hogy az adatbázis és az adatbáziskezelı rendszer nem a felhasználó cég számítógépén, ha-nem egy szolgáltató, vagy az alkalmazást fejlesztı szoftver-ház számítógépén kerüljön elhelyezés-re, ott mőködjön. Így a cég mentesül a nagy értékő hardver-beruházás alól, továbbá nincs szüksé-ge szakembergárdára a számítógépek és az adatbázisok üzemeltetéséhez. Az adatbázisadminisztrációt a szerver tulajdonosa végzi el, a cég felhasználói pedig Interneten ke-resztül futtathatják az alkalmazásokat, így végezhetik az adatok karbantartását, lekérdezését.

7.3. OLTP ÉS OLAP RENDSZEREK

Mőveleti adatbázisok – OLTP rendszerek

Amikor a vállalatok, bankok, kereskedıházak áttértek ügyviteli és termelési adataik számítógépes nyilvántartására, elsıdleges céljuk az volt, hogy a tárolt adatok pontosan tükrözzék az adott cég aktuális állapotát (megrendelések, raktárkészlet, stb.). Az ilyen céllal kialakított adatbázisok úgy-nevezett operatív, vagy mőveleti adatbázisok. A bennük tárolt adatok állandóan változnak, hiszen mindig az aktuális állapotot kell mutatniuk. Az adatbáziskezelı legfontosabb feladata a megbízha-tó tranzakciókezelés, vagyis az adatok felvitelének, karbantartásának biztosítása. Ezért azokat az alkalmazásokat, amelyek az ilyen típusú adatbázisok adatkezelését végzik OLTP (On-Line Tranzaction Processing), On-Line tranzakció-feldolgozó alkalmazásoknak nevezzük.

Döntéstámogató rendszerek – OLAP rendszerek

A mőveleti adatbázisokba óriási mennyiségő információ kerül felvitelre, ezeknek az adatoknak az elemzésével számos következtetést lehetne levonni a cég mőködésével kapcsolatban. Ehhez azonban nemcsak a pillanatnyi állapotot tükrözı adatokra, hanem a múltbeli értékekre is szükség lenne. Az OLTP rendszerek legfontosabb feladata a tranzakciókezelés, ezért nem biztosítanak hatékony megoldást sem az idısorok tárolására, sem ezen adatok feldolgozására. Az információs rendszerek egy viszonylag fiatal ága, a döntéstámogató rendszerek (Decision Support System, DSS) hivatottak arra, hogy a folyamatokat idıben vizsgálják, a múltbeli adatok felhasználásával próbáljanak következtetéseket levonni a jövıre nézve. Ezen rendszerek felhasználói általában a cégek vezetıi. A döntéstámogató rendszerek nagy mennyiségő adattal dolgoznak, melyeket idı-ponttal is el kell látni, hiszen nemcsak az aktuális állapotokat tükrözı adatok, hanem a régebbiek is szerepelnek a rendszerben. Az itt tárolt adatok nem változnak, ezért nincs szükség a karbantar-tásukra, a tárolt adatok köre egyre bıvül, bizonyos idıközönként a mőveleti adatbázisok adatai betöltıdnek a rendszerbe. Természetesen a túl régi adatok, amelyekre már nincs szükség, kitöröl-hetık. A döntéstámogatási rendszerek legfontosabb mővelete a lekérdezés, és az adatok elemzé-se. Azokat a rendszereket, amelyek célja nagymennyiségő adat feldolgozása, OLAP (On-Line Analitical Processing) on-line analitikus elemzı rendszereknek nevezik. Ezekben a rendszerekben a legfontosabb az adatok hatékony, gyors visszakeresése és a különbözı adatelemzési eljárások alkalmazása.

6. táblázat: Az OLTP és az OLAP rendszerek összehasonlítása

OLTP OLAP kisebb adatmennyiség nagy adatmennyiség karbantartás lekérdezés aktuális állapot archívum gyakori rövid ideig tartó tranzakció kevesebb, hosszabb idıt igénylı tranzakció sok konkurens mővelet kevés konkurens mővelet homogén adatforrás heterogén adatforrás


96. oldal

Adattárházak (Data Warehouse)

Az analitikus elemzı rendszerek feladatuk miatt alapvetıen más adatkezelı rendszert igényelnek, mint a tranzakció feldolgozó rendszerek. Erre a célra adattárházakat szoktak kialakítani. Az adat-tárház (data warehouse) egy témaorientált, integrált adatrendszer, amelynek legfıbb feladata az adatok lekérdezésének, elemzésének támogatása. Az adattárházban tárolt adatok mennyisége többnyire terabyte-okban mérhetı. Az adattárházak általában mőveleti adatbázisokon alapulnak, többnyire nem is egy homogén adatforrásból, hanem több, többféle felépítéső adatbázisból kap-ják adataikat. Az adatok betöltés, majd idıszakos frissítések során kerülnek az adattárházba. Ahhoz, hogy a különbözı adatmodellekbıl származó adatokat egyetlen rendszerbe lehessen integrálni, a betöltés és frissítés elıtt az adatokat egységes formátumúvá kell alakítani, és ki kell szőrni a közöt-tük fennálló esetleges ellentmondásokat. Ezt az eljárást adattisztításnak nevezzük. Az adattárhá-zakban gyakorlatilag nincs tranzakciókezelés, így szinkronizációs problémák sem fordulnak elı. Ezzel szemben számtalan, sokszor hosszú futási idejő lekérdezést hajtanak végre. A kliens olda-lon a lekérdezések eredményét további elemzéseknek vetik alá, ezért az itt használatos eszközök többnyire táblázatkezelık, vagy statisztikai programcsomagok. A nagymennyiségő adat elemzésé-re adatbányászati (data mining) programokat használhatnak, melyek sokrétő adatelemzést, statiszti-kák készítését, az adatok közötti összefüggések feltárását teszik lehetıvé. Az adattárház kezelı rendszerének fontos feladata, hogy biztosítsa az adatok bizonyos jellemzık szerinti összegzését felfelé (aggregálás, drill up), illetve az összegzett adatok bontását lefelé (lefúrás, drill down). Az összegzés során például a termelési értékeket megtekinthetjük, napi, havi, negyedéves, vagy akár éves bontásban is, a lefúrás pedig arra szolgál, hogy például, ha az elemzés kimutatja, hogy a cég eladásai csökkentek az elızı évihez képest, részletesebb bontásban vizsgálható, hogy melyik ter-mékkategória esetén, vagy konkrétan mely termékek esetén következett be ez a csökkenés.

38. ábra: Egy adattárház helye az információs rendszerben

Az adattárházak nem aktuális adatokkal dolgoznak, a döntéstámogatási rendszerek általában nem is igénylik a napra pontos adatokat, hiszen például a trendek vizsgálatához teljesen megfelelı, ha az adatok csak az elızı hétig, vagy esetleg csak az elızı hónapig állnak rendelkezésre.

Mivel az adattárházak nagyon sok adatot integrálnak, a lekérdezések megkönnyítése érdekében célszerő lehet tematikus részekre bontani, ezek a részek a data mart-ok, vagy adatpiacok.

Az adattárházak felépítéséhez már nem megfelelı a hagyományos relációs adatmodell, hiszen például nem tudja hatékonyan biztosítani az adatok több szempont szerinti csoportosítását. Ezért helyette a többdimenziós (multidimenzionális) adatmodellt alkalmazzák. Ebben a modellben az adatok tárolási egysége a kocka. A kocka élei a dimenziók, ezek egy-egy tulajdonságnak felelnek


97. oldal

meg, a kocka tartalma pedig a tulajdonságok által meghatározott érték. Például az eladások nyil-vántartására kialakíthatunk egy olyan háromdimenziós modellt, amelyben a dimenziók: a termék, az eladás dátuma és az értékesítési piacok, a cellák tartalma pedig egy adott termékbıl adott na-pon, adott üzletben eladott mennyiség.

Az értékesítési id

ıszakok adatai

Az értékesített termékek fajtái

Az értékesített termékek

mennyiség adatai

39. ábra: Többdimenziós adatmodell

Általában ilyen részletezettséggel nincs szükség az adatokra az elemzések során, ezért a dimenzi-ók mentén az adatok összesíthetık, így például a dátum lehet hónap, vagy negyedév, a termék lehet termék-kategória, az üzlet pedig város, vagy régió szintő. A lekérdezések során fogalmazhat-juk meg, hogy az egyes dimenziók mentén milyen szintő összegzést kérünk. A kockát szeletelhet-jük (slice) is valamely dimenzió mentén, ekkor az adott dimenzió értékét rögzítjük, így a dimenzi-ók számát csökkentjük, mintegy a nagy kockának egy síkmetszetét vizsgáljuk. Fenti példánkban, ha egy adott termék eladási adataira vagyunk kíváncsiak az idı és a piac függvényében, ez már egy kétdimenziós táblázatban is ábrázolható. Egy másik szeletet választunk ki, ha az eladásokat egy adott idıszakban vizsgáljuk, vagy az egy piacon történt eladásokat nézzük. Ha két, vagy több dimenzió értékét rögzítjük egy konkrét értéken, vagy értékhatárok között, akkor az eredeti kocká-ból egy kisebb kockát választunk ki.

40. ábra: Szeletelés


98. oldal

Természetesen nemcsak három dimenziós adatmodell alakítható ki, hanem tetszıleges dimenzió-jú, ezeket azonban már nem lehet ilyen szemléletes módon megjeleníteni.

A többdimenziós adatmodell tárolásához az adattárházak gyakran a csillag sémát használják. Ez a séma egy ténytáblából és dimenziótáblákból áll. A ténytáblában egy sor egy adatkocka leírása. Tartalmazza a kocka koordinátáit, és a kockában elhelyezett értéket, vagy értékeket. A koordiná-tákat úgy tárolják, hogy minden koordináta érték helyett egy mutató található, amelyik a megfelelı dimenziótábla azon sorára mutat, amely ennek a koordinátának a leírását tartalmazza. Például az eladott mennyiségnél a koordináták az idı, a termék és a hely, tehát három mutató szerepel egy sorban, valamint a mennyiség értéke. A dátum mutató a kockához tartozó dátum sorára mutat az idı dimenziótáblájában, a hely mutató az adott üzlet sorára, a termék mutatója pedig az eladott termék sorára a termék dimenziótáblájában.

41. ábra: Csillag séma

Árnyaltabb adatstruktúra a hópehely séma, ugyanis ebben a dimenziókon belüli hierarchiák is megje-leníthetık, így lehetıség nyílik egy-egy dimenzió mentén több szintő összesítés készítésére.


99. oldal

42. ábra: Hópehely séma

7.4. A VÁLLALATI INFORMÁCIÓS RENDSZEREK ÉS AZ ADATBÁZISOK

A vállalati információs rendszerek olyan programcsomagok (szoftverek), amelyek számos alkal-mazást tartalmaznak, amelyek megvalósítják egy vállalat operatív adatainak felvitelét, tárolását, karbantartását, a napi mőködéshez szükséges információk visszakeresést, feldolgozását, támogat-ják a vezetıket stratégiai döntéseik meghozatalában. A szükséges operatív adatok adatbázisokban kerülnek tárolásra, az elemzésekhez felhasználható adatokból pedig adattárházak alakíthatók ki. Ezek az alkalmazások csak az adatbáziskezelı rendszeren, vagy az adattárház kezelı rendszeren keresztül tudnak adatkezelı mőveleteket végezni. Ezért egy információs rendszer fejlesztésénél mindig figyelembe kell venni, hogy milyen típusú adatbáziskezelı rendszer fölött fog mőködni. Az SQL alapú adatbáziskezelıt használó rendszerek általában nem kötıdnek egy konkrét adatbá-zistípushoz, hanem többféle SQL alapú adatbáziskezelı rendszerrel is együtt tudnak mőködni. Maguk az adatbázisfejlesztı szoftver cégek is megjelentek a piacon a saját vállalati információs rendszereikkel, így például az ORACLE cég is, de számos olyan információs rendszert fejlesztı szoftver ház mőködik, amely csak alkalmazásokat készít, ezekhez valamely elterjedt adatbázismo-tort alkalmazzák, ilyen az üzleti szoftverek fejlesztésének piacvezetı cége, az SAP (Systems Applications and Products in Data Processing) is.


100. oldal

43. ábra: Egy összetett vállalati információs rendszer felépítése

101. oldal

8. A VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK KIVÁLASZTÁSA

Ebben a fejezetben azzal kívánjuk megismertetni az olvasót, hogy milyen összetett és ebbıl adó-dóan nehéz feladat a vállalat számára minden szempontból kielégítı vállalatirányítási információs rendszert választani. Emellett egy olyan eszközrendszert mutatunk be, amely segítségével egzakt módon kezelhetı e problémakör.

8.1. A RENDSZERKIVÁLASZTÁS FOLYAMATA

Az alábbiakban bemutatjuk azt az ajánlott forgatókönyvet, amely segítségével körültekintıen jár-hatunk el egy új vállalatirányítási információs rendszer kiválasztásánál:

A.) Állapítsuk meg, hogy szükségünk van-e új rendszerre?

a) A következı kérdéseket válaszoljuk meg:

− Vannak e üzleti és/vagy informatikai problémáink a vállalati mőködés során? − Ha igen, melyek ezek? (Lista jellegő összegzés) − Mibıl adódnak ezen problémák:

− Tisztán ügyviteli problémák. − A jelenlegi informatikai rendszer hiányos, vagy helytelen mőködésébıl adódó

problémák. − A jelenlegi informatikai rendszer ki nem használt funkcionalitásából eredı prob-

lémák. − Ismeretlen okból eredı problémák:

− Igénybe vettük e tisztán ügyviteli probléma esetén külsı vagy belsı ügyviteli tanácsadó segítségét?

− Igénybe vettük e a jelenlegi rendszer szállítójának segítségét?

b) Ha a kérdések megválaszolása után arra jutunk, hogy igen vannak problémáink, akkor ismerjük meg az információ-gazdálkodási tanácsadóktól, vagy rendszerszállítóktól származó vélemé-nyeket arról, hogy az általunk eszkalált problémákra létezik e egy új vállalatirányítási informá-ciós rendszerrel megoldás. Megjegyezzük, hogy gyakran ezen a szinten nem tudnak egyértelmő álláspontra jutni a vállalatok, mivel sokszor nem keresnek fel független tanácsadót a lehetısé-gek feltérképezéséhez, vagy éppen a megkérdezett rendszerszállítók véleményét nem tartják megnyugtatónak a szállítók eladási érdekei miatt.

Ha a válasz pozitív, akkor állapítsuk meg pontosan, hogy milyen típusú rendszerre van szüksé-günk (ERP, CRM, kollaboratív megoldások), ezen belül milyen modulok és milyen szerepkö-rök érintettek.

c) Döntsük el, hogy standard megoldások közül választunk, vagy a jelenlegi rendszer fejlesztésébe fogunk, vagy egy teljesen új rendszert fejlesztetünk szintén egyedileg. Ennek eldöntésekor a következı szempontokat érdemes figyelembe venni:

− Igényeinkre van e már a piacon létezı és referenciával mőködı standard megol-dás?


102. oldal

− Van-e idınk, tudásunk, emberi erıforrásunk és fıleg pénzünk arra, hogy egy fej-lesztı céget megbízzunk egyedi fejlesztéssel?

− Tudjuk-e és/vagy akarjuk e vállalni az egyedi fejlesztés idı, minıség és pénzügyi kockázatát?

A kérdések megválaszolása után ma már legtöbbször a vállalatok a standard megoldások mel-lett döntenek, mivel egyrészt az egyre bıvülı bevezetési tapasztalatok miatt ma már egyedi igényekre is létezik standard megoldás, másrészt azért, mert az egyedi fejlesztés több szempon-tú kockázata igen magas.

B.) Térképezzük fel a lehetıségeinket

− A kiválasztásnál fontos szempont, hogy mekkora cégünk éves nettó árbevétele?

− Képesek és hajlandóak vagyunk-e évente az éves nettó árbevételünk 1-3 %-át az új rend-szerre költeni? (A statisztikák alapján átlagosan ez a ráfordítás eredményez Magyarorszá-gon a vállalatok számára jó minıségő vállalati informatikát.)

− Van e elkülönített költségkeret az új informatikai rendszerre?

− Hogyan tudjuk, kívánjuk finanszírozni az új rendszer bevezetését:

− Egyösszegő ráfordításként − Folyamatos ráfordításként (részletfizetés, vagy havi bérleti díj) − Vegyes finanszírozással

− Mekkora cégünk sajáttıke hozama, azaz alternatív költsége az egyösszegő finanszírozás-nál, illetve havi bérleti díjnál?

− A rendszer kiválasztáshoz szükséges-e külsı információ-gazdálkodási tanácsadó igénybe-vétele?

− Képesek és/vagy hajlandóak vagyunk-e megfizetni az információ-gazdálkodási tanácsadó munkáját?

− Ha belsı erıforrásokkal oldjuk meg a kiválasztási feladatok elvégzését, akkor milyen egyéb, alternatív költség merül fel?

− Optimális-e cégünk szervezeti mőködése egy új informatikai rendszer bevezetéséhez?

− A szervezeti optimalizáláshoz szükséges-e külsı BPR (Business Process Reengineering) - azaz üzleti folyamat újraszabályozó -tanácsadó igénybevétele?

− Képesek és hajlandóak vagyunk e megfizetni a BPR tanácsadó munkáját?

− Ha belsı erıforrásokkal oldjuk meg a BPR feladatok elvégzését, akkor milyen alternatíva költség merül fel?

− Mekkora az IT szakembergárdánk?

− Elegendı-e ezen szakembergárda tudása és állománya az új rendszer üzemeltetési felada-tainak ellátásához:

− Folyamatos alkalmazástámogatás legalább a legfontosabb üzleti területe-ken,

− Az adott adatbázis folyamatos menedzselése, − A hardver, operációs rendszer és hálózat folyamatos üzemeltetése?

− Optimális-e a vállalat munkaerı állománya?

A vállalatirányítási információs rendszerek kiválasztása

103. oldal

− Létezik-e egy hatékony projekt team a kiválasztáshoz?

− A vállalat menedzsmentje képes-e egy meghatározott idın belül és adott információk alapján a döntéshozatalra?

− Léteznek-e olyan meglévı szerzıdések, amelyek befolyásolják a rendszerváltást?

− Gazdálkodásunk periodicitása befolyásolja-e a döntés, a bevezetés és az éles indulás ide-jét?

− Milyen döntési hierarchia és gyakorlat honos a vállalatnál?

− A kívánt éles indulás idıpontja és az addig hátralévı idı?

C.) Készítsük el a pályázati kiírás anyagát

A pályázati kiírás anyagának, a tenderanyagnak kialakítása többféle módon is történhet. Egyik lehetıség, hogy a cég maga készíti el tenderanyagot, a másik, hogy egy tanácsadóra bízza ennek a munkának az elvégzését. Fontos kiemelni, hogy a tenderanyag minısége meghatározza a pályá-zók ajánlatainak használhatóságát, illetve az egész kiválasztási folyamat sikerességét.

A pályázati kiírás anyagának ma már hazánkban is használt elnevezése az RFQ (Request For Quotation). Az RFQ-nak a következıket javasolt tartalmaznia:

− A pályázat tartalmának és céljának ismertetése

− A pályázati eljárás ismertetése:

− A pályázat típusa: zárt (meghívásos), vagy nyílt pályázat. − Zárt pályázatnál a meghívott pályázók megnevezése. − A pályázati anyag kiváltásának idıkorlátja. − A pályázati anyag kiváltásának költsége. − Konzultációs idıpontok megadása. − Konzultációs személyek adatainak megadása. − Leadási határidı. − A leadás módja és helyszíne. − Döntés módja és idıpontja. − Szerzıdéskötés módja és idıpontja.

− A pályázat kiírójának bemutatása. − A pályázat tárgyát képezı funkcionalitás bemutatása.

Javasolt egy részletes igénylista összeállítása, amelyet a különbözı üzleti területek képviselıi állí-tanak össze saját területük igényei alapján. Ezen igényeket összefésülve alakulhat ki egy részletes igénylista, amely vonatkozhat:

− Az alkalmazás alaptulajdonságaira (rugalmasság, egyszerő kezelhetıség stb.) − Az alkalmazás egyes üzleti területeken képviselt funkcionális képességeire − Az alkalmazás jogi, nyelvi megfeleltségére − Az alkalmazás üzletági referenciáira − Az alkalmazás tanúsítványaira


104. oldal

Ezen elvárt tulajdonságok számonkérésére megfelelı eszköz lehet, ha azt kérjük a pályázóktól, hogy az egyes igények mellé jelezzék a következık valamelyikét:

− Alkalmas − Nem alkalmas − Fejlesztendı − Interface segítségével kezelendı

− Az új rendszer felhasználói körének definiálása

− Létszám (a jelenlegi felhasználószámot is megemlítve) − Megoszlás üzleti területekként − Elvárt létszámcsökkentés − Felhasználók képességeinek bemutatása

− A rendelkezésre álló informatikai tárgyi és humán infrastruktúra bemutatása

− Jelenleg használt alkalmazás(ok) fajtája és funkcionalitása − Jelenleg használt interface-k − Az új rendszerhez kapcsolandó rendszerek − Jelenleg használt adatbáziskezelı − Jelenleg használt operációs rendszer − Rendelkezésre álló központi hardver környezet − Rendelkezésre álló WAN − Rendelkezésre álló LAN − Munkaállomások − Jelenlegi informatikai szakembergárda állományának és tudásának bemutatása

− Az elvárt technológiai és emberi erıforrásbeli mőködési környezet specifikálása.

A pályázati anyag formai követelményei:

− Megadott ajánlati struktúra:

− Pályázati azonosító és a pályázat címének megjelölése − Pályázó(k) bemutatása (egyéni, konzorcium, alvállalkozók)

− Cégadatok (telephely, cégvezetı, adószám stb.) − Tulajdonosi szerkezet − Cégtörténet − Alkalmazottak létszáma, összetétele − Tanúsítványok (ISO, szakvizsgák, akkreditációk) − Pénzügyi adatok (mérleg, eredmény-kimutatás, mérleg és cash flow

terv) − Referenciák − Ajánlólevelek


105. oldal

− Az ajánlott termék, szolgáltatás bemutatása

− Alkalmazási megoldások (modul, szerepkör, tranzakció szinten) − Üzleti konstrukció(k)

− Vásárlás − Bérlet − Vegyes konstrukció

− Technológia − Üzemeltetés

− Bevezetési ütemterv, elızetes projektterv − Ügyféllel szembeni elvárások − Szerzıdéses feltételek − Pénzügyi kondíciók − Mellékletek

− Szerkesztési feltételek (terjedelem, betőméret, betőtípus stb.)

8.1.1. A meghívottak körének megállapítása

A meghívottak körének megállapítására alapvetıen a következı lehetıségek kínálkoznak: − Saját meghívás

− Zárt pályázat − Piaci információk alapján − Tanácsadó cég ajánlására

− Nyílt pályázat − A pályázók maguk jelentkeznek

− Kihelyezett meghívás (a meghívást egy tanácsadó cég végzi) − Zárt pályázat

− Tanácsadó cég piaci információi alapján − Más pályázatokban résztvevık

− Nyílt pályázat − A pályázók maguk jelentkeznek

A meghívottak körének megállapítására gyakran alkalmazott eszköz az RFI (Request For Information), amely a potenciális meghívottakról kér olyan adatokat, amelyek alapján a kiíró el-döntheti, hogy az adott vállalatot bevonja e a meghívottak körébe.

A pályázatra meghívottak névsorát legtöbbször közzéteszik a pályázati dokumentációban.

8.1.2. A pályázat meghirdetése

A pályázat meghirdetése zárt pályázat esetén megegyezik a pályázati anyag meghívottakhoz törté-nı eljuttatásával. A pályázati dokumentáció általában tartalmaz egy:

─ Felkérılevelet (a cégvezetı és a projektvezetı ellenjegyzésével) ─ A pályázati anyagot nyomtatott formátumban ─ A pályázati anyagot nyomtatott valamilyen digitális formátumban (floppy, CD, e-mail)

Nyílt pályázat esetén a meghirdetı általa választott médiát alkalmazhat a közzétételre (szak- és közsajtó, rádió, televízió, szakintézmények, tanácsadó cégen keresztül).


106. oldal

8.1.3. Pályázati konzultációk

A pályázati munka egyik igen fontos és érzékeny pontja az ajánlattételi folyamatot segítı konzul-táció. Ezek témája minden esetben a kiírt pályázat tartalmának értelmezése, a felmerült kérdések megválaszolása.

A konzultáció vezetıje általában a kiválasztásért felelıs projektvezetı, aki az érintett szakterüle-tek vezetıinek meginvitálásával áll a pályázók rendelkezésére.

A konzultáción való részvétel lehet szeparált és csoportos, azaz a pályázóknak egyenként és cso-portosan is lehet lehetıséget biztosítani a konzultációra.

A konzultáción szereplı kérdéseket a pályázók legtöbbször a konzultációt megelızı nap 12 órá-jáig kell, hogy eljuttassák a projektvezetıhöz. Ennek oka az, hogy a projektvezetı feladata és fele-lıssége, hogy a feltett kérdések hiánytalanul és egyenlıen megválaszolásra kerüljenek.

A konzultáción elhangzottakról javasolt jegyzıkönyvet készíteni a késıbbi igazolhatóság érdeké-ben.

8.1.4. A beérkezett pályázatok értékelése

A tenderzárás idıpontjáig beérkezett pályázatokat egy többlépcsıs értékelési folyamaton javasolt keresztülvinni.

1. Értékelési szint az ajánlat formai kritériumainak ellenırzése.

2. Értékelési szint a tartalmi elvárások teljesülésének elemzése és egy egzakt összehasonlítási rendszer kialakítása. Ez utóbbinál szolgál jelentıs segítségül a funkciólista azonos ismér-vek alapján történı kitöltése (alkalmas – nem alkalmas – fejlesztendı – interface segítsé-gével kezelendı)

3. Értékelési szint az ajánlat üzleti és pénzügyi kondícióinak összehasonlítása. Ennél az elemzésnél fontos, hogy azonos ajánlati tartalmakat hasonlítsunk össze: vásárlást a vásár-lással, bérlet a bérlettel.

Ahogyan azt fent megismerhettük, a vásárolt és a bérelt konstrukció összehasonlítását a következık figyelembevéte-lével tehetjük meg:

− Adott idıhorizont kiválasztása (javasolt a 4 év) − A bevezetéshez kapcsolódó elemek költsége = a 4 éves összköltség 40%-val − Az üzemeltetéshez kapcsolódó elemek költsége = a 4 éves összköltség 60%-val − Mindig jelenértéken vizsgáljuk az elemeket − Határozzuk meg az üzletágunkra vonatkozó kalkulatív kamatlábat − Törekedjünk mindig az eszközértékek meghatározására és azok összehasonlítására

Egy példa alapján vizsgáljuk meg az összehasonlítás lehetıségét:

Két informatikai rendszerre vonatkozó ajánlat közül kell választanunk. Az egyik szállító egy egyösszegő vásárlási konstrukciót ajánl, amely tartalmazza a szoftver licenszek, implementáció és a hardver elemek költségét. Ezen elemek megvásárlásának ára 50 millió Ft.

A másik szállító ugyanerre a rendszerre egy bérleti (ASP) konstrukciót kínál, amely 4 éves határozott futamidejő szer-zıdés mellett az összes szükséges rendszerelemet biztosítja. A szolgáltatás havi bérleti díja 2 millió Ft.

Az összehasonlításhoz azt a megoldást választjuk, hogy az ASP konstrukció költségét transzformáljuk egy a másik konstrukcióval összehasonlítható eszközértékre:

Az ASP konstrukció 4 éves nominális összköltsége 2 millió * 48 = 96 millió Ft. (Ha a döntésünket e szám ismereté-ben hoznánk meg – 50 millió vs. 96 millió Ft – akkor biztos, hogy racionális döntésnek a vásárlás konstrukciója tőn-ne.)


107. oldal

A 96 millió Ft két részre osztható:

─ A bevezetési elemekre ─ Üzemeltetési elemekre

A bevezetési elemeket ebben a modellben 4 évre szétosztva fizetjük ki, így ezen összegnek a mai idıpontra számított jelenértékét kell kiszámolnunk. Az üzemeltetési elemek idıértékével nem kell foglalkoznunk, mivel ezek mind a vá-sárlásos, mind az ASP modellben folyamatosan merülnek fel, így idıértéküket azonosnak tekinthetjük.

A 96 millió Ft felosztásához a korábban bemutatott felmérési eredmény szolgálhat segítségül: 40 % bevezetési költsé-gek, 60 % üzemeltetési költségek. A megfelelı összegek tehát:

─ 38,4 millió Ft bevezetés ─ 57,6 millió Ft üzemeltetés

A 38,4 millió Ft-t a vásárlás, azaz a ma idıértékére kell diszkontálnunk. A diszkontáláshoz állapítsunk meg egy évi 12 %-os kalkulatív kamatlábat. Mivel az ASP konstrukcióban a havidíjat folyamatosan fizetjük, így a diszkontáláskor nem használhatjuk az egyszerő 4 éves futamidejő diszkontálást, hanem e helyett úgy kell eljárnunk, mintha a futamidı felére vonatkozna a tıkésítésünk. (Ha meggondoljuk, a ma befektetett pénzünket 2 évig kamatoztatva ugyanannyi kamatbevételhez jutunk, mintha a pénzünket 4 évre befektetve havonta 1/48 összeget szabadítanánk fel a befektetés-bıl.) Tehát a 2 évre vonatkoztatott diszkonttényezı (1 + 0,12)2 = 1,2544.

A kapott 38,4 millió Ft mai idıpontra diszkontált jelenértéke tehát 38,4 millió / 1,2544 = 30,61 millió Ft.

Az összehasonlítás tehát azt az eredményt hozta, hogy az 50 millió Ft-os eszközértékő ajánlattal szemben az ASP konstrukcióban egy 30,61 millió Ft-os eszközértéket állapíthatunk meg. Racionális döntésünk tehát az ASP konstruk-ció választása.

Ugyanerre az eredményre jutunk, ha egy másik megközelítést választunk, miszerint a vásárlás eszközértékét transz-formáljuk a 4 éves összköltségre: 50 millió Ft * 2,5 = 125 millió Ft. Ebben az esetben a pénz idıértékével nem kell foglalkoznunk, mivel ahogy már fent is említettük, az üzemeltetéshez kapcsolódó elemek felmerülése mindkét mo-dellben folyamatosan történik. Ez esetben is megállapíthatjuk, hogy a racionális döntés az ASP konstrukció választá-sa.

4. Értékelési szint az ajánlatokhoz csatolt szerzıdéses feltételek elemzése.

8.1.5. Eredményhirdetés

Az eredményhirdetés történhet nyilvánosan, az ajánlattevı pályázók közös meghívásával, vagy szeparáltan, az egyes pályázók egyéni kiértesítése útján. A meghozott döntés hátterében lévı ér-vekrıl javasolt tájékoztatni minden pályázót. Az eredményhirdetés lehet több lépcsıs, gyakran alkalmazott technika, amikor a beérkezett ajánlatok közül a legjobb két-három ajánlat és ajánlat-tevı egy ún. „short list”-re kerül, azaz bejut abba a körbe, ahol már csak a legjobb pályázók mérik össze erejüket. A short list-re került pályázókat legtöbbször egy második körös prezentációra és/vagy egy újbóli ajánlat megtételére kérik fel, amely lehetıséget adhat a kiírónak a pályázók kompetenciáinak mélyebb megismerésére, illetve esetlegesen kedvezıbb kondíciók elérésére.

A végleges eredményhirdetés természetesen relatív fogalom e tárgykörben, mivel elıfordulhat, hogy a legnagyobb gondossággal kiválasztott szállítóval sem tud a kiíró megnyugtató szerzıdést kötni. Ennek oka legtöbbször az, hogy az ajánlati fázisban kevesebb figyelem fordul a szerzıdé-ses kondíciók tisztázására, valamint az is gyakran elıfordul, hogy a magát már „befutónak” tartó kiválasztott szállító kíván erısebb feltételeket szabni egy kompromisszumokkal tarkított kiválasz-tási folyamat után.

109. oldal

Felhasznált irodalom:

1. Alvincz J.: Az élelmiszeripari vállalatok mőködési feltételei az átalakulás évében. In: Változások az élelmiszeripari és kereskedelmi vállalatok világában Budapest, AKII, 1997/4. szám, p. 21-25., 27-34.

2. Anthony R. N.: Menedzsment kontroll The Harvard Business School Press Boston, Massachusetts, BKE Vezetési és szervezési tanszék fordításában Budapest, BKE házinyomda, 1993. p. 450.

3. Baracskai Z.: A menedzsmentben is az ember dönt Budapest, Budapesti Közgazdaságtudományi Egyetem, 1993. p. 51.

4. Barakonyi K. - Lorange, P.: Stratégia és Management Budapest, Közgazdasági és Jogi Könyvkiadó, 1993. p. 9., 44., 291.

5. Bebchuk, L. A.: Efficient and Inefficient Sales of Corporate Control London, National B. of Economic Research Working Paper, 1994. July. p. 41.

6. Biel A.: Motiváció és controlling. In: Controller Magazin, 1992/2. 35. szám 7. Bordáné Dr. Rabóczki M.: A vezetıi teljesítmények értékelése In: Számvitel és Könyvvizsgálat,

1993/7. szám, p. 270-273. 8. Bordáné Dr. Rabóczki M.: Controlling és a belsı elszámolási és beszámolási rendszerek. In:

Számvitel és Könyvvizsgálat, 1993/8. szám, p. 325-330. 9. Buzás Gy.: A gazdasági kockázat kezelése, biztosítás. In: Mezıgazdasági üzemtan I. Szerk:

Buzás Gy. Budapest, Mezıgazdasági Kiadó 2000. p. 434.

10. Csikós I. - Juhász T. - Kertész T.: Operatív Controlling III. In: Pénzügyi Controlling. Novorg, 1997. p. 128.

11. Csillag I.: A gabonavertikum mőködése, növekedési tendenciái és a változás irányai Budapest, AKII, 1998/1. szám, p. 13-14., 31-33., 41-43.

12. Dobák M.: Szervezeti formák és vezetés. Budapest, Közgazdasági és Jogi Könyvkiadó, 1996. p. 246.

13. Dobay P.: Vállalati információmenedzsment, Budapest, Nemzeti tankönyvkiadó Rt, 1997. p. 33-36., 37-44., 51., 60-66.

14. Dorogi I. - Rott N.: Korszerő beruházás elıkészítési módszerek az élelmiszergazdaságban Budapest, Mezıgazdasági Kiadó, l981. p. 38-50.

15. Dr. Halassy Béla [1982]: Az információs rendszerek alapfogalmai. Számítástechnika-alkalmazási Vállalat, Budapest.

16. Drótos Gy.: Információs rendszer és a menedzsment Budapesti Közgazdaságtudományi Egyetem tanszéki segédlet, 1994. p. 46.-47., 66., 81-85.

17. Drótos Gy.: Számítógép alapú információs rendszerek a menedzsment területén. Nemzetközi elmélet-hazai gyakorlat, Doktori disszertáció Budapest Közgazdaságtudományi Egyetem, 1991. p. 121-123.

18. Erıs J.: A számvitel szerepe a vezetıi információs rendszer. Számvitel és könyvvizsgálat, 1993/12. szám, p. 586-590.

19. Farkas F. - Karoliny M.-né - Poór J.: Személyzeti/emberi erıforrás menedzsment Budapest, Közgazdasági Kiadó, 1997. p. 28.

20. Fekete G.: Irányítani tudni kell! In: Business Online, 1999. május 4-6. szám, p. 33. 21. Gábor A.: Számítógépes információ-rendszerek

Budapest, BKE – Aula Kiadó, kézirat, 1993. p. 21-23., 38.


110. oldal

22. Haklak László - Nagy József [1975]: Információrendszerek tervezése és szervezése. Közgazdasági és Jogi Könyvkiadó, Budapest.

23. Hegyi I. - Szőcs P.: Az európai üzleti asszisztens kézikönyve Budapest, Közgazdasági és Jogi könyvkiadó, 1994. p. 121., 140.

24. Hetyei J.: Vállalatirányítási információs rendszerek Magyarországon Budapest, ComputerBooks Kiadó Kft, 1999. p. 25-29., 33-35., 39-40.

25. Horváth P. et al.: Controlling, út egy hatékony controlling-rendszerhez Budapest, Közgazdasági Jogi Könyvkiadó, 1997. p. 212.

26. Horváth T. - Mészáros Á.: Controlling és vezetıi információs rendszerek - túl a mítoszokon. In: Vezetéstudomány, XXVIII évf. 3. szám, 1997. p. 10., 14-16.

27. Jenei T.: Korszerő vállalati struktúra - divízionális szervezet. In: Számvitel és Könyvvizsgálat, 1995/2. szám, p. 63-67.

28. Kacsukné B. L. – Kiss T.: Bevezetés az üzleti informatikába Budapest, Akadémiai Kiadó, 1999. p. 110., 148-151., 182 .

29. Kovács Á.: Mezıgazdasági vállalatok beruházási, befektetési döntéseit megalapozó számítógépes modell kialakítása Egyetemi doktori értekezés. Gödöllıi Agrártudományi Egyetem, 1990. p. 65.

30. Kovács Á: Vállalati menedzsment információs rendszer fejlesztése a gabonaiparban. Doktori (Ph.D.) értekezés, Szent István Egyetem, 2000 május, 130 p.

31. Körmendi L.- Tóth A.: Controlling a hazai szervezetek gazdálkodási gyakorlatában WEKA Szakkiadó, 2. kiadás, Budapest, 1998. p. 19-20.

32. Kroenke, D.: Managemettt Information Systems London, McGraw Hill. Inc., 1992. p. 222., 437.

33. Ladó L.: A controllingrendszerek hazánkban. In: Számvitel és Ügyviteltechnika, 1990a/6. p. 209-211.

34. Ladó L.: A vezetıi döntéshozatal és a számvitel néhány jellegzetes kapcsolódási területei. In: Számvitel és Könyvvizsgálat, Budapest 1992/3. szám, p. 121-128.

35. N. Petrovics [1977]: Az információról mindenkinek. Mőszaki Könyvkiadó, Budapest. 36. Niedermayr, R.: Controller und Controlling - A vezetık szerepe a kontrolling tevékenység

sikerességében, In: Controller Magazin 1995/6. szám, 1996/8. p. 198-210. 37. Noszkay E.: A vállalkozási informatika és a menedzsment. In: Ipargazdaság, 1994/4. szám,

p. 20. 38. Noszkay Erzsébet [1994]: A vállalkozási informatika és a menedzsment. Ipargazdaság 4.

szám 39. Parker C. – Watsonville T. C.: Management Information Systems, Strategy and Action

USA, McGraw-Hill Inc., 1993. p. 119., 59., 389. 40. Robert A. Szymanski - Donald P. Szymanski - Norma A. Morris - Donna M. Pulschen

[1988]: Inroduction to Computers and Information Systems. Merrill Publishing Company, USA.

41. Samuelson A.: Közgazdaságtan Budapest, Közgazdasági és Jogi Könyvkiadó, l988, p. 280.

42. SAP Software Product Briefing, 2005. p. 15-180. 43. Süle Zs.: Vállalati integrált adatfeldolgozó rendszer kiválasztás tudásbázisú szakértıi

rendszerrel Budapest Közgazdasági Egyetem szakdolgozat, 1995. p. 55-56., 74.

44. Székely Cs.: Stratégia és tervezés In: Mezıgazdasági üzemtan I. Szerk: Buzás Gy. Budapest, Mezıgazdasági Kiadó, 2000. p. 237-258.

111. oldal

45. Szintai I. - Eszes L. - Darabos A.: Tendenciák a korszerő vállalati információs rendszerek területén. In: Vezetéstudomány, 1993/3-4, 1993. p. 33.

46. Ullman,J.D. – Widom, J.: Adatbázisrendszerek – Alapvetés, Panem Kft., 1998 47. Világbanki Kézikönyv

International Bank for Reconsrtuctions and Development (IBRD), Budapest, Magyar Kereskedelmi Kamara, l986. p. 33.

48. Weetman, P.: A vezetıi számvitel alapjai Pénzügyi és Számviteli Fıiskola, 1997. p. 283.

49. Witt, F. - Witt, K.: Controlling kis és középvállalkozások számára Budapest, Springer Hungarica Kiadó Kft, 1994. p. 112., 268.

Copyright

113. oldal

Figyelmeztetés!

Ezen dokumentum jogvédett szellemi termék és a szerzık szellemi tulajdona. Csak azon szemé-lyek, illetve társaságok használhatják fel, amelyek számára a tulajdonosok ezt engedélyezték! Tilos az anyag bármely részének bárminemő sokszorosítása, felhasználása vagy közzététele a tulajdono-sok elızetes írásbeli engedélye nélkül!

A tantárgy folyamatos fejlesztése miatt jegyzet csak a 2008. tavaszi félévben érvényes!

Documents

Adatbáziskezelés és Vállalatirányítási Információs Rendszerek