ADATBÁZISKEZELÉS ÉS VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK

SZENT ISTVÁN EGYETEM Gazdaság- és Társadalomtudományi Kar Közgazdaságtudomány Jogi és Módszertani Intézet Gödöllő

ADATBÁZISKEZELÉS ÉS VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK EGYETEMI JEGYZET

Készítette: Dr. Kovács Árpád Endre Klárné Barta Éva Molnár Attila Szalay Zsigmond Gábor

Gödöllő

2015.

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 iii. oldal

Tartalomjegyzék

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!

iv. 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 igenis 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ágban vitathatatlan. A nagyobb vállalatoknál már nemcsak a vezetőknek, hanem valamennyi munkatá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 magasabb szinten születik egy döntés, annál összetettebb. Más-más problémakört takar egy-egy beruhá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özelí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. A jegyzet a gödöllői Szent István Egyetem - Vállaltgazdasági és Szervezési Intézetének oktatástámogató rendszerén (http://vgszi.szie.hu) található tananyagokkal együtt olyan ismeretanyagokat tartalmaz, amelyek nem nélkülözhetőek a korszerű információgazdálkodást folytató vállalatok vezetői számára.

5. 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 jutott. 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, kapacitá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űjtjü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 embereket 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. Szymanski - 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ésben 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ó tartamát alapvetően befolyásolja az a körülmény, hogy ki a vevője. (Noszkay [1994].) Egy hírrendszer tervezésekor tudnunk kell, hogy egyik vagy másik információt a vevők teljesen másként értelmezhetik. 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, jelrendszeré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 7. oldal

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

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ározzá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áltozhat. 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énynyel szokták jellemezni: C  k ln n ,

ahol n a jelhalmaz elemeinek a száma és k egy arányossági tényező. Az m pozíciót (cellát) tartalmazó 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 C ( m)  mC  mk ln n .

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éldául ha n = 27 és m = 50, akkor (mivel ln 27 = 3,2959):

C (50)  50  3,3k  165k . A csatornakapacitás egységének a bináris csatorna fajlagos kapacitását (n = 2) alapul véve k ln 2  1 .

Ebből

k

1 1   1,4428 . ln 2 0,6931

Így általában egy csatorna fajlagos információkapacitása C  ln n / ln 2 .

És mivel

ln n / ln 2  log 2 n , C  log 2 n .

8. oldal

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

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

C  k ln 27  log 2 27  4,76 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ábbiakban fejezhető ki:

1 C  log 2 n (bit/sec, bit/mm, stb.). t

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, hiszen a közlemények hossza nem került korlátozásra. Így akár egy jelből álló közlemények is öszszeá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özlemé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. Ebben az esetben a továbbított információ tartalma, azaz mennyisége (fej vagy írás; 0 vagy 1) azonosnak 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 hasonló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 , n / 2 , n / 22 ,…, n / 2H  1. Ebből következően n  2H

és

H  log 2 n .

Tehát n jelet tartalmazó készletből előállított közlemény egy jelének információhányada megegyezik 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: 9. oldal


p  p1

p1m

 p2

p2m

,

ahol p1  p2  1 és p1 , p2  0 . Innen a ténylegesen előfordulható, különböző közlemények M száma:

M

1 . p

Í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ással nyert információmennyiséget (egy közlemény információhányadát) kell meghatározni, ami

H (m)  log 2 M . A közlemény egy-egy jelére eső információhányad pedig (bit/jel):

H

1 1 1 log 2 M   log 2 p   (mp1 log 2 p1  mp2 log 2 p2 )  ( p1 log 2 p1  p2 log 2 p2 ) . m m m

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

H  H ( m) / m   pi log 2 pi bit/jel. i 1

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 átlagos 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 hordozott 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ényrendszer kimenetele, annál tartalmasabb információra van szükség ahhoz, hogy ismereteket lehessen 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özlemé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özlemé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 hordozó közlemény. Minden információszerzésnek az a célja, hogy a beérkező közlemények információtartalmának megismerésével csökkentsük valamely eseményrendszer kimenetelének bizonytalanságát. 10. oldal


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

0  H  log 2 n . 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ű ismé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:

R  1  H / H max 

CH . C

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

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:

N m  M , illetve N m  nm . Legyen az értelmes információk mennyisége I(m), ami – a fentiekhez hasonlóan – az Nm logaritmikusaként definiálható:

I ( m)  log 2 Nm  m log 2 n  C ( m) . A jelcsoport egyes jeleire jutó értelmes információhányad: I C.

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

N m  nu , 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:

u log 2 n  C  log 2 n . m 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 ehhez tartozó kódolási rendszert optimális kódnak nevezik. Ez többnyire változó hosszúságú jelsorozatokkal tehető meg a legjobb hatásfokkal. Ekkor a sűrűn előforduló, nem váratlan eseménye11. 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ítsé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 utolsó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 felhasználódnak az információk, hanem keletkeznek is. Ezzel növelik az egymásrautaltságot, és hatékonyabb 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ásoljá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 operatí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ítmé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, amelyet 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 ehhez 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.

12. 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 helyzetet 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 jelentéseket. Eseti jelentést leginkább középvezetők kérnek akkor, ha valamelyik mutató vagy adat szélsőségesen 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 vonatkozhatnak 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őrejelző 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 tulajdonosokkal és az ügyfelekkel kapcsolatos adatokat feldolgozza, segítse az egyes szereplők közötti ügyletek 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ó!

13. 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 megfelelnie:        

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ő szerkezetben 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. Egyré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 fogadja 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.

14. oldal


Befogadók halm ozott hányada

Befogadók hányada

0,5

1

0,4

0,8

0,3

0,6

0,2

0,4

0,1

0,2

A

C

B

E

D

0

0

0

2

4

6

8

10

12

14

Idő

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

0

2

4

6

8

10

12

14

Idő

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 kalandosságnak. Szívesen próbálnak ki új dolgokat, még akkor is, ha egy bizonyos kockázat is társul ezekhez. 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ítanak 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áltozá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 sorolni, 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állalati 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 alkalmaznak, 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.

15. 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ó haszná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ástó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 állnak rendelkezésre. A döntéshozó változókra gyakorolható hatása alapján megkülönböztetünk 16. 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ásolható. 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örnyezeti 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álva – 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 alternatívát választaná, mely esetében a környezet biztos változásának hatására a legnagyobb eredmé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 lehessen emelni. A példában egy kukorica termesztő gazdának kell arról döntenie, hogy mekkora tenyé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 csapadé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 állapotok 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 érté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önté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 a1el 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ékosabb é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örnyezeti 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ó 17. 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éggel 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üntetett 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 összefüggések még szorosabbak lennének, de mindenesetre jobbak, mint ha az áprilisi időjárások minden é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 aposteriori valószínűségeknek is nevezünk, hogy egyértelműen megkülönböztessük az uj környezeti á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 u j állapot akkor következik be, ha egy zk állapot már bekövetkezett:

p(u jz k ) 

18. oldal

p( u j  z k ) p( z k )

(1)


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)

