2 of 14

GRAPHISOFT

HQ – Budapest

Leányvállalatok:

Boston
Hong Kong
London
Madrid
Mexico city
München
Tokyo

Bevezetésképpen pár szó a GRAPHISOFT-ról:

A magyar alapítású GRAPHISOFT (1984) az épületinformációs modellezés (Building Information Modeling – BIM) egyik első kifejlesztője, az iparág egyik vezető vállalata.

Az Egyesült Államokban, Mexikóban, Németországban, Nagy-Britanniában, Spanyolországban, Japánban és Hong Kongban rendelkezik leányvállalattal, az értékesítési hálózat a világ több mint 100 országára terjed ki.

A GRAPHISOFT központja Budapesten van, 2007 óta a német Nemetschek-csoport tagja.

A vállalat a bevételeinek 98 százalékát magyar szellemi termékek exportjával éri el.

Az Üzleti intelligencia rendszer tervezését 2012 elején kezdtük, és nagyságrendileg 1000 embernapba és másfél évbe került, hogy most erről beszélhessek.

3 of 14

Tartalom

GRAPHISOFT BI áttekintés
BI bevezetés okai
Üzleti döntések és buktatók
Technológiai döntések és buktatók
Bevezetés után

4 of 14

Forrásrendszerek

5 of 14

Architektúra

Miből áll a GRAPHISOFT BI:

Adattárház architektúra

Adattárházhoz egy klasszikus 3 rétegű (stage, transzformációs réteg, csillagsémás adattárház) architektúrát választottunk a tetején OLAP adatkockákkal. A célunk az volt , hogy egy magas fokon standardizált, könnyen és olcsón üzemeltethető, egyszerűen bővíthető adattárház architektúrát kapjunk.

BI architektúra

Az adattárház fölött futó OLAP adatbázis lekérdezhető Excelből is és webes felületen keresztül is. Míg az üzleti elemzők, kontrollerek elsősorban az Excel pivot tábláján keresztül vagy az Excel kocka függvényei segítségével kérdezik le az adattárház OLAP kockáit, addig a vezetők, értékesítési menedzserek, partnerek az interaktív riportokat a vállalati intraneten, böngészőn keresztül használják.

BI portál

Az adattárház felépítésével párhuzamosan a vállalati intraneten kialakítottunk egy BI portált.

A portál elsődleges célja, hogy egy közös helyen kezeljük a az elkészült riportokat, a riportokhoz szükséges adatkapcsolati fájlokat, felhasználói manuálokat és dokumentációt.

A webes riportokat az üzleti felhasználók saját maguk, IT támogatás nélkül készítik és publikálják a BI portálra.

A BI portálon kapott helyet a mutatószámainkat, üzleti fogalmainkat egységesen definiáló „BI Wiki” is.

6 of 14

BI Bevezetés

Előzmények: új ERP bevezetés

Integrált, de nehezen riportálható

→ BI

Egységes adattárház
Közvetlen adatelérés, önkiszolgálás
Egyszerű riportkészítés
Automatikus és gyors adatfrissítés
Vállalati Intraneten

Előzmények: - új ERP bevezetés

2011-ben új vállalatirányítási rendszer került bevezetésre, a régi rendszer nem volt továbbfejleszthető, nem volt megfelelően integrálható az eladási folyamatainkba, így útját álta a további növekedésnek.

Az új rendszerrel szemben támasztott elvárás volt, hogy integráltságából következően könnyebben lekérdezhetővé válnak az adatok a beépített riportokkal.

Az elvárásokkal ellentétben kiderült, hogy a riportok karbantartása, új riportok gyártása költséges, a riportok lefutása idegtépően lassú, és a beépített riportok csak arra megfelelőek, hogy adatokat exportáljunk ki excelbe és ott folytassuk az elemzést. Az így készült riportok ráadásul mindig offline riportok maradtak, frissítésük külön feladatot jelentett.

→ BI

Egyértelművé vált, hogy szükség van egy hatékonyabb rendszerre: nem riportokra a vállalatirányítási rendszerből, hanem olyan adattárházra, amelyből saját magunk, önkiszolgáló módon tudunk elemzéseket, készíteni.

