Budapesti Műszaki- és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Elektronikai Technológia Tanszék
Értékesítési elemzés OLAP kockával Önálló laboratóriumi beszámoló
Készítette: Konzulens:
Szabó Péter Pálfi Attila
Dátum: Tárgykód:
2011.05.05. VIETA386
Tartalomjegyzék Tartalomjegyzék ......................................................................................................................... 2 Bevezetés .................................................................................................................................... 3 1. A feladat bemutatása .......................................................................................................... 3 1.1. A feladat szoftver specifikus bemutatása ..................................................................... 4 2. A feladat által érintett ismeretanyag ................................................................................... 4 2.1. Árképzési gyakorlatok ................................................................................................. 5 2.1.1. Személyre szabott árképzés .................................................................................. 6 2.1.2. Nem lineáris árképzés ........................................................................................... 8 2.2. Adattárházak ................................................................................................................ 8 2.3. Az OLAP kocka ......................................................................................................... 10 2.4. Microsoft Dynamics NAV funkcionális áttekintése .................................................. 11 2.5. Árképzés Microsoft Dynamics NAV környezetben .................................................. 12 3. Az önálló laboratóriumi feladat megvalósítása ................................................................ 13 3.1. A fejlesztőkörnyezet kialakítása ................................................................................ 14 3.2. A Microsoft Dynamics NAV adatstruktúrájának megismerése................................. 14 3.3. Az adattárház struktúrájának kialakítása ................................................................... 15 3.4. Ismerkedés a Business Intelligence Development Studio-val ................................... 18 3.5. Az ETL folyamat elkészítése ..................................................................................... 18 3.5.1. A dimenziótáblák feltöltése ................................................................................ 19 3.5.2. A ténytábla feltöltése .......................................................................................... 21 3.6. Az OLAP kocka felépítése......................................................................................... 24 3.6.1. Dimenziók definiálása ........................................................................................ 24 3.6.2. Kocka építése ...................................................................................................... 25 3.7. Adatbázis kezelő cseréje ............................................................................................ 25 3.8. Ár kialakítása Excel 2010-ben ................................................................................... 26 3.9. Egyéni ár, akciós ár meghatározása ........................................................................... 27 4. Az elkészített implementáció üzleti jelentősége ............................................................... 30 5. Irodalomjegyzék ............................................................................................................... 32 6. Táblázatjegyzék ................................................................................................................ 32 7. Képletjegyzék ................................................................................................................... 32 8. Ábrajegyzék ...................................................................................................................... 32
2
Bevezetés A feladatom egy értékesítési elemző rendszer kidolgozása volt. A kész rendszer használatát nem tartom egy olyan kaliberű feladatnak, amit a vállalat IT dolgozójának kellene elvégeznie, sokkal inkább a marketinges(ek)nek. Ezért a feladat megoldása során végig az vezérelt, hogy úgy alakítsam ki a környezetet, hogy az minél jobban elfedje a részleteket és ne mutasson zavaróan sok adatot egy szakmán kívülinek. Az egyes modulok vezérlése grafikus felületről néhány kattintással elvégezhető az adatok áttöltésétől kezdve a kocka felépítésén át az elemzésig. Az elemzésből kinyert adatokat is inkább Visual Basic (VB) Script-tel átalakítottam egy könnyen átlátható Excel munkafüzetbe, hogy ott az árakat meghatározó marketing szakembernek minél kevesebb felesleges adat vonja el a figyelmét a feladatáról. Majd miután végzett munkájával, megint pár kattintással le tud futtatni egy adatbázis folyamatot annak részletes ismerete nélkül, ezzel létrejönnek az új árlisták a vállalatirányítási rendszerben. Továbbá célom volt még, hogy az elkészített komponensek kellően általánosak legyenek ahhoz, hogy módosításuk egyszerű legyen, és a részfeladatok különüljenek el minél jobban, hogy azokat akár egymástól függetlenül is lehessen cserélni.
1. A feladat bemutatása Az önálló laboratóriumi feladatom egy fiktív vállalat, a Cronus Rt. értékesítési elemzése OLAP (On-Line Analitical Process) használatával. A munkámban eladó által irányított piacot fogok bemutatni, így az alkalmazott árképzési stratégia is ennek megfelelően kerül kiválasztásra. Az eladó által irányított piacon az alábbi peremfeltételeket kell elfogadnunk: az eladó tökételesen tisztában van az általa kínált áru értékével, minőségével, a többi piaci szereplő helyzetével, a vevők közti információáramlás tökéletlen, azok csak a keresleti árrugalmasságukon keresztül, vásárlási hajlandóságukkal tudják befolyásolni a kereslet/kínálat alakulását. Az eladók a vevők közti tökéleten információáramlást kihasználva kerülnek olyan pozícióba, hogy ők tudják kialakítani az árakat. (A modellezett piaci körülményekről részletesen a 2.1.-es fejezetben lesz szó.) A feladatot Microsoft technológiák felhasználásával oldottam meg. Az értékesítési elemzés során a következő problémákkal kerültem szembe: 1. Ki kellett alakítanom egy a vállalatirányítási rendszert támogató virtuális környezetet, melyben a feladatom el tudtam végezni. Ehhez fel kellett kutatni a megfelelő szoftvereket, valamint fel kellett készíteni azokat az egymás közti adatáramlásra. 2. A vállalatirányítási rendszer adatstruktúráját át kellett alakítanom egy, a számomra megfelelő adattárház struktúrává, amelybe be kellett töltenem a szükséges adatokat. Implementálnom kellett az ehhez szükséges áttöltő modulokat. 3. Fel kellett készíteni az adattárházat, hogy azon el tudjam végezni az elemzéseket, azaz fel kellet építeni rá egy OLAP kockát. 4. Módosítani kellett a vállalat árazási rendszerét az elemzés következtében meghozott döntéseknek megfelelően.
3
A tervezett feladat blokkdiagramja:
NAV Adattárház
Excel kliens
Elemzés
Feltétel
Árlista 1. ábra – Az elvégzett részfeladatok
1.1. A feladat szoftver specifikus bemutatása A feladatom megoldása során a Microsoft Dynamics NAV vállalatirányítási rendszert használtam, egy demó vállalaton, a Cronus Rt.-n. A vállalatirányítási rendszer az adatok tárolására MS SQL Server-t használ. Ezen az adatbázis szerveren hoztam létre egy csillag sémás adattárházat, amiben az elemzéshez ténylegesen szükséges és hasznos adatokat tároltam el. A vállalatirányítási rendszer által tárolt adatok, adatstruktúrák logikai felépítése eltér az általam megkívánttól, ezért azok megvalósítása érdekében el kellett készítenem egy áttöltő modult, amely az áttöltésen felül át is alakítja a Dynamics NAV által használt adatstruktúrákat az adattárházamban használtnak megfelelő formára. Ezen áttöltő modult Visual Studio-ban készítettem el. Miután elkészült az adattárház és fel van töltve a szükséges adatokkal, felépítettem arra az OLAP kockát, melyre, mint adatforrásra ezután rácsatlakozom Excelből és ott ki tudom választani a kocka egyes dimenzióit, melyek az elemzésben különálló csoportokként jelennek meg. A választás azért esett az Excelre, mint az elemzést megvalósító programra, mert fejlett támogatás létezik bent a kockákra és egyszerűen lehet benne szemléletes diagramokat létrehozni. Ezen lehetőségek még életszerűbbé teszik a megvalósítást, hiszen a stratégiai döntéseket a vezetők hozzák, akikre általában vagy nem jellemző az informatikai rendszerek mély ismerete vagy nem rendelkeznek túl részletes információkkal a tényleges marketing tevékenységről, csak a számok és arányok fontosak nekik. Ahhoz azonban, hogy a vezetői döntéseket operatív megvalósítás is kövessen, azok eredményét vissza kell írni a vállalatirányítási rendszer árazási modulja által használt táblákba a megfelelő formátumban.
2. A feladat által érintett ismeretanyag A feladatom megoldásához szükséges ismeretanyag túlmutat a mérnök informatikus képzés eddigi tantárgyainak tematikáján, ezért ebben a fejezetben elkészítettem a főbb érintett
4
területek rövid elméleti összefoglalóját. Így próbálom meg közös alapokra helyezni a dolgozatomban a későbbiekben előforduló fogalmakat, kifejezéseket.
2.1. Árképzési gyakorlatok [2] [4] Az árképzés dinamikája szempontjából két csoportba szokásos felosztani az árazási stratégiákat. Ezeket részletesen az 1. táblázat mutatja be. 1. táblázat - Árazási mechanizmusok és az árazást befolyásoló tényezők a statikus és a dinamikus árazású piacokon.
Az árazás dinamikája
Árazás alapmechanizmusa
Típusai
Az árazást befolyásoló tényezők a kínálat oldalán
Az árazást befolyásoló tényezők a kereslet oldalán
Statikus
Eladó által „diktált” árazás, hagyományos listaárakkal
Diszkontárak
Értékesítési csatorna
Szezonális kereslet, divat
Eladó által „diktált” árazás, speciális differenciáláson nyugvó formái
Szegmentálás, előfizetés, árukapcsolás
Eladott mennyiség. A javak öszszekapcsolása
Különböző csoportokba tartozó vevők eltérő árérzékenysége
Vevői aktív áralkotó szerepet feltételező modellek
Aukció, tőzsde, csoportos vásárlás
A termék jellege, az eladók száma
Vevői szolidaritás, potenciális vevők száma
Az eladó által irányított, a vevőket elszigetelő módszerek
Árak személyre szabása, termékváltozatok, csomagban történő értékesítés
A termék személyre szabásának lehetőségei, a termékek adott volumene
A vevőkről begyűjthető információk, adatbányászat
Dinamikus
A statikus árazási stratégiák jól illeszkednek az ipari klasszicizmus szelleméhez, vagyis, hogy a kínálati oldal a domináns. Az árakat elsősorban az eladók szabják meg, úgynevezett „one-to-many” módon, amikor a vállalat a vevőkre, mint fogyasztók tömegére tekint. Ebben az esetben a vevők közti információáramlás tökéletlen, a vevők emiatt nem tudnak élni a tömegükből adódó lehetőségeikkel a kedvezőbb ár kialakítására nézve, azt csak fizetési hajlandóságukon és a keresleti árrugalmasságon keresztül, közvetetten képesek befolyásolni. A dinamikus árképzési stratégia kiteljesedését nagymértékben elősegítette a web kettes világ térhódítása. Ekkor ugyanis a technikai fejlődés döbbenetesen fellendítette az információ áramlását. Többé már nem voltak elszigeteltek a vevők. Az információ minden honnét ömlött rájuk, a kereső szolgáltatásokkal minden elérhetővé vált, amit csak meg akartak tudni egy termékről. Ezáltal elillant az eladók előnye. A vevők ettől a pillanattól kezdve pontosan meg tudták állapítani az áruk és a csatolt szolgáltatások értékét és egy adott értékhez pillanatok alatt meg tudták határozni a legkedvezőbb árat, vagy az adott áron elérhető legkedvezőbb szolgáltatásokat. A jól informált vevők az árak diktálóivá váltak. Vil-
5
lámgyorsan terjedni kezdtek a különböző aukciós oldalak, tőzsdei mintára szerveződő adok-veszek típusú portálok és a csoportos vásárlásra buzdító site-ok. Az internet adta lehetőségekre azonban nem csak a vevők figyeltek fel, az eladók is gyorsan idomultak a változásokhoz, érthető módon céljuk a mielőbbi visszaszorítása volt az új trendnek és az ár diktálási jogának visszavétele a vevőktől. A vevők egyre magabiztosabban mozognak a web áruházakban, azokra ők leginkább kényelmi funkcióként tekintenek, valamint informálódnak rajtuk keresztül az egyes termékek árairól, azonban keresgélésük során rengeteg információt hagynak a rendszerben maguk után, amelyek rendkívül hasznosak az eladók számára a vásárlói szokások feltérképezéséhez. Ezen információk alapján az árdiktálás visszaszerzéséhez a cél a vevők megosztása, egyéni árak, csoportokra szabott kedvezmények kialakítása. E felhasználói adatok elemzése és az ügyfelek szegmentációja hatékony megoldás lehet annak a klasszikus dilemmának a kezelésében, melyben az eladónak egyetlen egy árat kell meghatároznia. Ha ezt az árat azonban túl magasra teszi, akkor ez sokakat elriaszt a vásárlástól, akik csak mérsékeltebb áron mutatnának hajlandóságot arra. Ha az ár túl alacsony, akkor pedig a vállalat a haszon egy részét azoknál a fogyasztóknál hagyja, akik hajlandóak lettek volna többet is áldozni a termékre, szolgáltatásra. Dolgozatomban a vevők szegmentációra építő módszereket vizsgáltam.
2.1.1. Személyre szabott árképzés [4] Az előző bekezdésekből világossá válhatott, hogy a fogyasztó által érzékelt értéknek kitüntetett szerepe van az árképzés során. Például ha rohanunk a vonatra, és közben szeretnénk ételt vásárolni magunknak az útra, akkor a vasútállomáson a büfében vásárolható szendvics felértékelődik bennünk, mert a szendvics értékébe az az idő is bele fog számítani, amit azzal nyerünk, hogy nem kell a messzebb lévő sarki kisboltba kiszaladnunk. Ezért cserébe hajlandóak vagyunk többet fizetni a büfében, csakhogy időt nyerjünk. Ebben és az ilyen helyzetek minél jobb felismerésében rejlik a személyre szabott árképzés profitnövelő lehetősége. A személyre szabott árak logikus magyarázata a következőkben rejlik: egy adott termék/szolgáltatás keresleti görbéjét tekintsük adottnak, azon nem tudunk változtatni. Ekkor az értékesítésből adódó profit az előállítási költség és a bevétel különbsége, a 2. ábrán látható téglalap területe. Látható, hogy a teljes elérhető bevétel a háromszög alatti terület lenne, de ettől messze elmarad a vállalat. A maximális bevételtől való elmaradás a két háromszög területével magyarázható. Elszalasztott nyereség alatt azt a mennyiséget értjük, amennyivel többet lettek volna hajlandóak áldozni a vásárlók, de a vállalat annál alacsonyabb árat szabtunk ki nekik, asztalon hagyottnak pedig azt a mennyiséget nevezzük, amit azért bukik el, mert ezen ügyfelek nem vásárolják meg a szolgáltatást a jelenlegi áron, de annál alacsonyabban megvették volna. Egyik eset sem szerencsés, ezért ezen háromszögek területének minimalizálása és ezáltal a profit maximalizálása a cél.
6
2. ábra – A profitnégyzet a hozzá tartozó háromszögekkel
3. ábra – Több ár meghatározása
A 2. és 3. ábra alapján, a teljesség igénye nélkül belátható, ha több árat határozunk meg, ezáltal egyre jobban szétosztjuk a vásárlókat, akkor a vállalat árbevétele és ezáltal a profitja csökkenő ütemben, de növekszik ugyan. Maximális akkor lesz, ha a négyszögek területösszege megegyezik a háromszög területével, ezáltal az ügyfelek szeparációja teljessé válik, azaz minden vevőhöz egyedi árat határozunk meg. Azon felhasználók megtalálása, akik hajlandóak többet fizetni, mindegy, hogy milyen módon történik, úgyis nyerünk rajta és megéri a fáradságot, amennyiben az így elért nyereségnövekedés fedezi a többletmunka költségét. (csökkenő hasznosság elve) A gyakorlatban emellett fontos eltérés az elmélethez képest, hogy a vásárlók jól definiált többletszolgálta-
7
tásokat várnak el a többletfizetésért, ezért nem finomodhatnak a téglalapok minden határon túl. A személyre szabott ár kialakítása történhet: földrajzi alapon (vasúti büfé példája) vásárolt mennyiség alapján (lásd: 2.1.2 Nem lineáris árképzés) kínált szolgáltatás színvonal alapján (1. és 2. osztályú vasúti menetjegyek) vásárlás ideje alapján (előfoglalási kedvezmények) A módszer sikerességére ékes példa Sir Collin Marshall, a British Airways elnökének nyilatkozata az ár „kismértékű” személyre szabásának eredményükre gyakorolt hatásáról: „… az utazóközönség nagy rész meghatározott áron fog utazni… [de] néhányan közülük valamivel többet fognak fizetni. Hangsúlyozom azonban, hogy amikor „kismértékű” különbségekről beszélek, akkor arra is gondolok. Esetünkben 5%-os átlagos eltérésről beszélhetünk. […] Ez az 5% plusz 440 millió $-t hoz évente.”
2.1.2. Nem lineáris árképzés [4] Sok vezető költségcsökkenéssel magyarázza a nem lineáris árszabás bevezetését. A kedvezmények hatására a megnövekedett rendelési tételnagyság miatt csökkennek az eladó szállítási és raktározási költségei. Nem lineáris árképzés során mennyiségi kedvezményben részesíti a vállalat a partnereit, azaz az egyes eladott termékeken érvényesített határnyereség egyre csökken az értékesített mennyiség növekedésekor. Jövedelmező lehet a nem lineáris árképzési stratégia akkor, ha a kedvezmény megnöveli a vásárlási hajlandóságot, így az eladások megnövekedett száma kompenzálja a határnyereség csökkenését. Tipikus eset a nem lineáris árképzésre a bérletek árusítása. Például egy színházi előadás 1000 Ft-ba kerül, de az 5 alkalmas bérletet már 4000 Ft-ért meg lehet vásárolni.
2.2. Adattárházak [5] [8] Az adattárház az információtechnológia viszonylag frissen önálló életre kelt ága, mintegy egy évtizedes múltra visszatekintő területe. Rohamléptekkel, egyszerre több irányba fejlődő, kiforratlan és már bizonyított technológiák halmaza, kevés elismert szabvánnyal, sok eltérő szolgáltatással és termékkel. Nehéz rá jó definíciót adni. Bill Inmon, a téma egyik apostolának legtöbbet idézett definíciója így szól: "A data warehouse is a subject oriented, integrated, nonvolatile, and time variant collection of data in support of management's decisions.", vagyis tárgy orientált, integrált, tartós és idő független gyűjteménye az adatoknak, mely a vezetői döntéshozást támogatja. Jobban végiggondolva a definíciót, kellően világos képet kaphatunk az adattárházak miben létéről: Subject oriented (tárgy orientált): Az adattárházakat mindig valamilyen jól definiált céllal hozzuk létre, azok meghatározott adatok köré épülnek, például az értékesítési adatok köré. Integrated (integrált): Az előz pontban említettet tárgyorientált, adatvezérelt tervezéshez szorosan kapcsolódik az integráltság fogalma abban az értelemben, hogy az adattárházban tárolt adatokat egy az adott tárgyterületre jellemzően csoportosítva célszerű tárolni. Nonvolatile (nem illékony): Azaz alapelvárás az adattárházba betöltött adatokkal szemben, hogy azok változatlanok legyenek. Amennyiben a forrásrendszer mégis megváltoztatná azokat, abban az esetben megfelelő időbélyegekkel kell ellátni őket. Time variant (időfüggetlen): Az adatokat általában jelen pillanatban töltjük be az adattárházba, de az elemzéseket múltbeli forrásokra támaszkodva végezzük el, és abból következtetünk jövőbeli eseményekre. Ezért az adatokat időponttól függetle-
8
nül kell időszakokhoz tárolnunk, hogy abból a szükséges riportok könnyen elérhetők legyenek. Az adattárház műveletek alatt általában a következőket értjük: a) Adatkinyerés tranzakciós, vagy más rendszerből, pl.: a vállalatirányítási rendszerből b) A kinyert adatok átalakítása a beszámoló elkészítéséhez alkalmas formára. c) A riportok, beszámolók elérhetővé tétele a döntéshozók számára. Az adattárház felépítése e céloknak megfelelően eltér az Adatbázisok című tárgyból tanultaktól. [1] Ebben az esetben az elsődleges szempont az adatok hatékony kinyerése az elemzések elkészítéséhez, azaz megengedhető némi redundancia a teljesítmény növeléséhez. Az adattárházakat általában csillag vagy hópihe sémában építik fel. Mindkét esetben az elemzés szempontjából fontos adatokat a ténytáblában helyezik el. Ide kerül be a vállalatirányítási rendszer törzs adatállományának megfelelő transzformáltja. Eköré, az úgynevezett dimenzió táblákba kerülnek be azon információk, melyek szerint a szűréseket, csoportosításokat elkészíthetik. Ezen táblákban, az ezek adatsémáiban, a köztük kapcsolatokban tér el egymástól a csillag és a hópihe séma. Csillagsémánál az elemzési dimenziók idegen kulcscsal kapcsolódnak közvetlenül a ténytáblához a 4. ábrán látható módon.
4. ábra – Csillagséma ER diagramja
Ezzel szemben hópihe séma esetében az egyes dimenziótáblák a természetes logikát követve egymással is kapcsolatban álnak, például az egyes üzletek városokban vannak, a városok megyékhez tartoznak, és így tovább. A hópihe séma ER (Entitás Relációs) diagramjára példa az 5. ábrán látható.
9
5. ábra – Hópihe séma ER diagramja
A témám feldolgozása során csillag sémás adattárházat építettem fel. A csillag séma összehasonlítása a hópihével: Előnyei: egyszerű, intuitív adatmodell használata kevés join adatbázis műveletet igényel használata kevés tábla olvasását igényli könnyű megvalósíthatóság, a modell meta adatai (adatokat leíró adat) egyszerűek Hátrányai: aggregációk (összegek) képzése nehézkes nagy dimenziótáblák esetén a hierarchiakezelés nagyon lassíthatja a lekérdezéseket a dimenzióadatok tárolása redundáns
2.3. Az OLAP kocka A vállalatirányítás rendszerek On Line Transaction Process (OLTP) elven működnek, azaz fő rendező elvük a tranzakciók végrehajtása. A felhasználók, a programok apró, elemi műveletek sorozatát hajtják végre a tranzakciókban, ezáltal egyes adatbázis objektumok állapotát kérdezik le, frissítik egymástól függetlenül, konkurens módon. Az elemzésekhez azonban ez a megközelítés nem megfelelő. Ilyen célokra az On Line Analysis Process (OLAP) megközelítés használatos. Az OLAP módszerek mindig magukba foglalják az adatok interaktív lekérdezését, valamint azok elemzését is. A felépített adattárház adatstruktúrája már úgy van megtervezve, hogy az a lehető leghatékonyabban segítse ezt a szemléletet, emiatt az adattárház és az OLAP fogalmak a gyakorlatban teljesen összefonódtak.
10
6. ábra – Értékesítési OLAP kocka 3 dimenziós reprezentációja
Az OLAP kocka egy adatszerkezet az adattárházban tárolt adatok elemzéséhez, csoportosításához. A kocka egyes dimenzióit az adattárház dimenzió táblái képzik, ezek szerint tudjuk beazonosítani a ténytáblában tárolt adatok egyes összetett részhalmazait. A kocka felépítését a 6. ábra tartalmazza. Gyakran tárolják el az egyes termékek a részhalmazok egyesítésekor, aggregálásukkor az egyes halmazok összesített mutatószámait. Így jelentős teljesítménynövekedés érhető el. A gyakorlatban természetesen több dimenziót is alkalmazhatunk, azonban ez ritkán indokolt és könnyen vezethet nehezen áttekinthető végeredményhez. A sok dimenzió szerinti analízis már inkább az adatbányászat területébe nyúlik át.
2.4. Microsoft Dynamics NAV funkcionális áttekintése A Dynamics NAV (más nevén Navision) a Microsoft ERP rendszere, kifejezetten kis- és középvállalatok számára. A vállalat napi teendőinek ellátásához teljes körű segítséget nyújt, minden elvégzendő vállalati feladathoz rendelkezik megfelelő modullal. Főbb moduljai a pénzügy, kereskedelem, CRM, termelésirányítás, raktárkezelés, projekt menedzsment, humán erőforrás és üzleti elemzés. A felhasználói felület felépítése és a megjelenő űrlapok nagyban hasonlítanak a félév során a QAD EA-ban és SAP Business One-ban megismertekre. A pénzügyi modulban állíthatók be a vállalat főkönyvi adatai, kezelhetők az eszközök és a bankszámlák, de itt kérdezhetők le a vállalat cash-flow és likviditási adatai is. A kereskedelem modulban találhatók meg a szállítói beszerzéseket és az értékesítést támogató modulok. Ezek egymáshoz rendkívül hasonlóak, hiszen a két műveletnél ugyanazon folyamatnak a két oldalán van a vállalat, ettől eltekintve a fogalmak hasonlóak: ajánlatok, megrendelések, visszaigazolások, számlák. A CRM rendszeren keresztül kerül kapcsolatba a termelés a vevőkkel, itt kerülnek megvalósításra azon funkciók, melyek az ügyféladatok kiértékelésében és az árképzésben támogatják a felhasználót. A termelésirányítási modulban nyílik lehetőségünk az agyagjegyzékek, a termékútvonalak, a kapacitás, az ütemezés, és a gyártási megrendelések létrehozására, karbantartására. A raktározás blokkjában a belső és külső árumozgatások összehangolása történik meg a tárolási költségek minimalizálása és a vevői kiszolgálás színvonalának növelése érdekében. A projektmenedzsment menüponton keresztül érhetők el az egyes projektek adatai, mint például az előrehaladása, költségei. 11
A humán erőforrás modulban tarthatók karban az egyes dolgozók törzsadatai, mint a munkaidő, a munkabér, az alkalmazottakhoz kapcsolódó ráfordítások vagy a személyi jellegű költségek. Az üzleti elemzés modul a vállalat főbb mutatóit fogja össze egy csoportba, azokat viszonyítja a tervezési adatokhoz. Szállító
Vevő Keresés
Megkeresés
Ajánlat
Ajánlat Készletvizsgálat Megrendelés
Megrendelés
Szállítás
Termelés Projekt Szerviz
Anyag raktár
Raktár
Szállítás
Számlázás
Számla
Számlázás
Átutalás
Bank
Átutalás
Szállítás
Könyvelés
7. ábra – Üzleti folyamatok egymásra épülése a Microsoft Dynamics NAV-ban
2.5. Árképzés Microsoft Dynamics NAV környezetben Az árképzéssel elsősorban az értékesítés kapcsán kell foglalkoznunk a Navisionben. Ennek elhelyezkedése a program hierarchiájában a 7. ábrán látható. Mivel ez képzi a feladatom központi problémáját, ezért a későbbiekben erre fektetek nagyobb hangsúlyt. Az árképzésért nem egy modul felelős, az egy hosszú folyamat, mely több rendszert is érint. Alapvetően az CRM hatásköréhez tartozik azon vevők felderítése, akik hajlandóak magasabb árat fizetni a nekik kínált termékért, de mint a 8. ábra is mutatja, ezt nem képes egymagában ellátni. Nem kaphatunk pontos képet a vevőinkről, anélkül, hogy ne ismernénk a múltjukat, korábbi vásárlásaikat, szokásaikat. Ehhez a történeti adatokhoz kell viszszanyúlnunk, melyeket a vállalatirányítási rendszer adatbázisában találunk. A kialakítandó árat mindig a jelenlegi helyzet alapján, a jövőbeni tervek érdekében, a múltbéli adatok figyelembevételével kell meghatározni. Ez a vállalati rendszer részeinek a szerves együtt működését követeli meg. Az ERP és a CRM közösen kísérik végig a vevőt a megkereséstől a termék egész életútján a 8. ábrán látható módon.
12
8. ábra - A CRM és az ERP kapcsolata az áralkotásban
Az árakat alapbeállításként a terméktörzsben lehet definiálni. Ettől eltérni ennek módosítása nélkül az Eladás és marketing/Készlet és árképzés/Eladási ár munkalapon lehet. Itt tudunk definiálni különféle kedvezményeket, egyedi árakat. Lehetőségünk van beállítani az új árazási stratégia kezdő és befejezési dátumát, annak érvényességi körét, mind termékre, mint vásárlóra, vagy akár könyvelési vagy árcsoportra. Új egyéni ár létrehozásakor az alábbi paraméterek megadására van szükség: Kezdési/befejezési dátum: az ár érvényességi idejét szabja meg Eladás típusa: itt adható meg, hogy az Eladási kód mezőben szereplő érték mely paraméterre értendő Cikkszám: az új ár az itt megadott termékre lesz csak érvényes Mértékegység Minimális mennyiség: azt a minimális rendelési mennyiséget jelenti, ami alatt nem érvényes az egyedi ár Új egységár: az az ár, amelyen az előbbi feltételek teljesülésekor az adott termék megvásárolható Sorengedmény %: az árengedmény az eredeti ár százalékában kifejezve
3. Az önálló laboratóriumi feladat megvalósítása A félév első felében az eddig leírtakban igyekeztem elmélyülni, hogy az elkészített megoldásom kellően átgondolt legyen. Úgy vélem, hogy ezen ismeretanyag elsajátítása után kellően tudatosan tudtam nekiállni a probléma vizsgálatának. Ezt követően került megfogalmazásra, hogy mi is az a konkrét feladat, mit fogok a félév során elkészíteni. Ebben a fejezetben a megoldás főbb lépéseit, tervezés fázisait mutatom be. Próbálom tisztázni az egyes tervezői döntésekhez vezető okokat, előzményeket.
13
3.1. A fejlesztőkörnyezet kialakítása A feladatom a hozzá szükséges fejlesztési környezet kialakításával kezdtem. A megoldásban virtuális gépen futtatok Windows XP Professional SP3 operációs rendszert, és rajta Microsoft SQL SERVER 2008 R2 Standard adatbázisszervert. Az adatbázis-kezelőt a következő szolgáltatásokkal telepítettem: SQL Server, Analysis Server valamint SQL Server Business Intelligence Development Studio. A Business Intelligence Development Studio a Visual Studio 2008 speciális konfigurációja, adatbázis folyamatok fejlesztésére. Az elemzéseket Excel 2010 programban készítem el a fejlettebb Analysis Service támogatás miatt. Az alkalmazott vállalatirányítási rendszer Microsoft Dynamics NAV 5.0. A Dynamics NAV telepítése után létrehoztam benne a Microsoft Demó vállalatát a Cronus Rt.-t, azt az adatbázis kiszolgálom tároltam el. Ahhoz, hogy az ERP elérje az adatbázis szervert a következő beállításokat kellett elvégeznem: - az xp_ndo.dll elhelyezése az MSSQL telepítési könyvtárában, alapesetben a C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\xp_ndo.dll útvonalon [3] - az SQL szerveren be kellett állítani a xp_ndo_enumusergroups és xp_ndo_enumusersids távoli eljáráshívásokat (Remote Procedure Call, RPC) [3]
3.2. A Microsoft Dynamics NAV adatstruktúrájának megismerése Mint minden vállalatirányítási rendszer a Navision is rengeteg adatot tárol el, rendkívül összetett, először kuszának tűnő struktúrában. Természetesen nem célom ezek részletes bemutatása, csupán az árelemzés során felhasznál táblák bemutatása és a köztük lévő kapcsolatok felderítése. A program telepítésekor és a vállalat létrehozásakor az adatok tárolására két lehetőségünk van: vagy a merevlemezen tároljuk azt fájlban, vagy adatbázis szerveren. Én ez utóbbit választottam, ehhez a 3.1-es pontban ismertetett távoli eljáráshívásokat be kellett állítani. A táblákhoz kétféle módon lehet hozzáférni: közvetlenül megkereshetjük az adatbázisban azt, vagy Dynamics NAV-ban kiválasztunk egy menüpontot, például az Eladás és marketing/Eladás/Vevők útvonalon feljövő űrlapon tudjuk kezelni a vevői törzsadatainkat. Ekkor a fejlécben megváltozik a felirat:
9. ábra - A Navision fejléce
A szögletes zárójelek közötti részben olvasható, mely formon járunk, és az mely táblát használja. Jelen esetben a Vevőkarton táblát használjuk. Az adatbázisban azonban angol nevükön szerepelnek a táblák. A magyar-angol megfeleltetést a táblanevek között legegyszerűbben az Obejct Designer-rel tudjuk megtalálni. Ezt az Eszközök menüből érjük el vagy a Shift+F12 billentyűkombinációval. A táblák magyar neve nem jelenik meg alapból, azt külön be kell kapcsolni az oszlopok megjelenítésénél, a Caption-t bepipálva. Ezek után már tudjuk azonosítani, hogy az adattárházhoz szükséges információk mely táblákból nyerhetjük ki. Az árelemzéshez feladatomban a tényadatokat az Eladás, Eladási számla és Eladási jóváírás táblákból nyerem főrészt. Ezen bizonylatok adataikat több táblában tárolják el. Minden bizonylathoz tartozik egy fej tábla bejegyzés, ami a partnerek általános törzsadatait, a kapcsolattartás, számlázás, fizetés, szállítás és a külkereskedelem adatait tárolja a rendszer. Valamint minden bizonylattípushoz tartozik egy adat tábla is, amiben a bizonylatok egyes sorai tárolódnak. Itt jelenik meg, a számlaazonosító, mint ide-
14
gen kulcs a számla fejére, a vevő azonosítója, cikkazonosító, mennyiség, egységár, kedvezmény, ÁFA, sorösszeg, stb.
10. ábra - A számla általános felépítése
Ahogy a 10. ábra is mutatja, a számlafej és a számlatörzs között egy-több kapcsolat van, több számlatörzs rekordból és egy fejrekordból épül fel egy számla. Ezenkívül még rengeteg egyéb kapcsolatban állnak ezen táblák az idegen kulcsaikon keresztül, például a vevő-, cikk-, könyvelési csoport, fizetési feltételek táblával. Miután megismertük az OLAP kocka alapjait, és megtaláltuk azon adatokat az ERP-ben, amik majd a kocka ténytábláját alkothatják, meg kell határozni azon attribútumokat, melyek alkalmasak rá, hogy dimenzióként használjuk őket. A dimenzió megválasztásakor érdemes előre gondolkodni, hogy melyek lehetnek azok az adatok, amelyek mentén lehet csoportosítani az adatainkat, és az eredményre is vezethet. Érdemes lehet például elemezni az egyes cikkek eladásait, vásárlóink fogyasztását, kedvezményeiket, területi elhelyezkedésüket, azt, hogy vásárlásaikat mely időszakokra ütemezik. Ezek közül a legtöbb adatot pusztán a vállalatirányítási rendszerből ki tudjuk nyerni a fent ismertetett módon. Én dimenzióként vettem fel, több, a vállalatirányítási rendszerben használt paramétert, törzsadatot, mint például a könyvelési-, ár-, és kedvezménycsoportot, a cikkeket, határidőket, vevőket és azok földrajzi elhelyezkedését. Ezen adatok mind az adatbázis egyes tábláiban érhetők el, melyeket az Object Designer-rel találtam meg. Az értékesítési elemzéshez lassan minden tábla rendelkezésre állt. Ahhoz azonban, hogy az elemzés ne csak egy statikus folyamat legyen, hanem a felhasználó könnyedén hozhasson létre engedményeket, egyedi árakat az eredmények függvényében, meg kellett keresni azt ahol ezek tárolva vannak. A keresett funkciót megtaláljuk az Eladás és marketing/Eladás/Vevő útvonalon, majd ott az Eladás gombra, majd a Sorengedményekre kattintva. Ezután megkereshetjük a tároló táblát: Vevői sorengedmények.
3.3. Az adattárház struktúrájának kialakítása Az elemzés megvalósításához az adatokat a vállalatirányítási rendszer adatbázisából át töltöttem egy adattárházba. Az adattárházban nem a vállalat aktuális „működési” adatai szerepelnek, hanem az archivált adatok lehető legbővebb gyűjteménye. Itt már nem szempont a vállalat napi ügyeinek a nyomon követése. Mivel az adattárház szerepe, feladata sok esetben eltér a normál adatbázisokétól, ezért létrehozásukkor is más szempontok szerint kell eljárni. Az adatbázisba általában adatokat viszünk be, tároljuk azokat, ezért a legfontosabb szempont a struktúra megalkotásakor a redundancia mentesség és a függőségek veszteségmentes feloldása. Lekérdezéseket ritkábban futtatunk, és azok eredményhalmaza a teljes struktúra viszonylag kis részét fedi le. Emiatt dominál a tárhely kedvezőbb kihasználása a join műveleteknél elszenvedett plusz műveleti idő felett. Ezzel szemben az adattárházakban sokkal nagyobb hangsúlyt kap az adatok elérése a döntések meghozatalakor egy jól strukturált, áttekinthető formában. Ezért az információt azzal a céllal tároljuk, hogy onnét azt szakaszos beírás után többször kinyerjük. Ennek köszönhetően az adat esetleg redundánsan több táblában is elhelyezkedik. Az adattárház felépítéséhez csillag sémát választottam, főként a kisszámú tábla és a modell egyszerűsége miatt.
15
A következő táblák szerepelnek benne: -
DimCustomer: A vevők adatait tartalmazó dimenziótábla DimDiscountGroup: A vevői árcsoportokat tartalmazó dimenzió DimItem: A cikkek tulajdonságai DimLocation: A vevők földrajzi elhelyezkedésének dimenziója DimPostingGroup: Az ERP-ben tárolt könyvelési csoportok DimPriceGroup: A tárolt vevői árcsoportok DimTime: Idő dimenzió a könyvelési és szállítási határidőhöz FactTable: Az adattárház ténytáblája
Az adattárház tábláit a következő SQL scripttel hoztam létre: Dimenziótáblák létrehozása: -- A ténytáblák létrehozása CREATE TABLE onlab.dbo.DimTime( [DateKey] int IDENTITY (1, 1) PRIMARY KEY, [Date] datetime UNIQUE NOT NULL, [DayNumberOfWeek] int NOT NULL, [DayNumberOfMonth] int NOT NULL, [DayNumberOfYear] int NOT NULL, [WeekNumberOfYear] int NOT NULL, [MonthNumberOfYear] int NOT NULL, [QuarterOfYear] int NOT NULL, [SemesterOfYear] int NOT NULL, [Year] int NOT NULL, -- Az idő táblába való beszúrás előtt leellenőrzöm a dátum constrainteket. CONSTRAINT C_DimTable_DNOW CHECK (DayNumberOfWeek BETWEEN '1' AND '7'), CONSTRAINT C_DimTable_DNOM CHECK (DayNumberOfMonth BETWEEN '1' AND '31'), CONSTRAINT C_DimTable_DNOY CHECK (DayNumberOfYear BETWEEN '1' AND '366'), CONSTRAINT C_DimTable_WNOY CHECK (WeekNumberOfYear BETWEEN '1' AND '53'), CONSTRAINT C_DimTable_MNOY CHECK (MonthNumberOfYear BETWEEN '1' AND '12'), CONSTRAINT C_DimTable_QOY CHECK (QuarterOfYear BETWEEN '1' AND '4'), CONSTRAINT C_DimTable_SOY CHECK (SemesterOfYear BETWEEN '1' AND '2') ); -- A földrajzi elhelyezkedés táblájának létrehozása CREATE TABLE onlab.dbo.DimLocation( [CountryCode] nvarchar(2), [City] nvarchar(30), [CustomerID] nvarchar(20) PRIMARY KEY, [Country] nvarchar(255) ); -- A könyvelési csoport táblájának létrehozása CREATE TABLE onlab.dbo.DimPostingGroup( [PostingCode] int IDENTITY (1, 1) PRIMARY KEY, [PostingGroup] nvarchar(30) UNIQUE NOT NULL ); -- A vevői árcsoport táblájának létrehozása CREATE TABLE onlab.dbo.DimPriceGroup( [Code] nvarchar(10) PRIMARY KEY NOT NULL, [Description] nvarchar(30) NOT NULL );
16
-- A kedvezmény csoport táblájának létrehozása CREATE TABLE onlab.dbo.DimDiscountGroup( [Code] nvarchar(10) PRIMARY KEY, [Description] nvarchar(30) NOT NULL ); -- Az eszköz tábla létrehozása CREATE TABLE onlab.dbo.DimItem( [No] nvarchar(20) NOT NULL PRIMARY KEY, [Description] nvarchar(30) ); -- A vevő tábla létrehozása CREATE TABLE onlab.dbo.DimCustomer( [IDNumber] varchar(20) PRIMARY KEY NOT NULL, [Name] varchar(50) UNIQUE NOT NULL );
A ténytáblában el kell tárolni a dimenziótáblák kulcsait is idegen kulcsként, a függőségek megőrzéséhez. Emiatt, valamint a tárolt adatok sokfélesége miatt a tábla attribútumainak száma bőven meghaladja a dimenziótáblákét. A ténytáblát létrehozó script: -- A ténytábla létrehozása CREATE TABLE onlab.dbo.FactTable ( "No_" nvarchar(20), "Sell-to Customer No_" nvarchar(20), "Bill-to Name" nvarchar(50), "Bill-to Address" nvarchar(50), "Bill-to City" nvarchar(30), "Posting Date" datetime, "Shipment Date" datetime, "Payment Discount %" numeric(38,20), "Customer Posting Group" nvarchar(10), "Currency Code" nvarchar(10), "Currency Factor" numeric(38,20), "Customer Price Code" nvarchar(10), "Customer Discount Code" nvarchar(10), "ItemNo" nvarchar(20), "Description" nvarchar(50), "Unit of Measure" nvarchar(10), "Quantity" numeric(38,20), "Unit Price" numeric(38,20), "Unit Cost (LCY)" numeric(38,20), "VAT %" numeric(38,20), "Line Discount %" numeric(38,20), "Line Discount Amount" numeric(38,20), "Amount" numeric(38,20), "Amount Including VAT" numeric(38,20), "Country Code" nvarchar(2), "Shipment Date Code" int, "Posting Date Code" int, "Customer Posting Code" int );
17
3.4. Ismerkedés a Business Intelligence Development Studio-val [6] Az MS SQL Server beépítetten tartalmazza a Visual Studio egy speciálisan konfigurált változatát, a Business Intelligence Development Studio-t, amellyel egy LabView szerű, grafikus programozói felületen tudunk áttöltő modulokat készíteni. A program használatának megtanulásához könnyen érthető demók találhatók a social.msdn.microsoft.com web helyen. A rendszer működésének megismeréséhez, valamint demók készítéséhez elérhető egy AdventureWorks nevű alkalmazás is, mely telepítése során több mintaadatbázist hoz létre a kiszolgálón. Ennek telepítése nagy segítséget jelentett a rendszerrel való ismerkedés folyamán. A félév során megismerkedtem a Business Intelligence Development Studio grafikus programozói felületével, és a programozással benne. [7] Az önálló laborom megoldásához a programban elkészített folyamatok a 12-14. és a 18. ábrákon láthatók. Az így elkészített folyamatok aciklikus gráfok, melyek csomópontjaiban helyezkednek el az adatokat átalakító műveletek, élei pedig csővezetékeket hoznak létre az adat áramlásához.
3.5. Az ETL folyamat elkészítése Az adattárház struktúrájának létrehozása önmagában még nem túl nagy feladat, hiszen az még üres, nincs bent adat. A feltöltése a vállalatirányítási rendszer adatbázisából történik meg. A Navision adatbázisát tanulmányozva hamar rájöhetünk arra, hogy annak felépítése nem egyezik meg az előzőekben létrehozott adattárház-struktúrával, az adatokat át kell alakítani betöltés előtt. Az ilyen adatbázis folyamatokat Extract, Transform, Load-nak (kinyer, átalakít, betölt (ETL)) nevezik. A minél könnyebb továbbfejleszthetőség miatt a következő névkonvenciót vezettem be a dimenziótáblákra: az általam létrehozott dimenziótábla neve a „Dim” előtaggal kezdődik, majd utána következik a forrástábla NAV által használt angol neve. A folyamatot próbáltam a lehetőségeimhez mérten minél inkább automatizálni, hogy ütemezetten is futtatható legyen kis változtatással. Az emberi beavatkozás szükségességét természetesen nem lehet elkerülni, hiszen az árképzés stratégiai döntés. Az ETL folyamatom state-chart diagramja a 11. ábrán látható. A process elején hozom létre az adattárház sémáját a fent bemutatott SQL script segítségével. Ezután megkezdődik a dimenzió táblák adatainak áttöltése az ERP adatbázisából az adattárház megfelelő tábláiba. Ezek általában egyszerű SQL lekérdezésekből állnak, majd az eredmény beíródik a megfelelő adattáblába. Végül az elkészült dimenzió táblák alapján, már fel lehet tölteni a ténytáblát is. A ténytáblába az adatokat némi átalakítás után az egyes értékesítési bizonylatok soraiból veszem.
18
11. ábra - Az elkészített ETL folyamat state-chart-ja
Ahhoz, hogy az egyes adatfolyamatokat definiálni tudjam, először létre kellett hoznom a vezérlési folyamatot Visual Studio-ban a state-chart alapján, majd az egyes állapotokat bővítettem ki adatfolyamokkal.
3.5.1. A dimenziótáblák feltöltése Az egyes dimenziótáblák feltöltése nagyon hasonlóan néz ki a feladatomban. Ezért részletesen csak a vevői árcsoport szerinti feltöltést ismertetem részletesen, illetve az ehhez képesti eltérésekre térek ki a többi esetben. A dimenzió táblák feltöltése többnyire egyszerű. A projekthez definiálni kellett egy kapcsolatot, mely rendelkezik az adatbázishoz való hozzáférést biztosító proterty stringgel. Ezután létre hoztam az adatfolyamot: két objektum, csővezetékkel összekötve. Kell egy, ami kiolvas az ERP adatbázisából és egy, ami a kiolvasott adatokat beírja az adattárház megfelelő táblájába. Az árcsoport táblához tartozó adatfolyamot a 12. ábra mutatja.
19
12. ábra - Egyszerű adatfolyam
Az adatfolyam ténylegesen csak egy forrásból és egy célból áll. A forrásban választható ki, hogy mely adatkapcsolatból olvasson ki adatokat. Itt beállítottam az ERP adatbázisára mutató korábbi kapcsolat objektumot, ez után kiválaszthatóvá válik, hogy mely táblából akarunk olvasni. Emellett elérhető egy saját SQL parancs kiadását lehetővé tevő opció is. Én azt választottam. A döntésem indoka a következő volt: általában a táblák nagyon sok attribútumot tartalmaznak, ezeknek csak a töredékére van szükségem, ezért csak azokat kérdeztem le, amik ténylegesen bekerülnek az adattárházba. Így biztosan kisebb lesz az adatforgalom az adatbázis szerver és az adattárház között, valamint a folyamat rövidebb processzoridőt igényel a kevesebb feldolgozandó adat miatt. A cél beállítása hasonló a forráséhoz. Itt is ki kell választani a célobjektum leíróját, ezért definiáltam egy további kapcsolatot, de ez esetben az adattárházhoz. Majd itt is beállítható a cél adatbázis, illetve annak egy már létező táblája, vagy új tábla hozható létre. Mivel az adattárházban az adatokat időszakonként töltjük be, ilyen és ehhez hasonló folyamatokkal ezért az inicializálásnál hoztam létre a táblát, hogy most, az áttöltés során már csak bele kelljen írni abba. Ezáltal többször használható, bővíthető lesz a projekt. A már létező tábla attribútumaihoz ezután hozzá kell rendelni az adatfolyam attribútumait, ezt angolul mapping-nak nevezik. Ez egy egy-egy kapcsolat, amely meghatározza, hogy az adatfolyam mely adatai pontosan melyik tulajdonságnak feleljenek majd meg a kimeneten. Ha nem található a bemeneten adat, akkor a kimenetre automatikusan NULL érték kerül. A többi dimenzió tábla feltöltése ehhez hasonlóan zajlik, természetesen mások a be- és kimeneti táblák azoknál. Lényegesebb eltérés van azonban az időt és a földrajzi elhelyezkedést definiáló dimenziótáblákban az eddigiekhez képest. Az idő dimenziónál az adatokat egy Excel táblába generáltam le, az AdventureWorks demótáblájának mintájára, melyet a 13. ábra mutat.
2. táblázat - Az idő dimenzió paramétereit tartalmazó Excel tábla részlete
Tehát az idő dimenziót tartalmazó adattáblát nem adatbázisból, hanem Excel táblából kell feltölteni. Ehhez speciális kapcsolatot kell létrehozni az adatbázis kapcsolathoz hasonlóan, amelyben a kapcsolat leíró objektum egy munkafüzetre tartalmaz mutatót. Ezután külön definiálni kell hozzá új adatforrást a megfelelő állapothoz, amely Excel munkafüzetből 20
képes adatokat beolvasni. A kimenet kezelése megegyezik az árcsoport dimenziónál leírtakkal, hiszen a cél itt is egy tábla lesz az adattárházban. A dimenziótáblák feltöltése közül a legösszetettebb a földrajzi elhelyezkedést tároló tábláé. Ennek menetét a 14. ábrán követhetjük végig.
13. ábra - A földrajzi elhelyezkedés tábla feltöltése
Itt két adatforrásból nyertem ki az összes szükséges információt. Egyrészt a vállalatirányítási rendszer vevői törzsadatait tartalmazó táblából a vevő országának rövidítését, városát és azonosítóját, másrészt készítettem egy Excel munkafüzetet, melyben eltároltam az országok rövidítését és tejes nevüket. Miután beolvastam az adatot mindkét forrásból, azokat össze kell illeszteni, hiszen közösen fognak egy rekordot alkotni. Erre való a Merge Join művelet a Visual Studio-ban, ami négy bemenő paramétert vár: a két illesztendő, illesztési kulcs szerint rendezett adathalmazt, és az illesztési attribútumok nevét az adathalmazokban. A rendezett bemenetek megteremtéséhez rendező objektumokat illesztettem be az adatfolyam gráfba, az illesztési attribútumokat pedig az illesztő objektum tulajdonságainál határoztam meg. Az így előálló n+m-1 attribútumú adathalmazt, - ahol m és n a bemenetek attribútumainak száma - a már ismertetett módon hozzácsatoltam egy cél objektumhoz, amely beszúrja azt az adattárház megfelelő táblájába.
3.5.2. A ténytábla feltöltése A dimenziók megtervezése és létrehozása után minden feltétel adottá vált, az adattárház ténytáblájának elkészítéséhez. Az ERP adatainak áttöltése a ténytáblába bonyolult feladat, amely sok, apróbb részfeladatból áll össze. Ezen kisebb részfeladatokat mutatom be ebben a fejezetben, a betöltő teljes adatfolyam-diagramja a 15. ábrán látható. Az adatok kinyerése a vállalatirányítási rendszer adatbázisából itt is hasonló kapcsolat leíró objektumokon keresztül történik, mint a dimenziótáblák elkészítésénél. Igyekeztem itt is 21
csupán a szükséges attribútumokat lekérdezni ezeken keresztül, hogy az adatmozgatást és a vele járó hálózatterhelést minimalizálni tudjam. A dimenzióktól eltérő módon azonban minden egyes vevői bizonylat adatállománya kettő adattáblában van szétosztva. Ezért az egyes táblákból különböző adatokat érünk el a bizonylatokról, melyeket egyértelműen azonosít és az adataikat összekapcsolja a bizonylat azonosítója a földrajzi elhelyezkedésnél már bemutatott join merge művelet segítségével. Ehhez itt is rendezni kell a bemeneti adatfolyamokat. A bizonylatok soraiban szereplő adatok nagyon hasonlóak, azonban a jelentésük eltérő lehet, ezért nem szabad meggondolatlanul áttölteni azokat az adattárházba, hiszen bizonylattípustól függően más és más jelentése lehet számunkra az adott mezőknek, még ha nevük azonos is. Például az eladási jóváírások esetében az eladott áruk mennyisége és a bevételünk nem növekszik, noha ezen mennyiségek pozitívan jelennek meg a bizonylatokon (ellentétben a QAD EA-val, ahol a stornózáskor negatív mennyiséggel is felkerül a tétel). Ahhoz, hogy ez ne okozzon téves forgalmat a statisztikai adatokban, és ne torzítsa el az elemzés eredményét, ezen számlák végösszege és darabszáma negatívan kell, hogy bekerüljön az adattárházba. Ehhez a Derived Culomn nevű komponenst használtam, ami a bemenetére kötött adatfolyam attribútumain képes aritmetikai műveleteket elvégezni. Miután minden bizonylatsor és a hozzá tartozó bizonylatfej egyesítésre került, a három adatállomány szerkezete teljesen egységes és semmi sem indokolja a külön kezelésüket a továbbiakban, ezért a három adathalmaz unióját képzem a további műveletek előtt az Union All metódus segítségével. Ebben a pillanatban az adatfolyamban előállt minden adattal, amit a ténytáblából az elemzés során ki szeretnék majd nyerni. Egy fontos szakasz azonban még hátra van, mielőtt az adattárházba be lehetne írni: el kell helyezni a dimenziótáblák kulcsait, ugyanis jelenlegi állapotában az adatállomány soraihoz nem, vagy csak nagyon erőforrás igényes műveletekkel lehetne hozzárendelni a dimenziókat. Ennek elkerülése végett a dimenziótáblák kulcsait idegen kulcsként el kell helyezni a formálódó adatállományba. A kulcsok beszúrásához az úgynevezett Lookup komponenseket használom fel. Mint a neve is mutatja, egy lookup táblát megvalósító feltételes szerkezet, ami ha … akkor … típusú ellenőrzésekre használható. Általánosságban véve nagy hátránya, hogy nagyon merev a szerkezet, nem képes tanulásra, csak a táblából képes visszaadni értéket. Ez itt nem jelent problémát, hiszen az ERP rendszerből úgy sem lehet kinyerni természetes működés mellett olyan adatot, ami nem szerepel bent. Másik hátránya a tábla méretéből adódó keresés komplexitása, ezt azonban speciális adatbázis környezetben lehet például ritkaindexeléssel javítani. Minden dimenziótábla kulcsa egy lookup tábla segítségével kerül bele egy új attribútumként az átalakítandó adathalmazba Miután minden kulcsot megkapott a kiolvasott, átalakított adat, az elérte azt a végső formáját, ami már kompatibilis az adattárház ténytáblájával. Ekkor nincs más művelet hátra, mint beírni azt a megfelelő táblába. Ez a dimenziótábláknál ismertetettel teljesen azonos elven történik.
22
14. ábra - A ténytábla feltöltése az ERP adatbázisából
23
3.6. Az OLAP kocka felépítése Miután az adattárház struktúráját kialakítottam és megtöltöttem azt az elemzéshez szükséges adatokkal a következő lépés az volt, hogy az adatokat olyan módon kell összefogni, hogy abból elemzéseket lehessen készíteni. Mivel elemzőeszköznek Excelt választottam, ezért adott volt a lehetőség, hogy a kockát Analysis Service projektként hozom létre Visual Studio-ban, mert az mind Excel-ben, mind pedig az SQL Serveren támogatva van. Analysis projektben is először adatkapcsolatot kell létrehozni a forrásként használni kívánt adatbázissal. Ez hasonló módon történik az ETL-nél megismerthez, vagyis itt is létrejön egy konnektor objektum a projekt és az adatbázis között. Ezen kapcsoló objektumon keresztül ezután létrehozhatunk egy nézet objektumot a projekthez, melyben az adatbázis táblái között további kapcsolatokat, új kulcsokat hozhatunk létre, új attribútumokat származtathatunk már meglévőkből. Mindez azonban csak virtuális változás, csak ebben a projektben jön létre, a tényleges adatbázis nem módosul. Létrehoztuk a virtuális adatmodellünket, neki láthatunk a kocka felépítésének.
3.6.1. Dimenziók definiálása A kocka építése előtt azonban definiálni kellett még azokat a dimenziókat, melyek szerint az adatok elemezhetők, csoportosíthatók lesznek majd. A dimenziókat varázslóval hoztam létre. Ehhez meg kellett adni, hogy melyik tábla alapján akarom elkészíteni, a tábla mely mérőszámait akarom felhasználni, illetve azt is, hogy melyik tábla adatain értelmezett az a dimenzió. Ez utóbbit minden dimenzió esetében az adattárház ténytáblájára állítottam. A varázsló végigkattintgatása után létrejövő formon tudtam beállítani azt egyes dimenziókban megjelenő objektumokat, azok hierarchiáját. A hierarchia létrehozásával keletkező hibaüzenetek megszüntetésére be kellett állítani a kapcsolatokat a hierarchiában résztvevő attribútumok között. Kialakított hierarchia
Attribútumok közti relációk
Kész dimenzió
3. táblázat - A kocka dimenzióinak létrehozásának lépései
24
3.6.2. Kocka építése A dimenziók elkészítése után futtatható a kockát elkészítő varázsló. Ebben lehetőségünk van beállítani, hogy mely táblákat kezelje ténytáblaként a rendszer, azokon milyen méréseket végezzen el, valamint mely dimenziókat rendelje hozzá. A varázsló lefuttatása után ismét egy formot kapunk, melynek első fülén a táblák közti kapcsolatok láthatók. A többi fülön van lehetőségünk beállítani új számított értékeket a kockára, a feliratokhoz, értékek nevéhez új fordításokat definiálni, illetve böngészni a kockában. Miután megépítettem a kockát, valamint beállítottam az aggregációk mentén az egyes mérések típusát, már csak telepíteni kellett a kockát egy adatbázis kiszolgálóra. Mivel mind a vállalatirányítási rendszer adatbázisa, mind az adattárház és ezekből kifolyólag a kocka is csupán tesztelési, fejlesztési céllal lett létrehozva, különösebb terhelésnek nincsenek kitéve, ezért úgy döntöttem, hogy mindet egy MS SQL Server példány fog kiszolgálni.
15. ábra - Az OLAP kocka „csillag” sémája
3.7. Adatbázis kezelő cseréje Az OLAP kocka adatbázisba való telepítése közben a következő hibaüzenetet kaptam: Errors related to feature availability and configuration: The 'Perspectives' feature is not included in the 'Standard Edition' SKU.
25
A hiba okának keresése közben hamar egyértelművé vált, hogy az csak XP SP3-nál jelentkezik. Tovább keresgélve, megtaláltam az SQL Server különböző kiadásait összehasonlító listában, hogy a Standard nem támogatja az Analysis Serices-t. Ezért MSDNAA-ról töltöttem le SQL Server Developer-t, és felkészültem az adatok migrálására. Próbálkoztam a régi adatbázisok többféle módon történő kiexportálására, de egyik sem hozta az általam elvárt eredményt, ezért azokról a fájlokról készítettem biztonsági másolatot, amelyekben az adatbázis el van tárolva. A régi verzió eltávolítása előtt megpróbáltam megoldani a problémát a telepítőbe épített kiadásfrissítési lehetőségekkel, azok azonban nem használtak, ezért az adatbázis kiszolgáló teljes törlése mellett döntöttem. Miután újra telepítettem és újra konfiguráltam a kiszolgálót, most már a Developer változatát, sikerült a kocka telepítése az adatbázisba. A kötelező újraindítás követően azonban ismételten hiba fogadott a kocka ismételt felépítésekor: Unable to connect to the Analysis server.
SQL Server Configuration Manager-rel megnézve a szolgáltatásokat, észrevettem, hogy nem indult el automatikusan az Analysis Service, ezért megpróbáltam kézzel elindítani, amire a következő hibaüzenetet kaptam válaszul: The request failed or the service did not respond in a timely fashion. Consult the event log or other application error logs for details.
Rövid keresgélés után rájöttem, hogy ez a hiba szintén XP-n jelenik csak meg. A megoldás megtalálásához viszont már sokkal több idő kellett, mire egy fórumon ráleltem: Ki kell törölni minden bejegyzést a rendszernapló alkalmazások csoportjából. Mióta kitöröltem a naplóbejegyzéseket ismét hibátlanul tudom használni a szolgáltatást.
3.8. Ár kialakítása Excel 2010-ben Miután sikerült visszaírni a kockát az adatbázis kiszolgálóra, annak tartalma könnyedén elérhető Excelből, csak adatforrást kell definiálni hozzá. Az adatforrást az Adatok/Egyéb forrásból/Az Analysis Services szolgáltatásból útvonalon lehet létrehozni az adatbázis szerverre való bejelentkezés után a kocka kiválasztásával. Ezután a baloldalon megjelenő Kimutatás mezőlista menüből drag&drop lehet összerakni a különböző jelentéseket, diagramokat. A jelentésekből a felhasználó tetszőleges szisztéma szerint kialakíthatja az elképzeléseihez leginkább igazodó árakat, akciókat. Az általam megvalósított egyéni árképzés szintén Excelben történik, kettő dimenzió mentén. Az árképzés során a vevőket és a termékeket használtam fel az árlisták megvalósításához, mint két független dimenziót. Az elemzés mérőszámaként ebben a konkrét implementációban a bizonylatokból kinyert összegeket használtam fel, de a feladat további részét úgy alakítottam ki, hogy e két dimenzió mentén tetszőleges mérőszám segítségével lehessen árlistát készíteni. Az elemzésben a dimenziókat nem egymásba ágyazva helyeztem el, hanem X és Y irányban, így az Excel által generált nézet egy mátrixként jelenik meg, melynek oszlopainak száma megegyezik a vevők számával és oszlopazonosítói a vevők cégneve. Hasonlóan a sorok száma megegyezik az ERP-ben definiált termékek számával, melyeket szintén a termék megnevezésével azonosítottam. A mátrix (i,j)-dik eleme az az összeg, amennyit az i-edik partnere fizetett a j-edik termékért összesen a vállalatnak. Ezen mátrixnak természetesen csak abban az esetben lesz feltöltve minden sora és oszlopa, ha az adattárházban szereplő minden vevő vásárolt már legalább egy darabot minden termékből. A minta vállalat adatbázisából emiatt egy erősen hiányos mátrix képezhető, azonban ennyi is elég a feladat végiggondolásához és megvalósításához.
26
16. ábra - Automatikusan generált diagram: Értékesített cikkmennyiség negyedéves bontásban
3.9. Egyéni ár, akciós ár meghatározása A kockából képzett ritka mátrixból sok tanulság leszűrhető az egyes termékekről vagy a vásárlóink szokásairól, arra azonban teljesen alkalmatlan, hogy belőle adat egyszerűen visszatölthető legyen a Navision-be. Az egyes vevőkre vonatkozó árak, kedvezmények felvétele ugyan lehetséges lenne a mátrixba is, azonban az arra vonatkozó egyéb paraméterek beállítása itt nem, vagy csak nehezen áttekinthető módon lenne kivitelezhető. Ennek kezelésére egy Visual Basic scriptet írtam, amely átalakítja a mátrixot olyan táblázatos formára, amiben az egyéni árak kialakításához szükséges minden paraméter egyszerűen megadható és azok könnyen áttekinthetők. Az így kialakított táblázatban szereplő oszlopok a vevők, az értékesített termékek, a kijelölt mérési eredmények, az adott vevőre vonatkozó sorkedvezmény százalékban kifejezve, a kedvezményes ár használatának időtartama és az a minimális rendelési mennyiség, amely felett a kedvezményes árra jogosul a vevő. A ritkamátrixot táblázattá átalakító kódrészlet a scriptből: ’A vevők összeszámolása a munkafüzet 2. sorában Do Until ExcelReader.Cells(2, intCustomerNumber) = "" intCustomerNumber = intCustomerNumber + 1 Loop ’A cikkek összeszámolása az első oszlopban Do Until ExcelReader.Cells(intItemNumber, 1) = "" intItemNumber = intItemNumber + 1 Loop ’... ’Egymásba ágyazott ciklusokkal végig pásztázom a ritka mátrixot és
27
’ha értékes elemet találok benne, akkor azt átmásolom a táblázatba For i=1 To intCustomerNumber For j=1 To intItemNumber If ExcelReader.cells(j+2, i+1).Value <> "" And ExcelReader.cells(j+2, i+1).Value <> "0" Then WrittenSheet.Cells(intRow, 1).Value = ExcelReader.Cells(2, i+1) WrittenSheet.Cells(intRow, 2).Value = ExcelReader.Cells(j+2, 1) WrittenSheet.Cells(intRow, 3).Value = ExcelReader.cells(j+2, i+1) intRow = intRow + 1 End if Next Next
A táblázat előre kitöltött részeit létrehozó kódrészlet: ’Kitöltendő oszlpok nevének kitöltése, megjelölésként WrittenSheet.Cells(1, 1).Value = "Vevők" WrittenSheet.Cells(1, 2).Value = "Termékek" WrittenSheet.Cells(1, 3).Value = ExcelReader.Cells(1, 1) WrittenSheet.Cells(1, 4).Value = "Kezdési dátum" WrittenSheet.Cells(1, 5).Value = "Befejezési dátum" WrittenSheet.Cells(1, 6).Value = "Minimális rendelési mennyiség" WrittenSheet.Cells(1, 7).Value = "Sorengedmény %"
4. táblázat - A VB Script által generált táblázat részlete
Ezen oszlopok közül az időszakot, a minimális rendelési mennyiséget és a sorengedmény százalékos értékét a felhasználónak kell meghatároznia. Az így elkészített táblázatos forma már nem tartalmazza azokat az elemeit a mátrixnak, ahol az nem tartalmazott értéket. Emellett a táblázat visszatöltése az adatbázisba sokkal egyszerűbben algoritmizálható is. A táblázat feltöltését, ezzel a vásárlói engedmények megállapítását Excelben végeztem el, ezzel egyúttal teszteltem a kialakuló megoldásom, hogy az ténylegesen képes-e nyújtani az elvárt működést. Az átláthatóság kedvéért minden sorban a kezdési és befejezési dátum, valamint a minimális rendelési mennyiség mezőket azonosra állítottam. Természetesen ez nem kötelező a későbbiek során. A feladat megoldás során a következő adatokkal töltöttem fel az Excel táblát: Kezdési dátum: 2008.01.15. Befejezési dátum: 2008.02.10. Minimális rendelési mennyiség: 100 db. A sorengedmény meghatározása során törekedtem azoknak a bonyolult szabályoknak a követésére, amelyek alapján a valós életben a kedvezmény megállapításra kerül, csupán egy egyszerű képlet alapján számolom azt (1. képlet). Természetesen a felhasználó tetszőleges bonyolultságú, az Excelben megvalósítható képletet találhat ki az engedmény meghatározására. 1. képlet – A sorengedmény % kiszámítása
28
Ahhoz, hogy az így meghatározott árlistát is felhasználja a Navision a bizonylat felvételénél a fizetendő ár meghatározására, annak tartalmát vissza kell tölteni az adatbázisba. Ehhez meg kellett határoznom az adatok exportálásakor ismertetett módon, hogy melyik adatbázistáblában tárolja az ERP ezeket az adatokat. A dolgozat témáját képző feladat megoldásához nem maradt más hátra, minthogy vissza kell töltenem az adatokat a Sales Discount Line táblába. Ehhez egy az adatok adattárházba való betöltése során használt ETL folyamatokhoz hasonlót készítettem el ismét, melynek adat forrásként a már egy marketing szakember által módosított Excel táblát adtam meg, valamint a betöltéshez szükséges egyéb kapcsolótáblákat. Az ETL modul adatfolyam diagramját a 17. ábra szemlélteti.
17. ábra - Az egyéni árlistát visszatöltő ETL process adatfolyam diagramja
29
Ahhoz, hogy a fentiekben elkészített munkafüzetet vissza tudjam tölteni a vállalatirányítási rendszer adatbázisának megfelelő táblájába, hozzá kell csatolni a constraint-ek kielégítéséhez szükséges külső kulcsokat. A cikkek azonosítóját a kocka cikk dimenzió táblájából csatoltam hozzá, a vevő azonosítót pedig a vevő dimenzióból. Van még néhány kulcs, amit fel kellett vennem, de ezek e feladatban statikusak, ezért nem csatoltam őket hozzá az adatfolyamhoz, hanem csak beállítottam azok értékét statikusan. Egy újabb join számításigényes művelet, és már így is van jó pár a process-ben, valamint értékük nem változhat, mert az a fizikai valóságot sértené meg. Például mindig csak a vevő jellegű partnereinknek tudunk kedvezményeket adni, a szállítóktól legfeljebb csak kaphatunk kedvezményt, de velük úgysem foglalkoztam a feladatom során. Végül hozzácsatoltam az ERP cikkekre vonatkozó törzsadatokat tároló táblájából még hozzácsatoltam a mennyiség mértékegységét. Miután minden kényszert kialakít az adatfolyam, nincs más feladat hátra, be kell írni azt a megfelelő táblába. Az adatbázis műveletek optimalizálása érdekében kiszűrtem a ritka mátrix azon sorait, amiben nincs érték már a táblázattá alakítás során, most pedig betöltés előtt szűröm ki azon rekordokat az adatfolyamból, amelyekben a kedvezmény mértéke 0%. Ezek tárolása értelmetlen és felesleges az adatbázisban, illetve ha mégis megtörténik, akkor teljesítményromlást okozhat a Navision futásában is, hiszen minden új bizonylat felvételénél az ár meghatározásakor több látszólagosan „kedvezményes” árból kellene kiválasztani a minimálist, amire ezen adatok semmilyen hatással sincsenek. Az elemzés eredményének az ERP adatbázisába történő visszatöltésével bezárult a 1. ábrán felvázolt kör. Ez azt jelenti, hogy a vállalatirányítási rendszer árlistái már tartalmazzák a felhasználó által meghatározott egyéni kedvezményeket, árakat, vagyis mindig, ha ezután új bizonylatot vesz fel valaki a rendszerben, akkor annak létrehozásakor a rendszer már figyelembe veszi a most beállított új kedvezményeket is.
5. táblázat - A kedvezmény automatikus érvényesítése bizonylat készítésekor
4. Az elkészített implementáció üzleti jelentősége Az általam elvégzett feladat jelentős részét meg lehetett volna oldani a Microsoft Dynamics NAV-on belül is. Árlisták definiálására, kedvezmények megadására természetesen ott is van lehetőség. Arra a döntésre, hogy a feladatot az adatok külső adattárházba exportálásával oldjam meg az vezetett, hogy az így elkészített megoldás sokkal dinamikusabb, mintha az ERP-n belül oldottam volna meg a feladatot. Vegyünk például egy multinacionális vállalatot, amelynek több országban is jelen van leányvállalata. Ebben az esetben közös ERP-t nem, vagy csak nehezen használhatnának, hiszen, pl. országonként más és más számviteli törvényeknek kellene megfelelniük. Ezért saját ERP-ben tárolják a tranzakciós adataikat. A vállalati adatok elosztott kezelése egyszerűbben konfigurálhatóvá és üzemeltethetővé teszi a vállalatirányítási rendszereket, ugyanakkor az adatok centrális tárolásának hiánya nehézkessé teszi mind az elemzést, mind az anyavállalat közös árképzési politikájának meghatározását. Erre a problémára nyújtottam egy megoldást a dolgozatom során, ahol meghagytam a lehetőséget arra, hogy a vállalat egyes divíziói saját vállalatirányítási rend-
30
szereket üzemeltethessenek úgy, hogy a cégvezetés stratégiailag fontos döntéseihez szükséges adatokat újragondolt struktúrában, egy központi adattárházban is eltároltam. Fontos észrevenni, hogy a feladat nem követeli meg azt sem, hogy az egyes leányvállalatok azonos vállalatirányítási rendszereket használjanak, így különösen kedvező megoldásként szolgál több cég egyesítésére is. Önálló laboratóriumi munkám során biztosítottam a lehetőséget az ERP-k egymástól minél függetlenebb implementációjára a centrális, dinamikus árpolitika lehetőségének biztosítása mellett.
31
5. Irodalomjegyzék [1] Gajdos, S. (1999). Adatbázisok. Budapest: Műegyetemi Kiadó. [2] Hámori, B., & Szabó, K. (2006). Információgazdaság. Budapest: Akadémiai Kiadó. [3] Lohndorf-Larsen, L. (2008. november 5). Basic SQL - Creating Extended Stored Procedure / xp_ndo.dll. Letöltés dátuma: 2011. március 10, forrás: Nav developer's blog: http://blogs.msdn.com/b/nav_developer/archive/2008/11/05/basic-sqlcreating-extended-stored-procedure-xp-ndo-dll.aspx [4] Robert J. Dolan, & Hermann Simon. (2000). Árképzés okosan. Budapest: Geomédia Szakkönyvek. [5] Sildó, C. (2004. augusztus). Adattárház összefoglaló. Letöltés dátuma: 2011. április 25., forrás: Adattárház összefoglaló: http://scs.web.elte.hu/Work/DW/adattarhazak.htm [6] social.msdn.microsoft.com. (dátum nélk.). Letöltés dátuma: 2011. május 5., forrás: MSDN fórum: social.msdn.microsoft.com [7] SSIS Tutorial: Creating a Simple ETL Package. (dátum nélk.). Letöltés dátuma: 2011. május 5., forrás: Microsoft Developer Network: http://msdn.microsoft.com/enus/library/ms169917(v=sql.90).aspx [8] Whitehorn, M., & Burns, K. (2008. július). Best Practices for Data Warehousing with SQL Server 2008. Letöltés dátuma: 2011. május 5., forrás: Microsoft Developer Network: http://msdn.microsoft.com/en-us/library/cc719165(v=sql.100).aspx
6. Táblázatjegyzék 1. táblázat - Árazási mechanizmusok és az árazást befolyásoló tényezők a statikus és a dinamikus árazású piacokon. ...................................................................................................... 5 2. táblázat - Az idő dimenzió paramétereit tartalmazó Excel tábla részlete ............................. 20 3. táblázat - A kocka dimenzióinak létrehozásának lépései ..................................................... 24 4. táblázat - A VB Script által generált táblázat részlete .......................................................... 28 5. táblázat - A kedvezmény automatikus érvényesítése bizonylat készítésekor....................... 30
7. Képletjegyzék 1. képlet – A sorengedmény % kiszámítása ............................................................................. 28
8. Ábrajegyzék 1. ábra – Az elvégzett részfeladatok ........................................................................................... 4 2. ábra – A profitnégyzet a hozzá tartozó háromszögekkel ........................................................ 7 3. ábra – Több ár meghatározása ................................................................................................ 7 4. ábra – Csillagséma ER diagramja ........................................................................................... 9 5. ábra – Hópihe séma ER diagramja ....................................................................................... 10 6. ábra – Értékesítési OLAP kocka 3 dimenziós reprezentációja ............................................. 11 7. ábra – Üzleti folyamatok egymásra épülése a Microsoft Dynamics NAV-ban ................... 12 8. ábra - A CRM és az ERP kapcsolata az áralkotásban .......................................................... 13
32
9. ábra - A Navision fejléce ...................................................................................................... 14 10. ábra - A számla általános felépítése ................................................................................... 15 11. ábra - Az elkészített ETL folyamat state-chart-ja ............................................................... 19 12. ábra - Egyszerű adatfolyam ................................................................................................ 20 13. ábra - A földrajzi elhelyezkedés tábla feltöltése ................................................................. 21 14. ábra - A ténytábla feltöltése az ERP adatbázisából ............................................................ 23 15. ábra - Az OLAP kocka „csillag” sémája ............................................................................ 25 16. ábra - Automatikusan generált diagram: Értékesített cikkmennyiség negyedéves bontásban .................................................................................................................................. 27 18. ábra - Az egyéni árlistát visszatöltő ETL process adatfolyam diagramja .......................... 29
33