1

ADATOK: Szemes kukorica ára (Ák) [Ft/kg]:

22,00

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

ADATMÁTRIX a kukorica különböző érési fázisainak /korai (a1), középko2 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

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

EREDMÉNYMÁTRIX 6 a (feltételes) a-posteriori p(uj/zk)=[p(uj…zk)]/p(zk)

Cselekvési alternatívák (ai) környezeti állapot

4

valószínűségekhez

(zk)

(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

kezdeti INFO

biztos INFO

jobb INFO

EREDMÉNYMÁTRIX:

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

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

u1

***

66,50

71,25

(ai)

u2

***

76,00

76,83

(zk)

a1

a2

a3

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 évvel megadásra került, az egyesített valószínűség a (2)-es egyenlet alapján nagyon egyszerűen meghatározható.

19. oldal


p( u j  z k ) 

u j  zk E

(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:

p( z k ) 

z k E

(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: p(u jz k ) 

u j  zk z k

(4)

A feltételes valószínűségi értékeket a táblázat 6-os blokkja tartalmazza. Például a p(u1z1) érték a következőképpen számítható ki: p(u1z1)=(5/50)/(12/50)=5/12=0,4167. A feltételes valószínűségek p(ujzk) 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 alternatí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(ujzk) 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(u1z1)+e21  p(u2z1)+e31  p(u3z1) (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

(a i , z k )   e ji  p(u jz k ) i 1

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átrixot 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 haszná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 20. 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 volumené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 szorosabb 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ő folyamatokat. (KUHLMANN 1990, 41. old.). A gyakoribb és átfogóbb ellenőrzések, a sűrűbb szabá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 keletkeznek. Ezt az összefüggést a 3. ábra szemlélteti.

Anyagráfordítás

Hibaköltség

80

80

B2

60

70

40

60

20

50

0

Op

40

30

-20

B1 20

-40

B1

10

-60

-80

B2

0 0

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

Idő

3. ábra: Vállalati eszközráfordítás az idő és a szabályozásintenzitás függvényében

0

10

20

30

40

50

60

70

80

90 100 110 120 130 140 150 160

Idő

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

Az 3. ábránál kiinduló pontnak kell tekinteni, hogy egy időtáv alatt a termeléshez létezik egy bizonyos optimális anyagráfordítás, például a cukorrépa-ráfordítás a cukorgyártásban. Ezt az optimá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ó cukortartalmá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 21. 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ásintenzitá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.

Hibaköltség 100 90 80 70 60 50 40 30 20 10 0 0

20

40

60

80

100

120

Idő

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 folyamatellenőrzésből, és ezáltal, a zavarkompenzációs szabályozás elvének értelmében javítja a szabályozott 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 maximá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 integrá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 kontrollintenzitást a szabályozás összköltségének minimumából közvetlenül leolvashatjuk. Ebből a határnyereségek is levezethetőek, melyek akkor keletkeznek, ha egy korábban nem optimális szabályozá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 hibakö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, 22. 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írni. Az optimális szabályozásintenzitás Op1-ről Op2-re változik. Másrészről, ha a szabályozás összkö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. Nyereség

Hibaköltség

120

120

100

100

80

80

60

60

40

40

20

20

0

0 0

20

40

60

80

100

120

140

160

180

200

0

20

40

60

80

100

Idő

120

140

160

180

200

Idő

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ályozá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éppen 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. Egyré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, nominálisan mind magasabb nyereségveszteségek tekintetében. Ezért a szabályozásintenzitások szerepe a jövőben fokozatosan tovább fog növekedni. Hibaköltség

Hibaköltség

200

100

180

90

160

80

140

70

120

60

SK DK

100

50 SK3 SK1

80

40

60

30 SK2

40

20

20

10

Op1

Op2

Op3

HK

Op

0

0 0

20

40

60

80

100

120

140

Idő

8. ábra: Az optimális szabályozásintenzitás meghatározása

0

20

40

60

80

100

120

140

Idő

9. ábra: Optimális szabályozásintenzitás a szabályozási költségnemek változó értéke mellett

23. 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ásgazdasá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 jelené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öztetett 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 élettartama 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ámszerű é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 pusztá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ézsé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.

24. 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öltségelemei tartoznak, melyek bizonylattal nem határozhatóak meg. Ezek egy része az adott rendszerhez 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ásokat. 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 bevezetésével.

Számvitel által meghatározható: - hardver - szoftver

Saját ráfordítások

Analitika által nem meghatározható: - lekötés - átállás

- szolgáltatás

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égsem lehet eltekinteni, hiszen az egyes megoldások, alkalmazások összehasonlíthatóságához elkerü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 tulajdonlá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 egyszerű eszközbeszerzésektől kezdődően az integrált vállalatirányítási rendszereken keresztül megjelenhet 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.

25. oldal


IT fejlesztés:

Üzleti folyamatok fejlesztése:

HATÉKONYSÁG

HATÁSOSSÁG

Termék és szolgáltatásfejlesztés: INNOVÁCIÓ

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 elemeinek cseréje, bővítése, korszerűbb megoldások beszerzése. Ezek a fejlesztési elemek természetesen 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 informatikát érintő auditok lefolytatása, szabályzatok készítése. Ezen fejlesztések az információs technoló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ásossá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 megjelení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ékelé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 fejleszté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.

26. oldal


Jelentős különbség az eddigi elemzésekhez képest, hogy a gazdaságossági vizsgálatok során a bevétel oldal alakulását is figyelembe kell venni, eljárásokat kell kialakítani számszerű értékük megközelítésére. TCO DIREKT KTG. Beruházási ktg.  szoftver  hardver  szolgáltatás

Működési ktg.  karabantartás  bérleti díjak előfizetések  személyi jellegű

INDIREKT KGT.  szolgáltatás leállás  végfelhasználói informatikai 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 puha 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égedettsé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 adnak 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é.

Kemény

Puha

ROI

ROI

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 27. oldal


a jelen, így minden pénzösszeg jelenértéke kerül kiszámításra. A diszkontálást a kalkulatív kamatlábbal végezhető el, melynek értékét befolyásolja az előbb említett fix hozamú befektetés kamatlába, de nem azonos vele, ezt más számos tényezők és a döntéshozó egyéni preferenciái is befolyá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 öszszehasonlí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égelemeken 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 megegyezik 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 keresztü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állalatokat, hiszen anyagi megfontolások nem késztetik a dolgozókat arra, hogy csak a ténylegesen szüksé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észetesen a főnöke előtt. Kellemetlen helyzet ez, hiszen a mennyiségi gyarapodás könnyen vezet a minőség, az értelmezhetőség rovására. Herbert Simon Nobel-díjas közgazdász tette az alábbi kijelentést: „az információgazdagság figyelemszegénységet szül.” A probléma tehát már nem az informá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.

28. 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íradá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 tartoznak, 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 fogyasztó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 menynyiben 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ökkent 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áltatónk erre a termékre kizárólag átállás esetén ad 50 % árengedményt, teheti ezt mert a nála jelentkező költségek 60 Ft-ba kerülnek. Ebben az esetben a szállítónak 10 Ft-ba került az az árengedmé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.

29. 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 helyzetbe 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 ösztö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 integrá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 egyszeri 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 30. oldal


próbálkozást az eladó, hogy remek ajánlatokkal rávegye a vevőt az egyes területek idő előtti fejleszté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ábbfejleszté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 jellemző ez a jelenség: a nagysebességű nyomtatók és másolók, a távközlési berendezések, a gépkocsik, 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 tartozó 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á tartozó 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 lekö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ű szabvá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üggőségi helyzet kerülhet a vevő. A termékek megvásárlása és a későbbi megrendelések között szoros ö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 vevőt, mind az eladót érintik ezek a tételek. Meglehetősen komoly döntések közé tartozik egy vállalat é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é.

31. 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 Tartós beszerzések Márkaspecifikus ismeretek Adatok és adatbázisok Szakosodott szállítók Keresési költségek

32. oldal

Átállási költségek Beszerzés költsége, avulással csökken. Az új rendszer megtanulása, közvetlen költségek és termelékenységromlás egyaránt jellemző; az idővel emelkedik. Az adatok átvitele új formátumba; az adatmennyiség növekedése miatt az idővel általában emelkedik. Az új megtalálása; az idővel emelkedhet, ha nehéz kapacitásokat találni vagy megtartani. A szállító és a vevő összesített költségei; magukban foglalják az alternatívák minőségének tanulmányozását.

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, milyen tudományterületről is beszélünk, akkor sok rokon értelműnek tűnő fogalommal találkozhatunk, ú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ástechnika é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állalati 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üksé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 kialakí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 jelentősen különbözik a hagyományos rendszerektől. Ez a definíció tehát a számítógépes technoló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őállításában támogatja. Így a különböző célú információs rendszerek közül azok tartoznak ebbe 33. oldal


a kategóriába, amelyek a vezetés irányítási tevékenységét a szükséges információk alaprendszerekbő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 feldolgozza, í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árható. 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önté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 szakirodalomban 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 hozni 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 foglalja 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 34. oldal

Információ-gazdálkodás

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, megrendelé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, videokonferencia 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 menedzsert,  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őkre 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, 35. 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ókkal 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 kommuniká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. ~ 1950

TPS MIS

~ 1960

OAS ~ 1970

DSS ~ 1980

ES

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

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 figyelembe vételével. Az információs rendszerek csoportosítása után következtetésként megállapítható, hogy a menedzsment 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 informá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.

36. oldal

Információ-gazdálkodás

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 stratégiai szintű döntésekhez.

Főleg stratégiai szintű döntésekhez.

Döntési képesség

Strukturált döntésekhez.

Főleg félig strukturált problé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ódosítható formátumban, a döntéshozó igényei szerint.

A felhasználó igényei szerint változtatható formátumú jelentések periódikusan és igény szerint, valamint ad hoc lekérdezések.

Problématerület

Általános, gyakran előforduló problémákhoz nyújt segítséget, személytől függetlenül.

Egyedi problémák megoldá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 segí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ó információk

Múltra, jelenre, jövőre egyaránt vonatkozó információk

Múltra, jelenre, jövőre egyaránt vonatkozó információk.

Modellezési képesség

Nincsenek modellezési képességei.

Fejlett modellezési képességekkel rendelkezik.

Limitált modellezési képességekkel rendelkezik.

Felhasználói interfész

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

Felhasználóbarát, de bizonyos 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 rendszereknek 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. 37. oldal


38. 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égben 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 beszerző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ó termé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 gyakorlatot 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 vehető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 rendszerkialakí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 paramé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 39. 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árfelhajtá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éteznek 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 megoldásoknál megvalósulhat a 80% körüli előkonfiguráltság is. Az előkonfiguráltság előnyeit leginká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állalat 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őrekonfigurá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 algoritmusok 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 algoritmus-rendszer alapján összeválogatja és szintén egy előre definiált rend alapján elkészíti a nyomtatható 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őállításához szükséges anyagok raktárra vétele, stb.

40. oldal

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

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 TERÜ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.

41. 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, miszerint: 4. táblázat: A vállalatirányítási területek felosztása Vállalati működési terület Alapvető ügyvitel, backoffice Ügyfélkapcsolatok, frontoffice Vállalatközi, illetve szervezetközi együttműködés, collaboration

Vállalatirányítási terület Vállalati erőforrás tervezés (Enterprise Resource Planning, ERP) Ügyfélkapcsolat menedzsment (Customer Relationship Management, CRM) Kollaboratív megoldások (Collaborating solutions)

Az ERP rendszerek tehát az alapvető ügyviteli működési folyamatokat támogatják. Ezek a folyamatok 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.) Kollaboratív megoldás ERP/CRM 1.

A z ERP/ C RM 1. ált al felh aszn ált adat (in put)

ERP/CRM 2.

A z ERP/ C RM 2. ált al 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ítsé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 egye42. 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 szerepel. 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 gyakorlatban legsűrűbben használt kollaboratív megoldásokat: ─ Elektronikus adatcsere rendszerek (Electronic Data Interchange, EDI): az ERP és CRM adatok, tranzakció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 összekapcsolása a vevőkkel az interneten keresztül. Megvalósulásai között megtalálhatóak a végfelhaszná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 ecommerce 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ághoz 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 összekapcsolá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ározás, termelés. ─ Iparági megoldások üzleti konnektorja: olyan speciális iparági, jellemzően műszaki alkalmazásoknak a konnektálásáról van szó, amelyek a vállalat ERP, vagy CRM rendszeréhez szolgáltatnak 43. 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ámogatott gyártás), CAPP (Computer Aided Process Planning, Számítógéppel támogatott folyamat-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érvként. Természetesen minden vállalatirányítási információs rendszer szállító más és más terminológiát használ a rendszer moduljainak elnevezéséhez. Mi azt a modellt mutatjuk be, amely a leginkább elterjedt a mai gyakorlatban. A vállalatok működése ERP szempontból alapvetően négy területre osztható: logisztikai folyamatok, pénzügyi folyamatok, emberi erőforrás gazdálkodási folyamatok és projektgazdálkodási folyamatok. 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épességeit. A modulok gyakran használt analógiával a vállalat szervezeti egységeinek, osztályainak, csoportjainak 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 44. 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 felismerve 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 alkalmazá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 rendszerterminoló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önhatá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:

45. oldal

Üzleti folyamat térképBelső vállalati struktúra Kollaboratív

Online értékesítés Web Information Center B2B konnektorok Mobil megoldások

CRM

ERP

Marketing Értékesítés

Pénzü gy

Szolgáltatá sok Call center

Beszerz és

Számvit el

Eszköz Kontrollin gazdálk g odás

Készlet gazdálko Terme dás lés

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

Értékes ítés

HR

Projekt gazdálko dás


Piaci struktúra Tulajdonos Vállalatunk

Vevő

Szállító

Versenytárs

17. ábra: Paci struktúra 47. 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üksé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 eszkö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 értjü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 informá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 kapcsolódó rendszerelemeket a vállalat megvásárolja, és saját költségén üzemelteti, vállalva ezzel a vásárlás és üzemeltetés technikai, üzleti és pénzügyi kockázatát. A vásárlás általában egyösszegű ráfordí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 fennmaradó 60 %-ot a bevezetett rendszer üzemeltetésére fordítják. Ez az arány igen fontos megálla49. 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,5szerese 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 bevált erőforrás kihelyezésre épül. Ennek keretében egy az adott feladattípusra specializált szolgáltató nagyobb szakértelemmel, koncentráltabb kapacitásokkal és ezekből következő relevánsan magasabb 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 bizonyí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 modell 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áltató 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 adatkommunikációs kapcsolattal csatlakoznak a vállalat helyi hálózatához, így a felhasználók munkaállomásaihoz.

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ó. 50. oldal

Az igénybevétel formái

5.3.2. Alkalmazásszolgáltatás - ASP Az alkalmazásszolgáltatás (Application Service Provision, ASP) a hosting szolgáltatáson túlmutató 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 telephelyei 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 megoldá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 modell 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, megteremtve 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: 51. 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állalatok 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 szereplő 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):

52. oldal

Az igénybevétel formái

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

Outsourcing modell 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ó

Szolgáltató

ÜZEMELTETÉS



Alkalmazástámogatás

Vállalat

Vállalat



Alkalmazás verzióváltás

Vállalat

Vállalat

Szolgáltató



Alkalmazáshoz kapcsolódó üzleti 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ó

53. oldal

6. VÁLLALTIRÁNYÍTÁSI MODULOK Jelen fejezetben a Magyarországon legelterjedtebb rendszer példája alapján (SAP) részletesen bemutatjuk 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” funkcionalitá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 biztosí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 informá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 alkalmazható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 üzletfelekkel lebonyolított adatcsere (vevő, szállító, bank, biztosítás, hitelinformáció) is nagyrészt elektronikus ú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 öszszeglista, 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 üzle55. oldal


ti/ügyviteli szint párhuzamos felügyeletét. Az FI-rendszeren keresztül a vállalat kontrollingterü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 összekapcsolá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énznem-értékelés, átcsoportosítások, a követelések és kötelezettségek csoportosítása a maradványfutamidő 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.

56. oldal

Vállaltirányítási modulok

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. kemé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érlegké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 egyedileg 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 automatikusan 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, likviditástervezés és fedezetszámítás rendszere így folyamatosan aktuális és egyeztetett információkhoz 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 integrá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ékesség-előrejelzés és kockázati elemzések (idegen pénznemek).

57. 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 eszkö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ékelé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 „figyelemremé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érlegsorá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.

58. 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 alapjá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áslistákon és az eszköztükörben. A standard mozgásnemek mellett saját mozgásnemek is definiálható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ámlahozzárendelést az eszköz-osztályban kell lerögzíteni. Ezekben az osztályokban értékelési területenké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ő üzleti 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 kezeljenek. 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. 59. oldal


Szabadon definiálható érvényességi feltételekkel a gazdasági események könyvelésénél a standard ellenő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égrehajtani. A sztornírozás Minden olyan eszközmozgást, amelyhez előáll egy könyvelési bizonylat, javítás esetén az FI rendszerben, 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ámogatja a felhasználót, hogy integrált könyvelést végez a kapcsolódó alkalmazásokkal, automatikusan 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 dokumentá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ésbő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ügyi könyvelés vonatkozó számláit költségnemenként vagy árbevétel-fajtánként a kontrolling is 60. oldal


ö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ó komponensek 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öltsé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 újratervezé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, amelyért érdemes a vállalatnak a készletét értékesítenie. Szimulálható, hogy a termelési eljárásban bekö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árhuzamosan statisztikailag vezetik. 61. 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örté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 alapjá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ételfigyelé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, melyek egyszerűen kiegészíthetők cégspecifikus beszámolókká. A beszámoló megjelenítéséből tová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ő.

62. 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észletvezetést, a pontos anyagszükséglet-tervezést, az átgondolt raktárgazdálkodást, a gondos számlaellenő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övekedésekről.

Áttekintés Alapadatok

SD

 Vevõk

Értékes.tervezés

Vevõi rendelések kezelése

 Szállítók

Vevõi igény

 Anyag  Darabjegyzék CAD/KI  Mûveletterv, karbantartási terv, vizsg. terv, CAP  Munkahely  Gyártási segédeszköz

PP

Programtervezés Szükségl. tervezés Nagyvonalú kapacitás tervezés

 Nagyvonalú tervezési terv  Berendezés

Tervrendelések

 Dokumentum

Megnyitási horizont

 Osztályozás  MUNKAFOLYAMATOK SZERVEZÉSE  Szövegfeldolgozás  LEVELEZÉS  Kommunikáció  TELEFAX, EDI, ...  Termékkalkuláció

Rendelés: - megnyitás - engedélyezés - visszajelentés Gyártás-irányítás Kapacitás kiegyenlítés

CAM

Projektsystem

Eredménytervezés SOP Terv-szükséglet Prognózisok

QM

 Hálóterv  Projektek

 Vizsgálandó sorozat nagyság  Vizsg.rendelés

MM Közvetlen igénylés Beszerzés Készletvezetés Árubeérkezés Kiértékelés

Raktárgazdálkodás

Számlaellenõrzés

PM

 Helyreállítás  TMK

SD

 Kiszállítás, számlázás, transzport

23. ábra: Az MM modul integrációjának áttekintése 63. 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 szolgá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. ABCanalí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

64. oldal


eszközkönyvelés (AM), és a költségszámítás (CO) felé. A logisztika-számlaellenőrzésnél az anyaggazdá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élkülözhetetlen támogatást kapnak: a termelést bonyolító rendszer szervezéséhez, a termelőfolyamat 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.

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.

65. 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ő funkció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üksé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észtermé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 kapacitá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 öszszeveti. A kapacitáskiegyenlítés a munkahelyek kapacitásainak kihasználatlanságát vagy azok túlterhelé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 kapcsoló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)

66. 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 (funkcionalitá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ő.

67. 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érhető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 érintett 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 szemé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 hozzá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 megrendelés-visszaigazolást automatikusan kapják levélben, faxon vagy az EDI-n keresztül. Az ügyfelekhez 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 árstruktúrák is egyszerűen definiálhatóak a rendszerben.

68. oldal

Vállaltirányítási modulok Értékesítési támogatás

Törzsadatok

Vevõkapcsolatok Levelezés

Ügyfél

Vevõi anyag információ Osztályozás Szövegek Feltételek

Eladás

Értékesítési információrendszer

Anyag Darabjegyzék Értékesítési csoportok Választék

MM PP

Ajánlatkérés Ajánlatok Rendelésfeldolgozás

Anyaggazdálkodás Termeléstervezés

CO FI

Controlling Pénzügyi számvitel

PS

Projekt-rendszer

MM

Készletnyilvántartás

MM

Raktári nyilvántartás

Kiszállítás Komissiózás Csomagolás Szállítás

Számlázás Egyedi számla Gyûjtõszámla Számlajegyzék Megerhelés / jóváírás

Értékesítési adók Statisztikák

FI

Vevõfolyószámlakönyvelés

CO

Eredményszámítá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 folyamatok 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 MM

Árajánlatkérés

Szállító kiválasztása

PP

Megrendelés

Árubeérkezés

Rendelés

QM

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

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

- 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 69. 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ántarthatja 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. 70. 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 mindenkori követelményeket. A bérszámfejtés általános nemzetközi funkcionalitása lehetőséget biztosít a bruttó bér országfüggetlen meghatározására, az időadatok adminisztrációjának figyelembevé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öltsé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ályagondozási tervvel − Képesítés szerinti lekérdezés lehetősége − Az oktatás költségeinek nyilvántartása

71. 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ótervezésen át a projektbeszámolóig minden részterületet. Ezzel segíti a döntés-előkészítést és optimalizá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

72. oldal


A PS modul igen részletes, több dimenzióban megvalósítható, pontos tervezhetőséget, tényadatkezelé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) összehasonlíthatóvá válnak. A projektütemezés, kapacitás, és a határidők monitorozásával az azokra vonatkozó 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 öszsze az MS-Excel és az MS-Project programokkal. Az elektronikus adatcserét biztosító EDI lehető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 tartalmá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 szabott é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. 73. 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. standalone 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ékonyan 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ükrö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égrehajtását, ill. sikerességük ellenőrzését. A modul segítségével könnyebben exportálhatók ill. importálható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ármelyik csatornán is a vevői rendelés, a rendszer megállapítja az adott esetben érvényes szabályokat, 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

74. 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ékenysé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 kampá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 riportok 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 mindennapi é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ánlatok, megrendelések, szerződések mintáit. Workbench Alacsony bevezetési költségek (TCO) a gyors implementálásnak köszönhetően. 75. oldal


A Mobile Sales paraméterezésére szolgáló eszköz, a vállalat igényei szerinti beállítások létrehozá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ótalkatré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 huszonné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) nevezik. Ebből a modulból (képernyőről) általában elérhető valamennyi olyan funkcionalitás, amelyre 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. 76. oldal