Az időközbeni vállalati intranet bevezetéssel követelménnyé vált, hogy az elkészült riportoknak azon keresztül megoszthatóak legyenek és automatikusan frissüljenek.

7 of 14

Üzleti döntések

Eszköz kiválasztás

Eszköz kiválasztás:

A BI bevezetést érintő első jelentős üzleti döntés a megfelelő eszköz kiválasztása volt.

A vállalatirányítási rendszer bevezető partnerünk egy integrált dobozos terméket a Targit-ot javasolta, de a ERP-n végrehajtott testreszabás miatt itt is jelentős fejlesztési költségekkel kellett volna számoljunk, valamint az átadott rendszert nem tudtuk volna csak saját erőforrásból üzemeltetni, továbbfejleszteni, így ezt elvetettük.

Microsoft-os megoldásokat más fejlesztési területeken is használtunk már eddig is, így került előtérbe az MS BI. A kiértékelésnél Gartner tanulmányt, MS odalról elérhető esettanulmányokat és technikai leírásokat vettünk figyelembe. Ezek mindegyike megerősített minket benne, hogy egy kellőképpen flexibilis, piacvezető megoldással állunk szemben. Ráadásként kiderült, hogy a jelenlegi liceszállományunk bővítése sem szükséges, gyakorlatilag már birtokában voltunk az eszköznek.

8 of 14

Üzleti döntések

Erőforrás

Kizárólag belső erőforrás

Dobozos tanfolyam: SSAS

→Coaching:

Tanácsadás
Igényre szabott tanfolyamok

BI project management
Excel riportok

Job shadowing / On-the-Job training

SSIS, SSAS

Az eszköz kiválasztása után jött a neheze, bele kellett tanuljunk. Az kizárolagos kiszervezés lehetősége fel sem merült, az új rendszert magunk akartuk felépíteni, üzemeltetni és továbbfejleszteni.

El is mentünk egy 3 napos MS Analyis oktatásra (SQL Server 2008 R2 AS), aminek a végén lett tiszta számunkra, hogy nem csak az eszközt kell megismerjük:

Tisztában kell lennünk a BI terület jellemzőivel, egy ilyen project sajátosságaival és szükséges, hogy rendelkezzünk a megfelelő gyakorlati tapasztalatokkal.

Éppen ezért kerestünk egy tanácsadót, aki vállalta, hogy segít nekünk összerakni a project tervet, és a megvalósítás minden lépésében vezet minket.

Szerencsénkre hamar megtaláltuk a megfelelő szakértőt Kővári Attila személyében.

A Coaching tapasztalatokról csak pozitívan tudok nyilatkozni, az igényre szabott tanfolyamok illetve Job shadowing / On-the-Job training gyakorlat véleményem szerint a leghatékonyabb módja az ismeretek átadásának, nekünk pedig volt mit tanuljunk. A technológiák megismerése és az első inkrementumok elkészülte után egyre inkább csökkent a Coaching szerepe, a bevont külső segítség (konzultáció , oktatás és fejlesztés) a teljes projectre vetítve 10% alatt maradt.

------------------

~1000 manday

Development: 600 manday

BI Developers: 540 manday

Outsource: 60 manday

Management, Consultation, Training: 200 manday

Controlling (Business + Finance): 135 manday

Project Management: 50 manday

Outsource: 15 manday

Data Cleaning, Reporting: 200 manday

Business Controlling: 200 manday

Erőforrás:

Coaching +:

technológiai alternatívák között szakértő vélemény dönt az igények mentén

az átadott rendszer külső erőforrás nélkül üzemeltethető tovább

agilisan tud reagálni a követelmények változására

az átadott rendszer pontosan lefedi a szükségletet

megértés és döntés támogatás

Coaching -:

a tanulási görbe hatással van a kezdeti scope-okra, az esetleges buktatók határidő csúszást eredményeznek

lazább scope értelmezés, üzleti oldalról állandóan bővült

a belső erőforrásokat magasabb prioritású feladatok elvonhatják a projectről

nem érvényesíthető a határidő csúszás, rendelkezésre állás, garancia (hibás döntések)

Outsource +:

határidő vállalás

követelmények kőbe vannak vésve, tiszta scope