77. 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árolták és visszakeresték, hanem különböző alkalmazások segítségével feldolgozták, elemezték azokat. 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ő eszközök kidolgozását igényelték, így alakultak ki a ma széleskörűen használt adatbáziskezelő rendszerek, 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 szerkezet 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 adatbá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 értjü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 felhaszná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. 79. 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 egyszerre 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 felhaszná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 általa módosított rekordot, ezzel felülírja az első felhasználó módosítását. Ezért nem lehet megengedni, 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 tartalma 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 akadályozza meg az egyidejű módosítást, hanem a rekord visszaírásakor ellenőrzi, hogy az adathordozón levő rekord kódmezője megegyezik-e a visszaírandó rekord kódmezőjével. Ha igen, az azt

80. oldal

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

jelenti, hogy a kiolvasás óta nem módosult a rekord, így engedélyezi a visszaírást, ha nem, a rekordot ú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 adatkarbantartá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 meglé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 összefü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 felhaszná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 adatbázisnak csak azon részét látja, amelyikre a munkájához szüksége van. Mivel az adatbázisok bonyolult belső szerkezet szerint épülnek fel, operációsrendszer szintről többnyire nem értelmezhető az adatbázis-állományok adattartalma, tehát azok a felhasználók, akik nem jogosultak az adatbázisba történő belépésre, operációs rendszer szintről sem tudnak hozzáférni az adatbázis adataihoz. 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ásolatot 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ányba 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 gyakorlatilag 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éldá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élyre, vagy személyek egy csoportjára, aki az adatbázis működéséért felelős. Ő az adatbázisadminisztrá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 feldolgozni, 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 sebes81. 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ű egyedhalmaz 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ántartást készítenek, úgy ezek közül a név, születési dátum, szak, évfolyam tulajdonságokkal fogják jellemezni 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ékeket 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árgybó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.