rövidebb fejlesztési periódus , saját megoldás leszállítása

Outsource -:

üzemeltetési szerepkörök házon kívül maradnak

további fejlesztésekhez újra outsource bevonásra lesz szükség

üzleti követelmények megértése nehézkes, üzleti oldal konzultációs ideje nem spórolható meg

az alkalmazott technológia korlátozódik az outsource partner megoldásaira

nem érdekelt a technológiai tudás átadásában

megértés vagy fejlesztés, együtt a kettő ritkán

Konklúzió:

első fázis valamint teljesen új területek/technológiák bevezetésekor Coaching módszer vált be

későbbi fázisoknál csökken a Coaching szerepe, a technológiák megismerése után az fejlesztési erőforrás válik a szűk keresztmetszetté

9 of 14

Üzleti döntések

Terület és Scope

Értékesítés

Első fázis (eredeti / bővített scope)

HQ Eladások
HQ Kiszállítások
GS Group Eladások (HQ + Leányvállalatok)
Eredmény Kategóriák
Terv Árfolyamok
Tervek
Előrejelzések
Intranet Integráció
Új Field List
Leányvállalati Adatkockák

A terület kiválasztásában már a szakértő segített nekünk:

Mi eredetileg a kintlevőségek elemzését akartuk megoldani, de ha már nekiálltunk, akkor csináljunk egy normális BI-t, és ha már BI, akkor üzleti igényfelmérés, amiből már az jött, hogy az első terület legyen az értékesítés, mert ez a legtöbb felhasználót érintő terület és ennél van legnagyobb szükség napi szintű elemzésre.

Scope:

A scope-ot próbáltuk minél kisebbre venni – legyen kevesebb, mint 3 hónap - , de a business oldal folyamatosan tágította:

Az HQ számlázott eladások átadásakor jött az üzleti oldal, hogy nekik ez így még nem sokat jelent, mert csak hetente számlázunk, szükségük van a már kiszállított de még nem számlázott eladásokra is. Majd miután ezt megkapták kiderült, hogy a leányvállalati eladások nélkül ez fabatkát sem ér. Miután konszolidáltan megkapták az egész cégcsoportbeli eladásokat, jöttek azzal, hogy nem megfelelőek az eredmény kategóriák, illetve, hogy miért nem terv árfolyamon számolunk. És mire odértünk, hogy miért nem látják mellette a terveket, előrejelzéseket.

Tehát a scope folyamatosan bővült, amíg el nem ért egy ténylegesen használható szintet, ami már nem csak a riportálást, hanem a tervezést is szolgálta.

10 of 14

Üzleti buktatók

Közös nyelv:

BI szakszavak
BI Wiki: mutatószámok, üzleti fogalmak

Excel, pivot tábla:

Tanfolyam

Adatgazdák:

Terület és Felelősség

Bizalom

Közös nyelv

A közös nyelv alapjait minél hamarabb tisztázni kell,

Egyrészt a közös nyelvnek a részévé kell hogy válljanak az újonnan megismert BI szakszavak is, úgy mint pl. pivo tábla, filed list, hierarchia, lefúrás, átfúrás, dimenzió, measure, set, adattárház, adatkocka, perspektíva, etc., hogy ezek használatával tudjunk kommunikálni a felhasználókkal.

Másrészt üzleti oldalon is ki kell alakuljon ez elnevezések egységessége, a measure-ök, KPI-ok tisztázásához.

Sajnos ez lassú folyamat, és mi bele is futottunk: Egy management tanfolyamot követően a már elkészült, részben átadott adatkockákon kellett átnevezéseket végrehajtsunk, ami együtt járt a riportok újragyártásával is.

Ahhoz, hogy ezeket kezeljük, a BI portálon kapott helyet a mutatószámainkat, üzleti fogalmainkat egységesen definiáló „BI Wiki”, amelyből pl. mindenki számára egyérteműen kiderül, hogy hogyan számoljuk és mit is értünk pontosan az „új vevő” fogalmán.

Pivo tábla

Excel / pivot tábla ismeret hiánya nemcsak a felhasznlálóknál, de még a projeck tagoknál is okozott gondot, ezeket a hiányosságokat több szintű riportkészítési tanfolyamokkal foltoztuk.