82. 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.

83. 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ámasztunk. 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 tartalmazzá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 adatmodellben általában több egyedhalmaz szerepel (hallgató, oktató, tantárgy, terem, vizsga), így több táblá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 megfelelő 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 kulcsok 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. 84. 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 85. 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 megjelölésére szolgál, így ez tekinthető elemi adatnak, a lakcím cellában tehát szerepelhet. Ugyanakkor, ha valakinek van egy állandó, és egy ideiglenes lakcíme, ezek már nem szerepelhetnek ugyanabban 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 tulajdonsá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 inté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 nagyon sok vásárlást blokkolnak, a dátum és az időpont sem határozza meg egyértelműen, hogy melyik 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árlá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értelmű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. Ekkor 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 tulajdonsá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.

86. oldal

Adatbázisok és adattárházak – az információs rendszerek adatkezelői 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 kulcsnak. 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üggő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, vagyis 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, ezeknek 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ásnak 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ótartalmat hordozzák, mint a kiinduló táblázat.

87. oldal


n o r m alizálatlan f o r m a táb lázato s f o r m ár a h o zás 1 NF a k u lcs r és zeitő l v aló f ü g g ő s ég ek eltáv o lítása 2 NF a tr an zitív f ü g g ő s ég ek eltáv o lítása 3 NF

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, TANTÁ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őfordulhatnak azonos nevű hallgatók és tanárok, ezért volt szükség a hallgatókód, és a tanárkód bevezetésére. Két különböző tanszék is meghirdethet azonos nevű tantárgyat, így célszerűbb a tantárgyakat 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 tantá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)