Adatgazdák:

A forrásrendszerek minden adatának kell, hogy legyen tulajdonosa, és hogy ki mért felel, legyen mindenkinek világos.

Enélkül elveszik az adatokba/riportokba vetett bizalom.

Főleg a projekt kezdeti szakaszaiban nem volt mindig tiszta, hogy egy adott vagy új területnek ki a felelőse, illetve a felelős nem volt tisztában a hogy az adatok karbantartása milyen fontosággal bír.

Ki kell jelölni területenkénti adatgazdákat és tisztázni kell a felelősségüket a projectben:

Bizalom

A biztalom kérdése nagyon fontos, és ebben a BI mint új rendszer eleve hátrányból indult.

Ezt csak sok munkával lehetett ledolgozni, és sajnos az elején még rajtunk is érződött a tapasztalat hiánya.

Hogy egy példát említsek: a kezdeti szakaszban az egyes inkrementumok validálásakor a kulcs felhasználók annyival jobban bíztak a vállalatirányítási rendszerben, hogy a BI elemzés során tapasztalt hibákat/eltéréseket egyből visszadobták azzal, hogy rossz a BI.

Idővel ezek egyre gyakrabban forrásrendszerbeli adathibákra lettek visszavezethetőek, de eleinte még mi magunk is a BI-ban kerestük a hibát és amikor már egyáltalán nem találtuk, csak akkor mentünk vissza a forrásrendszerig.

11 of 14

Technológiai döntések

SQL szerver

2008 R2 vs. 2012 → SSIS, MDS

Adatmodell

OLAP vs. Tabular → Visszaírás

Törzsadat kezelés

Excel vs. MDS → Jogosultság kezelés

Leányvállalati adatok importja

Excel vs. MDS → Adatellenőrzés

SQL server: 2008 R2 vs. 2012

2012 elején a már elkezdtük a fejlesztési környezet kialakítását 2008 R2-es környezetben, amikor megjelent a 2012-es.

Gyorsan kellett döntenünk, hogy bevállaljuk-e az áttéréssel járó esetleges csúszást, vagy inkább maradunk a korábbi verziónál.

Az áttérés melleti legfőbb érvek

1. Ne ragadjunk le eleve egy verzióval
2. SSIS paraméterek – egységes csomagok kialakításának lehetősége az azonos típusú forrásrendszerrel rendelkező leányvállalatoknál
3. Használható MDS a csomagban

Adatmodell

OLAP vs. Tabular

OLAP - nagyobb támogatottság
Tabular: sok az ismeretlen
plan/forecast tények karbantartása: Excel vs. MDS vs Olap Write Back

Törzsadatkezelés:

Kellett találjunk egy egyságes kezelési felületet azoknak az adatainknak, amik a vállalatirányítási rendszerből nem kinyerhetőek, illetve ott nem kezelhetőek.

Ilyenek pl. a vállalatirányítási rendszer által használt kód-megnevezés párok egy része, a terv átváltási árfolyamaink, illetve a hiererchiáink.

Célül tűztük ki, hogy ezeket az adatgazdák IT segítség nélkül tudják karbantartani, és az adatok frissítés után automatikusan kerüljenek be az adattárházba.

Ehhez az SQL Server Törzsadatkezelőjét és a hozzá tartozó Excel add-ont vettük használatba.

Leányvállalati adatok importálása

A nem integrált vállalatirányítási rendszert használó leányvállalatok eladási adatainak importálására is több lehetőség is adott.

Azzal tisztában voltunk, hogy valamilyen szintű automatikus adattisztítást, validálást is végeznünk kell ezeken, és mivel ekkorra már kiismertük az MDS lehetőségeit úgy döntöttük azzal valósítjuk meg.

Az MDS-ben üzleti szabályokat hoztunk létre és csak a frissített adatok közül csak a validáltak kerülnek az adattárházba.

12 of 14

Technológiai buktatók

Új technológia

Üzemeltetés

Szakértő hiány

BI elérés - Excel

Lányvállalatok
OSX OLAP support

A project indulásakor felmértük, hogy milyen technológiai kockázatokkal kell számoljunk.