88. 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ásodik 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 EREDMÉ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 meghatá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árgykó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.

89. 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 definiá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, öszszehasonlí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:

90. 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, hiszen 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, amikor 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 91. 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öntő 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 adatbá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ő rendszerek á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 alkalmazá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.

92. 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 programjá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ázisszerverre. A felhasználókhoz hozzárendelhető, hogy mely alkalmazásokat futtathatják. Az adatbázisszerverre az alkalmazásszerveren futó alkalmazás jelentkezik be, ez a kliens elől elrejtve törté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

93. 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 kapcsolt 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ódosítás sikeresen lezajlik az első adatbázisban, azonban hiba történik a második adatbázisbeli módosí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ásra, 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ényleges commit végrehajtása. Ha az előkészítés során valamelyik adatbázis hibát jelez, akkor a második fázisban a tranzakcióban résztvevő összes adatbázisban megtörténik a tranzakció visszagörgeté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érhessenek. Az adatbázis továbbra is egy központi szerver gépen helyezkedik el, kliens lehet bármely olyan számítógép, amely Internet-eléréssel rendelkezik. A kommunikációhoz valamely Internetes protokollt használják fel. Az alkalmazások vagy Web-es böngésző program felületén 94. oldal


futtathatók, vagy a JDBC (Java DataBase Connectivity) protokoll segítségével közvetlenül kommuniká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, hanem egy szolgáltató, vagy az alkalmazást fejlesztő szoftver-ház számítógépén kerüljön elhelyezésre, 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 keresztü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 úgynevezett 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ízható 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 karbantartá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ölhető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 kisebb adatmennyiség karbantartás aktuális állapot gyakori rövid ideig tartó tranzakció sok konkurens művelet homogén adatforrás