Tudtuk, hogy meg bele kell tanulnunk egy teljesen új területbe és ez eleinte még lassítani fogja az előrejutást, de azzal nem számoltunk, hogy az új technológiával kapcsolatosan üzemeltetési problémákba is belefutunk:

Új technológia:

Üzemeltetési gondok: job-ok lefutása akadozott: Memória és tárhely foglalási beállítások, megmagyarázhatatlan sikertelen betöltések

Bug-ok és folyamatos frissítések

SQL Server 2012 + SP1

volt hogy ez egyik release közben meg kellett álnunk szervízcsomagot frissíteni az éles szerveren, mert olyan funkciót használtunk a fejlesztői környezetben, ami arra épült.

Szakértő hiány

Nem gondoltunk rá, hogy az SQL Server-nek lesz olyan része, amihez nem találunk szakértőt itthon

- MDS: nem volt elérhető szakértő, autodidakta módon tanultunk bele, a tapasztalat hiánya miatt elég döcögősen haladtunk

Story: MDS szakértő keresése – Kővári – xy - Kővári

- Sharepoint integrálás: külön szakértő bevonása vált szükségessé

BI elérés – Excel:

És persze nekünk sem mindenre sikerült találni megoldást, továbbra is gondban vagyunk a

Leányvállalati excel elérés: VPN konfogurálás, trusted domain – AD authentikálás

natív MAC/iPad support: Citrix Desktop, Citrix Receiver

---------------------------

Kódlapok:

lokalizált karakterek használata: forrásrendszerenként eltérő kódlapok

garbage karakterek a japán szöveges mezőkben

13 of 14

Bevezetés után

Stabil BI rendszer

Bizalom:

Adatminőség
Elérhetőség

Használat:

Tanfolyam

→ Támogatás, kulcs felhasználók

Terjesztés:

→ Elkötelezettség

→ Kommunikáció

Bizalom:

A másfél éves bevezetés végén most úgy állunk, hogy van egy megbízható, elérhető, egyértelmű eladási adatokat szolgáltató riportálásra és tervezésre alkalmas rendszerünk, és ami a legfontosabb, hogy nemcsak mi gondoljuk így, a felhasználóink is. Ezt bizalmat meg is kell őrizni, ezért elsődleges feladatunk a rendszer folyamatos monitorozása, és az adatok minőségének ellenőrzése.

Használat:

Ahhoz, hogy a befeketés minnél jobban megtérüljön, rá kell venni a felhasználókat, hogy használják és egyre szélesebb körben kell kialakítani a felhasználási lehetőségeket.

El kell érnünk, hogy a felhasználók magabiztosan használják, tréningelni kell őket: mi területenkénti és leányvállalatonkénti tréningeket és follow-up tréningeket szervezünk.

A tréningek során a felhasználók tisztába kell kerüljenek a rendszer alapvető működésével, honnan jönnek az adatok, és milyen gyakorisággal frissülnek, hogyan tudják elérni, és használni.

A nagyságrendileg 50 felhasználóból leányvállalatonként egy-egy kulcs felhasználót képzünk ki, hogy az a leányválalati kéréseknek helyben eleget tudjunk tenni, ne kelljen adott esetben fél napot várni az eltérő időzónák miatt a segítségre.

Terjesztés:

Fontos, a project szponzorok és project tagok elkötelezettsége.

Egy nagyon jó példa, hogy a pénzügyi és operatív igazgatónk legutóbbi leányvállalatokat érintő útja során személyesen kért visszajelzéseket a rendszerről és tesztelte az elérhetőséget.

Egy másik példa, hogy vezérigazgatónk kötelező tanfolyamot hírdetett a management-nek, illetve külön kért személyes follow-up tréninget.

Az elkötelezettség felé tett fontos lépés, hogy 2014-től kezdődően csak a BI-ból készített jelentéseket fogadunk el terv/tény eladások területről.

--------------------------

Exceed ROI:

More users

Expert users

From more department (finance, sales operation, marketing, business development)

Monitoring, Operation:

Data Quality

Response Time

Usage

1 of 14

2 of 14

3 of 14

4 of 14

5 of 14

6 of 14

7 of 14

8 of 14

9 of 14

10 of 14

11 of 14

12 of 14

13 of 14

14 of 14