OLAP nagy adatmennyiség lekérdezés archívum kevesebb, hosszabb időt igénylő tranzakció kevés konkurens művelet heterogén adatforrás

95. 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 adattá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 kapjá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öttü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 oldalon 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, statisztiká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 termé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 96. oldal


meg, a kocka tartalma pedig a tulajdonságok által meghatározott érték. Például az eladások nyilvá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 napon, adott üzletben eladott mennyiség.

Az értékesítési időszakok adatai

Az értékesített termékek mennyiség adatai

Az értékesített termékek fajtái

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 fogalmazhatjuk meg, hogy az egyes dimenziók mentén milyen szintű összegzést kérünk. A kockát szeletelhetjü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 97. 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 megjeleníthetők, így lehetőség nyílik egy-egy dimenzió mentén több szintű összesítés készítésére.

98. 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 alkalmazá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ámogatjá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ázismotort alkalmazzák, ilyen az üzleti szoftverek fejlesztésének piacvezető cége, az SAP (Systems Applications and Products in Data Processing) is.

99. oldal


43. ábra: Egy összetett vállalati információs rendszer felépítése

100. 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árhatunk 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ő problé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 megoldás?

101. oldal


− Van-e időnk, tudásunk, emberi erőforrásunk és főleg pénzünk arra, hogy egy fejlesztő 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 mellett 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 szempontú 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 rendszerre 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ásná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énybevé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 feladatainak ellátásához:

− Folyamatos alkalmazástámogatás legalább a legfontosabb üzleti területeken,

− 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? 102. oldal

A vállalatirányítási információs rendszerek kiválasztása

− 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 idejé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

103. 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

104. oldal

A vállalatirányítási információs rendszerek kiválasztása

− 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ó eldö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). 105. 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ő konzultá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ületek 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 csoportosan 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 felelő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érvek 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árlá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ételé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ű szerző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űnne.)

106. oldal

A vállalatirányítási információs rendszerek kiválasztása 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ésbő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 konstrukció 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 transzformá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 modellben 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ő érvekrő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ánlattevő 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álasztási folyamat után.

107. 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ástechnikaalkalmazá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. 109. oldal


22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44.

Haklak László - Nagy József [1975]: Információrendszerek tervezése és szervezése. Közgazdasági és Jogi Könyvkiadó, Budapest. 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. 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. Horváth P. et al.: Controlling, út egy hatékony controlling-rendszerhez Budapest, Közgazdasági Jogi Könyvkiadó, 1997. p. 212. 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. 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. Kacsukné B. L. – Kiss T.: Bevezetés az üzleti informatikába Budapest, Akadémiai Kiadó, 1999. p. 110., 148-151., 182 . 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. 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. 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. Kroenke, D.: Managemettt Information Systems London, McGraw Hill. Inc., 1992. p. 222., 437. Ladó L.: A controllingrendszerek hazánkban. In: Számvitel és Ügyviteltechnika, 1990a/6. p. 209-211. 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. N. Petrovics [1977]: Az információról mindenkinek. Műszaki Könyvkiadó, Budapest. 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. Noszkay E.: A vállalkozási informatika és a menedzsment. In: Ipargazdaság, 1994/4. szám, p. 20. Noszkay Erzsébet [1994]: A vállalkozási informatika és a menedzsment. Ipargazdaság 4. szám Parker C. – Watsonville T. C.: Management Information Systems, Strategy and Action USA, McGraw-Hill Inc., 1993. p. 119., 59., 389. Robert A. Szymanski - Donald P. Szymanski - Norma A. Morris - Donna M. Pulschen [1988]: Inroduction to Computers and Information Systems. Merrill Publishing Company, USA. Samuelson A.: Közgazdaságtan Budapest, Közgazdasági és Jogi Könyvkiadó, l988, p. 280. SAP Software Product Briefing, 2005. p. 15-180. 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. 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.

110. oldal

45. 46. 47. 48. 49.

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. Ullman,J.D. – Widom, J.: Adatbázisrendszerek – Alapvetés, Panem Kft., 1998 Világbanki Kézikönyv International Bank for Reconsrtuctions and Development (IBRD), Budapest, Magyar Kereskedelmi Kamara, l986. p. 33. Weetman, P.: A vezetői számvitel alapjai Pénzügyi és Számviteli Főiskola, 1997. p. 283. Witt, F. - Witt, K.: Controlling kis és középvállalkozások számára Budapest, Springer Hungarica Kiadó Kft, 1994. p. 112., 268.

111. oldal

Copyright

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 tulajdonosok előzetes írásbeli engedélye nélkül!

113. oldal

ADATBÁZISKEZELÉS ÉS VÁLLALATIRÁNYÍTÁSI INFORMÁCIÓS RENDSZEREK

Recommend Documents