Quantcast
Channel: Excel
Viewing all 129 articles
Browse latest View live

PowerPivot memóriahasználatának optimalizálása 2

$
0
0

Írtam már korábban a PowerPivot memóriahasználatának optimalizálásáról, és ezt a most 2 újabb ponttal egészítettem ki.

A PowerPivot memóriafogyasztását csökkenthetjük, ha szétvágjuk a sok különböző értéket tartalmazó oszlopot több, kevesebb különböző elemet tartalmazó oszlopra. Példák:

  • Idő oszlopok (óra:perc:másodperc) szétbontása Óra, Perc, Másodperc oszlopokra
  • Értékesítés Ft oszlop helyett a Mennyiség és az egységár oszlopokat olvassuk be.

Az ötletet a Optimize memory in PowerPivot and SSAS tabular című cikk adta

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2013. szeptember 24.-i Önkiszolgáló BI workshopra. Részletek >>

  

Bookmark and Share

Case Sensitive adattárházak problémái

$
0
0

A kis és a nagybetű megkülönböztetése adattárház vagy döntéstámogató rendszer oldalon nem túl szerencsés. (finoman fogalmazva) Nagyon sok hibalehetőséget hordoz magában és sok esetben a riportkészítő eszközök sem támogatják a kis és nagybetű megkülönböztetését.

Ha case sensitive (kis- és nagybetűt megkülönböztető) az adattárház, akkor az abból táplálkozó OLAP adatbázisnak, és az OLAP adatbázisból riportkészítő eszközöknek is case sensitive-nek kell lennie.

Csakhogy amíg ez az OLAP adatbázis oldalon nem gond addig a riportkészítők esetében már az. Itt van példának az Excel

Az Excel kis- és nagybetű érzékenység szempontjából egy különös faj. Különös, mert néha megkülönbözteti a kis- és nagybetűket, néha nem. Ha például OLAP adatbázist kérdezünk le vele a Pivot táblán keresztül, és az OLAP oldalon a számformátumot 'PERCENT'-ként definiáljuk, akkor a Pivot tábla nem fogja százalékos formátumban megjeleníteni az adott mutatót. Ugyanakkor a formázást 'Percent'-re állítjuk, akkor tökéletesen jól formáz a Pivot tábla.

A számformázási problémát megtanulja az ember és együtt tud vele élni. Azonban egy case sensitive adatbázisból dolgozni az Excellel szinte lehetetlen. Sem a Pivot tábla sem az Excel kocka függvényei nem birkóznak meg a kis- és nagybetűben különböző dimenzió elemekkel. Ugyanis sem a Pivot tábla, sem a kocka() függvények nem különböztetik meg a kis- és nagybetűket.

Tegyük fel hogy a forrás adatbázisunk kis- és nagybetű érzékeny (case sensitive) és van egy a1 és egy A1 nevű termékünk. Ha behúzzuk a termék dimenziót sorra, akkor az Excel kilistázza mind az a1, mind az A1 nevű terméket:

Case sensitive adatok megjelenítése a Pivot táblában

Mind a kettőt kisbetűvel. Szűrni már nem tudunk az a1 vagy az A1 termékre, mert a szűrőben vagy csupa nagybetűvel, vagy csupa kisbetűvel jeleníti meg az elemeket:

Case sensitive adatok a Pivot tábla szűrőjében

Csae sensitive adatok a Pivot tábla szűrőjében

Még rosszabb a helyzet a kocka függvényekkel. A kocka függvények használatával ugyanis nem tudjuk lekérdezni mindkét elemet. A

KOCKA.ÉRTÉK("KOCKA"; "[Termék].[Összes].[a1]", [Measures].[db])

és a

KOCKA.ÉRTÉK("KOCKA"; "[Termék].[Összes].[A1]", [Measures].[db])

Ugyanazt az eredményt adja. Ergo csak az egyik elemet tudjuk lekérdezni. A másikat nem.

Mi a megoldás?

Kerülni kell döntéstámogató rendszerekben a kis- és nagybetűk megkülönböztetését :-) Ha ez nem járható és OLAP-ot használunk (Analysis Services), akkor létre kell hoznunk egy olyan származtatott oszlopot, amely nem kis és nagybetűben teszi különbözővé (egyedivé) a terméket. Pl az a1-hez hozzárendeli az 1-es kódot, az A1-hez a 2-est és erre úgy építeni egy attribútumot, hogy annak kódoszlopa az így képzet kódoszlop lesz, a megnevezés oszlopa az a1-et és A1-et tartalmazó kód. Ebben az esetben a Pivot tábla is jól fog működni, és a kocka függvények is:

Case sensitive adatok az Excel pivo táblában

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2013. szeptember 24.-i Önkiszolgáló BI workshopra. Részletek >>

  

Bookmark and Share

Power BI

$
0
0

A Power BI első ránézésre a már korábban létező PowerPivot, Power View, GeoFlow és Data Explorer Excel bővítmények összecsomagolása egy termékbe, mindezt kiegészítve a megosztásra alkalmas webes BI portállal (BI Site) és a mobil BI elérhetőséggel.

Másképpen fogalmazva: A Power BI egy önkiszolgáló BI szoftvercsomag, melynek részét képezi egy önkiszolgáló ETL eszköz, néhány önkiszolgáló elemző és adatvizualizációs eszköz, a webes megosztást lehetővé tevő BI portál és a mobil elérhetőséget biztosító webes és vastagklienses megoldások.

Ára még nincs. Megjelenési dátuma sincs. Publikusan tesztelhető próbaverzió sem érhető még el. Épp ezért a cikk egyfajta első benyomás, esélylatolgatás arra vonatkozólag, hogy merre mehet majd a Microsoft BI.

A power BI megismerését kezdjük a réges-régóta várt Mobil BI lehetőségekkel. Ezen belül is a HTML 5 támogatással.

HTML 5

Miért fontos a HTML 5 támogatás? Mert a Silverlight-ot - amiben a Power View-val készített vizualizációk is futnak - nem minden böngésző támogatja. Így nem fut pl.: iPad-en sem. Hiába építünk egy gyönyörű webes riportot, ha azt nem tudjuk megnézni bármilyen eszközről, bármilyen böngészőben.

A HTML 5 támogatás része lesz a Power BI-nak. Nem tudni még milyen mélységben fogják átírni az adatvizualizációs Power View-t Silverlight-ról HTML 5-re, de a bemutatókból úgy fest, hogy az egész Power View át lesz írva HTML 5-re. És ennek örülünk :-)

De úgy fest, hogy a HTML 5 támogatás először csak a felhőben futó Office 365 részeként lesz elérhető. (ahogy valószínűleg a teljes Power BI szoftvercsomag is. De erről majd később)

A lokálisan telepített SharePoint marad Silverlight-on. Legalábbis a következő verzióig. Azaz, ha valaki akar majd egy minden böngészőben futó HTML 5 BI portált, akkor azt először a felhőben futó Office 365 „megvásárlásával" teheti meg. A lokálisan telepített SharePoint-ok továbbra is maradnak Silverlight-on. Egyelőre itt nem lesz HTML 5 támogatás...

„Cloud first" - ahogy mondja a Microsoft új stratégiája. És úgy fest ezt komolyan is gondolják.

Mi lehet a Microsoft a célja ezzel az „arccal a felhő felé" BI stratégiával? Ki lesz az új felhő alapú BI stratégia célpiaca?

A nagyvállalatok aligha. Ők lassan váltanak egy még egy újabb lokálisan telepített SharePoint verzióra is. A felhő BI szempontból nekik ismeretlen terület.

Lehet, hogy a mobil elérés lehetőségével át lehet őket csábítani a felhőbe illetve át lehet szoktatni őket egy felhőalapú BI megoldásra. De tömegesen nem hiszem, hogy váltanának. A nagyválallatok tehát valószínűleg maradnak a klasszikus, lokálisan futó, adattárház alapú BI megoldásoknál.

Ugyanakkor ott vannak a fiatal vállalkozások. Nem azt mondom, hogy kicsik, de a fiatal szóban benne van az is, hogy még nem olyan nagyok. Ok már felhőben nőttek fel. Nekik a felhő egy ismert terület. Nekik meghozni azt a döntést, hogy a BI egy része átvándoroljon a felhőbe nem olyan súlyos kérdés, mint a nagyvállalatoknak, hiszen sokuknál az alaprendszerek egy része is a felhőben fut.

Tehát a Microsoft célja ezzel a „Cloud first" stratégiával a BI területen valószínűleg az, hogy az office 365 fele terelje a vállalatokat, ahogy anno tette ezt a SharePointtal is. Excel riportokat akarsz a weben megjeleníteni? Vegyél SharePointot. Időzítve akarsz PowerPivot fájlokat frissíteni? Go to SharePoint. Mobil BI megoldást szeretnél? Irány a felhő és az Office 365.

Persze valószínű, hogy a lokálisan telepíthető SharePointba is átkerül majd a HTML 5 támogatás, de annak akinek MOST kell mobile BI, valószínűleg az Office 365 lesz az egyetlen járható út. Ez egyelőre feltételezés, de ha igaznak bizonyul, akkor ki kell hogy ábrándítsam azokat, akik meglevő BI rendszerüket szerettek volna táblagépről is elérni. Nekik egy tipikus nagyvállalati környezetben éveket kell meg várniuk amíg a vállalat upgrade ciklusa eléri a mobil lehetőségeket.

HTML 5 alapú mobil BI

A HTML 5 böngészőkön keresztül meghozza a mobil BI lehetőségeket minden kliens platformra, de a jelenleg felépített BI rendszereket nem lehet meg egy darabig elérni a HTML 5 alapú Power View-ből. Csak a felhőben futó SharePointból.

És a felhőben futó SharePointnak - és így a BI portálnak is - van méretkorlátja. Jelenleg 10 megánál nagyobb PowerPivotos Excel fájlnál nagyobb fájl nem tölthető fel rá. Valószínű, hogy ezt a korlátot megemelik majd a Power BI megjelenésére, de nem hiszem hogy többszáz megabájtra.

Támpontul: az Önkiszolgáló BI worshopon kb. 50 megabájtos Excel fájllal dolgozunk, ami lefedi a magyarországi gyógyszerforgalom 2 évét, hónapra es megyére aggregálva. Az ügyfeleimnél élesben használt Excel fájlok mérete viszont jellemzően eléri/meghaladja a 100 megabájtot, ami így nem tölthető fel a SharePoint on-linera. Ez nem biztos, hogy baj, de tudnunk kell, hogy nem minden PowerPivot megoldásunk lehet automatikusan webesíthető.

Tehát ha táblagépre akarunk fejleszteni, akkor némely esetben csökkentett tartalmú (méretű) megoldást kell készítenünk. Ez egy IT által menedzselt világban nem feltétlenül baj, de egy olyan területen, mint amilyen a Power BI célközönsége, már könnyen nyűggé válhat. Az üzleti felhasználok ugyanis nem fogjak tolerálni, ha egy külön Excel fájlt is el kell készítenünk és karban kell tartaniuk pusztán azért, hogy táblagépről is elérhető legyen a megoldásuk.

Mobil BI alkalmazás

Lesz ipad kliens. Nem böngészőből futó, hanem igazi, natív, az App Store-ból letölthető mobil BI kliens. Nem tudom mit fog tudni, nem tudom hogy fog majd működni, de jön. És ez nagy boldogsággal tölt el.

Több, mint 3 éve, amikor elkezdtem tesztelni a Mobil BI technológiákat, nem gondoltam volna, hogy 2013 végéig kell majd várni arra, hogy a Microsoft kijön valamilyen natív alkalmazással... De úgy néz ki, hogy ezen a fronton is szép lassan pont kerülhet az í-re.

Miért fontos ennyire a mobil BI?

Nem minden vezető akarja elérni a vállalat kulcsinformációit táblagépről. De minden vezetőnek szüksége van a LEHETŐSÉGRE, hogy elérhesse a kulcsinformációkat táblagépen is. A táblagép ugyanis a szabadság megtestesítője. Hogy bárhol és bármikor képes vagyok kontrollálni a vállalatot.

Épp ezért a szállítóknak az ajánlati fázisban égető szükségük van a mobil BI lehetőségek biztosítására. Lehet, hogy nem a vezető tör pálcát egyik vagy másik megoldás fölött, de egy biztos: Az az eszköz jobb, amiben van mobil BI támogatás annál, amiben nincs. Ez mindenki számára érthető, világos és evidens.

"Teljesítmény alapján választunk autót, de a nyomatékát használjuk a közlekedésben" magyarázta egyszer egy barátom. Nincs ez máshogy a BI esetében sem. Nem a mobilhasználat a legfontosabb része a vállalati BI-nak. De az eszközválasztásnál óriási szerepe van.

Az utóbbi egy-két évben nem találkoztam olyan BI ajánlati felhívással ahol ne lett volna igényként megjelenítve a mobil BI. Nem azt kérték, hogy fejlesszünk táblagépre, nem azt kérték, hogy fejlesszünk mobilon is elérhető megoldást hanem azt, hogy ennek legyen meg a lehetősége.

Mindezek miatt nagyon várom az iPad alkalmazást és bízom benne, hogy nagyot fog domborítani vele a Microsoft. A mobil BI ma már nem egy ismeretlen piac. Most már nem azon kell gondolkodni, hogy hogyan fogják a felhasználok táblagépről használni a BI-t. 3-4 éve még ez volt a kulcskérdés. De ma ez az út már ki van járva, úgyhogy csak egy jó klienst kell csinálni és bízom benne, hogy az iPad-es és Windowsos megoldás ilyen lesz.

BI site

A BI site nagy valószínűséggel a SharePoint online BI lehetőségeire szűkített változata, amit becsomagolnak majd a Power BI-ba. Gyakorlatilag egy felhőben futó BI portál, ahol az üzleti felhasználók megoszthatják egymással az önkiszolgáló módon felépített megoldásaikat, elemzéseiket.

A webes megosztásra eddig is lehetőségünk volt, csak SharePoint Enterprise-ra, es egy olyan csapatra volt szükség aki felkonfigurálta es menedzselte a BI portált.

A gyakorlatban azonban egy ilyen BI portál ritkán épült fel. Hiába volt meg a szoftveres lehetősége. A SharePointért felelős csapat nem ért a BI hoz, a BI-os csapat nem ért a SharePointhoz és a BI portál a kettő határán van valahol. A semmi közepén.

A felhőben futó BI site pont erre a problémára lehet egy nagyon jó megoldás, hiszen fel van építve karban van tartva. Az üzleti felhasználok AZONNAL birtokba vehetik. Felpublikálhatják rá önkiszolgáló BI megoldásaikat, beállíthatják azok adatfrissítési gyakoriságát, szabályozhatják hogy ki férhet hozzá és kész. Nem kell hozzá az IT. Nem kell megvárni amíg az IT feltelepíti, felépíti a BI portált. Hiszen az már készen van. Nem kell könyörögni érte, nem kell várni rá, azonnal birtokba vehető. Csak fizetni kell érte és kész. Lehet, hogy ez még csak ígéret. Lehet, hogy ki fog verni pár biztosítékot, de a technikai korlátok már megszűntek...

A nagyvállalatok azonban, - akiknek nagy BI büdzséjük van - még évekig nem fognak rálepni erre az ösvényre. Ez borítékolható. A kicsiknek viszont - akiknek nincs annyi büdzséjük BI-ra viszont számukat tekintve jóval többen vannak mint a nagyok - egy nagyon jó belépési pont lesz a professzionális BI megoldások felé.

BI site: Nem csak webes riportok tárolása

Bár nagyon kevés még a megszellőztetett információ de úgy fest, hogy a BI site-on nem csak riportokat, hanem adatokat és adat transzformációkat is tárolhatunk majd. Ez utóbbira mondok egy példát.

A példa az egyik önkiszolgáló BI workshoprol való, ahol a megyei népesség adatokat a Wikipédiáról szedtük le és mivel azok eredeti formájukban használhatatlanok voltak, ezért a Data Explorerrel (újabb nevén Power Query) emberi fogyasztásra alkalmas formába transzformáltuk: tizedes pont csere vesszőre, szóközök törlése, szöveg konvertálása számmá, mértékegység levágása, stb.

Ha jók az információim, akkor az így elkészített transzformációt elmenthetjük a majd BI site-ra és ha valakinek szüksége van népesség adatokra, akkor csak fel kell mennie a BI site-ra es meg kell adni forrásként azt a táblát, ami mögött a valóságban egy transzformációs szkript fut. Nem adat - bár a felhasználó annak látja - , hanem egy nézet, egy transzformációs szkript ami mindig a friss és transzformált adatokat adja vissza.

Nem az adatot tároljuk, hanem a transzformációt. És ez szerintem zseniális. Nem az adatot kell feltölteni duplikáltan tárolni és állandóan karban tartani, hanem a transzformációt. Egy ETL fejlesztő ezt eddig is könnyen meg tudta csinálni, de az elemzők nem.

Nézzük meg egy elemző napi rutinját! Forrásadatot másol, tisztit és transzformál, új forrást állít elő. Kézzel. Nap, mint nap ismétlődő jelleggel. Mert nem volt eszköze, amivel ezeket a transzformációkat meg tudná valósítani. Most úgy néz ki, hogy lesz egy. Ráadásul egy olyan amelynek outputja nem adat, hanem egy automatikusan frissülő tábla.

Természetes nyelvű lekérdezés/keresés az adatok között

Része lesz a Power BI csomagnak egy természetes nyelvű lekérdező/kereső is, ami lehetőséget biztosit arra hogy természetes (angol) nyelven írjuk meg lekérdezéseinket. Azaz beírjuk, hogy "show me the ABC product sales" és a természetes nyelvű kereső felhozza azokat az adatokat, amely az ABC termék eladási statisztikáit mutatja. Kiteszi térképre, grafikont rajzol, táblákat tölt fel. Jól hangzik?

Megmondom őszintém nagyon szkeptikus vagyok vele. Van itt valaki, aki 2000 környékén is követte BI vagy SQL server közeli témákat? Aki igen annak ismerős lehet ez a megoldás... Anno volt az SQL szervernek egy English Query nevű szolgáltatása ami nagyon hasonlóan működött: Beírtuk, hogy „show me the Top 10 customers" és jött a válasz. Próbálgattuk, de a való életben nem vált be. A hétköznapi nyelvünk sokkal egyszerűbb annál, hogy bonyolult lekérdezéseket szavakkal pontosan megfogalmazzunk. Épp ezért ebben a formában a természetes nyelvű lekérdezésnek nem adok nagy esélyt. Ugyanakkor nagyon sokat fejlődött a technika ezen a téren az elmúlt tizenx évben, és lehet hogy egész jól használható megoldást kapunk. Meglátjuk.

Viszont van itt más is. Mégpedig a háttér technológia, ami már nem a 13 évvel ezelőtti, és jóval több annál amit a természetes nyelvű lekérdező láttatni enged. De erről majd egy másik cikkben...

Összefoglalva

Azt kell látnunk, hogy a Power BI elsősorban nem a nagyvállalatoknak szól majd. Nem az ő problémáikra ad megoldást és szerintem nem is őket célozza vele a Microsoft. Nekik továbbra is megmarad a klasszikus (lokális) kliens szerveres BI architektúra fejlesztői es üzemeltetői csapatokkal, külső tanácsadókkal/szállítókkal. A Power BI csak annyira illik a BI stratégiájukba, amennyire a szakterületi BI vagy az önkiszolgáló BI. A Power BI az Ő szemüvegükön nézve nem más mint egy önkiszolgáló BI szoftvercsomag, ami remekül kiegészíti felépített adattárházukat.

A kis- és közepes vállalatoknak ugyanakkor egy lehetőség lesz a BI-ra. Azon cégeknél ahol kis túlzással egy ember cseréli a festékpatront, telepíti a szoftvereket, készíti a mentéseket, fejleszti az alkalmazásokat, a Power BI jelentheti a BI rendszert. A Power BI az Ő szemüvegükön keresztül nézve nem más mint egy egyszerűen üzemeltethető és karbantartható keretrendszer, ahol az üzleti felhasználókkal karöltve építhetik majd fel BI rendszerüket. Az Ő esetükben a Power BI valószínűleg a nagybetűs BI lesz, amin keresztül értékesítési forgalmukat elemezhetik.

Meglátjuk majd milyen változásokat hoz a Microsoft új BI szoftvercsomagja a kis- és középvállalatok számára. De ha segítségre lesz szüksége tudjon róla, hogy van hova fordulnia.

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2013. szeptember 24.-i Önkiszolgáló BI workshopra. Részletek >>

  

Bookmark and Share

Miért kell export to Excel funkció?

$
0
0

Vissza a múlt századba... 1998-at írunk. Kijött a Microsoft OLAP szervere de nem volt hozzá BI kliens... A Microsoft filozófiája ebben az időszakban az volt, hogy ők adják a back-endet és a partnerek majd kifejlesztik a front-endet. A partnerek ki is fejlesztettek jó párat. Egytől-egyig használhatatlan volt mindegyik. A kedvencem egy olyan BI kliens volt, amelyben ha lefúrtunk, a PC hangszórója fúrógép hangot adott ki. Mókás volt, de összecsukni a hierarchiát már nem lehetett...

Mi ekkortájt már jó néhány BI bevezetésen túl voltunk ORACLE Expresszel. Ismertük a felhasználók igényeit és tudtuk, hogy hiába van egy jó OLAP back-end, ha nincs hozzá jó BI front-end. Nem akarom szaporítani a szót. A vége az lett, hogy belekezdtünk egy BI kliens kifejlesztésébe.

Elkezdtük összeírni, hogy milyen funkciókat kell támogatnia a BI kliensünknek: Lefúrás, rotálás, beágyazás, .... Export to Excel. Majd ez utóbbin elgondolkodtunk.

Miért kell export to Excel gomb?

Mert kell egy szoftver, ahol a felhasználók manipulálni tudják a számokat, mert nem minden felhasználónak lesz BI kliense és az Excelen keresztül meg tudják osztani az elemzéseiket, mert az Excellel össze tudják fűzni a BI rendszer adatait má rendszerek adataival, mert úgy is ki fogják követelni maguknak a felhasználók, bla-bla-bla. Aztán miután feltettük az 5 miért kérdést, megkaptuk a választ: Mert nem fogunk tudni soha olyan rugalmas BI eszközt építeni, mint az Excel.

Rájöttünk ugyanis, hogy az Export to Excel gombra akkor kattintanak a felhasználók, amikor elérték a BI szoftver lehetőségeinek határát. Drasztikusabban fogalmazva, amikor a BI szoftver mebukott...

Most 15 évvel később déjá vu érzésem van. Egy cég érdeklődött az önkiszolgáló BI iránt. Megkérdeztem, hogy használnak-e a cégnél adattárházat vagy BI rendszert és mondta, hogy igen. Kérdeztem, hogy mi a problémájuk vele, miért gondolkodnak PowerPivotban? És jött a válasz, hogy "mert a BI eszközünk csak Excel 2003-ba tud exportálni, ami még csak 65 ezer sort tud kezelni..."

|

Ha tetszett, nézze meg a BI jegyzetek-et is

Építsünk interfész adatbázist a PowerPivot alá?

$
0
0

A legjobb az, ha az önkiszolgáló BI rendszer alatt van egy adattárház. Pont. De mit csináljunk akkor, ha nincs adattárházunk, vagy az adattárházunkban nem található meg az a forrás, amelyből dolgozni szeretnénk? Érdemes kiépíteni az önkiszolgáló BI rendszer alá egy köztes (interfész) adatbázist, vagy használjuk inkább az önkiszolgáló BI rendszer adatbázis-kezelőjét?

Nos. Ha nem érjük el közvetlenül a forrásadatbázist, akkor érdemes építeni a PowerPivot-os önkiszolgáló BI rendszer alá egy köztes adatbázist. Ha a forrásadatok nem adatbázis-kezelőkben vannak tárolva, akkor is. Mondom az érveket.

Inkrementális töltés

A PowerPivot adatbázisát nem lehet inkrementálisan tölteni. Az egy read only in memory adatbázis, amit trükközve lehet inkrementális módon tölteni, de hivatalosan támogatott módszer nincs az inkrementális töltésre. Ugyanakkor egy köztes adatbázisban az inkrementális töltés könnyen megoldható.

Pillanatfelvételek esete

Sokszor egy üzleti probléma meg sem oldható, vagy csak nagyon nehezen oldható meg köztes adatbázis nélkül. Ilyen üzleti probléma például a pillanatfelvételek esete (stock mutatók) ahol az elemzés során pillanatképeket hasonlítunk egymáshoz. (készletszint változás, státuszváltozások, bankszámla egyenleg, stb.) E pillanatképek rögzítésre vagy tranzakciókból történő visszafejtésére a Pover Pivot nem, vagy csak nagyon korlátozottan alkalmas.

ETL

Adatbázis-kezelőkkel sokkal könnyebb az forrásadatokat a megfelelő alakra hozni, mint a PowerPivottal

Újrahasznosítás

Ha meg kell tisztítanunk a forrásadatokat, akkor azt célszerű egy adatbázisban megtenni, így mások is élvezhetik ennek előnyeit. Ha a PowerPivotban tisztítanánk, akkor annak eredményét csak az adott PowerPivot adatbázisra épülő riportok használhatnák.

Ugyanilyen megfontolásból célszerű a sokak által használható kategóriákat, ügyfélszegmenseket, besorolásokat, minősítéseket, stb mind-mind külön adatbázisban, esetleg központi törzsadatkezelőben tárolni.

Teljesítmény

A PowerPivot az adatokat jobban tudja tömöríteni ha a forrásból rendezetten olvassuk be. Ehhez viszont az szükséges hogy beolvasás előtt rendezzük az adatokat, amit pl txt forrásfájlok esetén könnyen meg tudunk csinálni egy köztes adatbázisban

Szintén a teljesítmény mellett szól érvként, hogy a PowerPivot a számított oszlopokat rosszabbul tudja tömöríteni, mint a sima oszlopokat. Emiatt célszerű a számított oszlopokat adatbázis oldalon létrehozni és rendezve beolvasni.

Összefoglalva: Ha az üzleti felhasználók nem érik el közvetlenül a forrásadatbázisokat, vagy ha a forrásadatok nem adatbázisok kezelőkben vannak tárolva, akkor érdemes interfész adatbázist építeni az önkiszolgáló BI rendszer alá. (És nem az önkiszolgáló BI rendszerben megoldani mindent.)

Az IT ebben tud segíteni. Ebben profi. És ha már segít, akkor érdemes olyan interfész adatbázist építenie, ami adattárház jellemzőket mutat :-)

|

Ha tetszett, nézze meg a BI jegyzetek-et is

Nyelv váltás Excelből

$
0
0

Adott a következő probléma: Van egy adattárházunk tetején egy OLAP kocka, amelyből magyarul is és angolul is kell riportokat készítetni. Míg az ügyfélszolgálatokon dolgozó munkatársak magyarul fognak riportokat készíteni, addig a menedzsment és topmenedzsment angolul. A kontrolling pedig attól függően magyarul vagy angolul, hogy kinek készítik az elemzéseket, riportokat.

A megoldás adott. Az Analysis Services OLAP adatbáziskezelő támogatja a többnyelvű egjelenítést. Csak annyit kell ehhez csinálni, hogy a mutatóknak, dimenzióknak, attribútumoknak kell meg kell adni a magyar megnevezésüket, illetve meg kell mondanunk, hogy melyik oszlop tárolja a termékek, dátumok, stb. magyar megnevezését.

Tudtam hogyan kell ilyet csinálni, hiszen jópár éve csináltam már. Írtam is róla:

Elolvastam a cikkeket és nem úgy ment, mint ahogy mennie kellett volna. Döbbenten álltam a probléma előtt. Aztán hazafelé eszembe jutott, hogy ha a connection tulajdonságainál be van pipálva a „retrieve data and errors in the office display language when available" jelölőnégyzet, akkor az Excel nem a regionális beállításoknak megfelelő nyelvet fogja használni, hanem az Excel nyelvének megfelelőt.

Adatok lekérdezése az Office nyelvével azonos nyelven

Ha tehát magyar regionális beállítások mellett angol Office-t használunk és a „retrieve data and errors in the office display language when available" jelölőnégyzet be van jelölve, akkor az angol nyelvű translation-t fogja az Excel megjeleníteni. Brrrr.

Jó hír viszont, hogy az ügyfelem angol nyelvű Excelt használ magyar regionális beállításokkal, így nem kell connection stringekkel bíbelődnie ha nyelvet akar váltani, hiszen elég csak a „retrieve data and errors in the office display language when available" jelölőnégyzet ki-be pipálnia a nyelvváltáshoz. Zseniális :-)

A setup a következő:

  1. Az OLAP adatbázis angol nyelvű, de
  2. fel van véve pluszba egy magyar nyelvű translation is
  3. A regionális beállítás a kliens gépeken magyar és
  4. az Excel angol nyelvű.

 

|

Ha tetszett, nézze meg a BI jegyzetek-et is

Adat Rambók

$
0
0

Kik azok az adat Rambók? Olyan Excel felhasználók, akik eddig egyedül csináltak mindent. Ahogy a Mórickás vicc mondja:

  • Apa, Rambónak csúfolnak a iskolában
  • A teremburáját! Holnap bemegyek és beszélek az osztályfőnököddel
  • Hagyd apa. Ezt a harcot nekem kell megvívnom

Az adat rambók power userek, akik ha nem volt adattárházuk, csináltak egyet. Egyedül. Minden más munkájuk mellett. Nem adat Rambóként kezdték, de az élet azzá nevelte őket.

Adat Rambo

Miért fontosak nekünk az adat Rambók? Mert az önkiszolgáló BI stratégiában nagyon fontos szerepet kapnak majd. Egy önkiszolgáló BI ökoszisztémában ugyanis ők lesznek majd a fő fejlesztők. Őket kell majd megtalálnunk, és IT valamint tanácsadó oldalról nagyon erősen támogatnunk. Őket kell majd motiválnunk, őket kell majd képeznünk hiszen Tőlük függ majd az Önkiszolgáló BI sikere.

|

Ha tetszett, nézze meg a BI jegyzetek-et is

PowerPivot 2013 számított mezők dokumentálása, függőségek detektálása

$
0
0

Írtam már arról korábban, hogy hogyan lehet az  Excel 2010-es PowerPivot függőségeit feltérképezni illetve arról is, hogy  hogyan lehet a számított mezőket dokumentálni.

Excel 2013-ban ezt kicsit trükkösebben lehet megoldani. Mutatom hogyan:

Lekérdezzük a PowerPivot adatbázis legkisebb tábláját: (Meglévő kapcsolatok gombra kattintva)

Dax szerkesztő előhívása (Jobb egér a táblázaton)

A DAX szerkesztőbe beírni az alábbi lekérdezést:

 

Számított mezők dokumentálásához:

 

SELECT

                [MEASURE_NAME],

                [DESCRIPTION],

                [MEASUREGROUP_NAME],

                [EXPRESSION],

                [MEASURE_UNIQUE_NAME],

                [MEASURE_IS_VISIBLE],

                [DEFAULT_FORMAT_STRING] 

FROM $SYSTEM.MDSCHEMA_MEASURES

WHERE [MEASURE_AGGREGATOR] = 0

 

Függőségek detektálásához

SELECT

DISTINCT [Object],

[Expression],

[Referenced_object] 

FROM $system.discover_calc_dependency

WHERE Object_Type = 'Measure'

És jönnek az eredmények:

|

Ha tetszett, nézze meg a BI projekt blog-ot is


A tantermi tanfolyamok legnagyobb korlátja

$
0
0

Sok embert oktatattam már. Aki olvassa a BI projekt blogot az tudja ezt. A tanfolyamokat folyamatosan javítottam, optimalizáltam, de voltak olyan problémáim, amelyekre csak nagyon lassan találtam meg a megoldást. Az egyik ilyen probléma az volt, hogy hogyan tudom átadni a tudást úgy, hogy a résztvevők be tudják építeni a frissen szerzett tudást a mindennapi gyakorlatba.

A tanfolyamokon sokszor rá is kérdeztek: „Tudok valamilyen módszert a hatékony tanulásra?" És ekkor mindig elmeséltem, hogy ha oktatásra megyek, akkor az oktatások után mindig kiveszek fél nap szabit, hogy feldolgozzam és akciótervvé alakítsam a tanfolyamon hallottakat: Mi az amit meg fogok csinálni, hol tudom a saját gyakorlatomban használni a tanult elméletet, mit csináltam rosszul eddig, stb.

Persze amikor ezt elmeséltem akkor mindig megmosolyogtak és közben arra gondoltak, hogy: „bár csak megtehetném cimbora"... Pedig működik. És nem csak én gondolkodom így.

Hagy meséljek el egy példát. Nemrég egy vezérigazgató kért egy vezetői BI oktatást magának és a teljes vezérkarnak. A vezérigazgató kapásból úgy kérte az oktatást, hogy rá egy héttel kért magának egy follow-up oktatást is. Nem azért mert ezt javasoltam. Hanem azért mert ezt Ő is így szokta. A tantermi tanfolyamoknak ugyanis nem ott van vége, hogy az oktató megköszöni a figyelmet, hanem ott, hogy összeírjuk, átgondoljuk mit, mikor és hogyan fogunk átültetni a gyakorlatba. Akár egyedül, akár az oktató segítségével.

Aztán egy másik példa: Szintén gyakorlat, hogy az önkiszolgáló BI workshopra többször is eljön egy résztvevő. Kérdeztem is tőlük, hogy miért jöttek el másodszor is ugyanarra az anyagra és a válasz rendszerint az volt, hogy most már értünk hozzá és ennek tükrében szeretnénk meghallgatni még egyszer. És abszolút megértem őket. A szakkönyveket általában én is kétszer olvasom ki. Először amikor új a téma, másodszor pedig amikor már gyakorlatban használom. Amikor először olvasom a könyvet, akkor még csak annyit értek meg belőle, hogy HOGYAN kell csinálni, de miután megcsináltam és újra kiolvasom a könyvet megértem azt is, hogy MIÉRT így csináltam.

Aztán még egy példa: Valahol olvastam egy kutatást arról, hogy a tanfolyami résztvevők kb. 20%-a tudja a tanfolyamon hallottakat alkalmazni a gyakorlatban. Ez egyfelől megnyugtatott, hogy nem vagyok egyedül, még ha bízom benne is hogy nálunk nem ilyen alacsony ez a szám, másfelől elszomorított és e kutatás. Ennek köszönhetően, illetve az előbb említett történetek tükrében elkezdtem gondolkozni azon, hogy hogyan lehetne ezt a számot feljebb tornászni, és a résztvevőkből mihamarabb gyakorlati szakembert faragni, a tudást minél jobban rögzíteni és a tanulási ciklust lerövidíteni.

A kérdés tehát ez volt: Hogyan tudom elérni, hogy a résztvevők minél magasabb számánál alakuljon át az elméleti tudás napi gyakorlatban használt tudássá?

Az első és máig használt módszer az volt, hogy nyomatékosan megkértem a résztvevőket, hogy egész nap egy dolgon járjon az agyuk: Hogyan/hol tudják majd használni a tanultakat a gyakorlatban, illetve hogyan tudnak majd profitálni az itt megszerzett tudásból. Lehet hogy ez segített valamit, de áttörést nem hozott. Ahogy az sem, hogy az elsőbbségi képzések némelyikén a szünetekben fel is írtuk egy táblára, hogy hol/hogyan tudnánk ezt használni a hallottakat a napi gyakorlatban.

De volt még egy probléma:"Van egy konkrét esetem. Tudnál ebben tanácsot adni?"

Szinte minden önkiszolgáló BI workshopon volt egy-két résztvevő, aki elmesélt egy valós üzleti problémát és utána megkérdezte, hogy szerintem ezt hogyan lehetne megoldani. A válasz azonban ritkán érte el célját mert egy szünet rendszerint kevés ahhoz, hogy megértsem az üzleti problémát és elmagyarázzam, hogy hogyan lehetne megoldani.

És ekkor bevillant: Oldjuk meg közösen a problémát. Ültessük át közösen az elméletet a gyakorlatba!

A megoldás: on-the-job tréning!

Az on-the-job Power Pivot tréninget pont az eddig említett problémának a megoldására fejlesztettem ki. Zárkózzunk be 3 napra, tanuljunk jó sokat és közben oldjunk meg egy valós problémát. Együtt. Ültessük át az elméletet a gyakorlatba a megszerzett tudás épüljön be a vállalat folyamataiba és AZONNAL kezdjen el termelni, termővé válni!

Az első képzéseken már túlvagyunk és a tapasztalatok nagyon jók. Ha érdekli a téma, ha elérte az Excel korlátait akkor az önkiszolgáló BI workshop mellett nézze meg az on-the-job Power Pivot tréninget is, mert jelenlegi tudásom szerint ez a leghatékonyabb módja az önkiszolgáló BI/Power Pivot tanulásnak.

Érdekel. Megnézem az On-the-job Power Pivot tréninget >>

|

Ha tetszett, nézze meg a BI jegyzetek-et is

Mi tűnt el a 2013-as PowerPivottal

$
0
0

Sokat jegyzeteltem itt már a 2013-as Excel PowerPivot bővítményeinek újdonságairól és várhatóan sokat is fogok még. Most következzen egy olyan téma, ami ritkán beszédtéma. Nevezetesen a „Mi tűnt el a 2013-as PowerPivottal”

  • Kapcsolatok észlelése: Bár megmaradt a funkció, de az már csak a forrásadatbázisokban létező kapcsolatokat deríti fel. A 2010-es PowerPivotban megismert heurisztikus kereső eltűnt
  • Leírások:A leírások (Description) rögzíthetősége megmaradt a PowerPivotban, de sajnos az Excel már nem jelenti meg őket. Nagyon kár érte, mert nagyon jó tulajdonsága volt a 2010-es Excelnek, hogy a mutatószám fölé vive az egeret látszott az adott mutatószám leírása
  • Perspektívák kezelése: A 2010-es V2-es verziójú Power Pivot meghozta a Perspektívák kezelésének lehetőségét, de a 2013-as Excelből kivették ennek megjeleníthetőségét...
  • Más adatforrás megadása:A 2010-es Excel lehetőséget biztosított arra, hogy a Pivot tábla PowerPivot adatforrását meg lehessen változtatni. A 2013-as Excelben, ha a Pivot tábla egy belső Power Pivot adatbázisra mutat, akkor ez a funkció nem elérhető. Pedig nagyon fontos lenne ez migrációkor, azaz amikor a Power Pivot adatbázist átteszük a szerverre és szeretnénk ha a riportjaink a belső adatbázis helyett a szerveres adatbázisból táplálkoznának...

A kapcsolatok észlelésének hiánya nem olyan fájó, de a többi igen...

|

Ha tetszett, nézze meg a BI projekt blog-ot is

Power Query már magyarul is!

LastUpdatedDate, LastPocessedDate, LastRefreshDate

$
0
0

Sok ügyfelemnek megírtam már az elmúlt tizenx évben, hogy hogyan lehet lekérdezni az Analysis Services / Power Pivot kockák utolsó frissítésének dátumát, de ide még egyszer sem írtam le. Úgyhogy most megteszem :-)

Az utolsó felösszegzés dátuma MDX-ből

SELECT LAST_DATA_UPDATE

FROM $System.MDSCHEMA_CUBES

Where Cube_Name ='Kocka'

Az utolsó felösszegzés dátuma SQL-ből OpenQuery-vel

Select*

from Openquery(

LinkedServerName,

'SELECT LAST_DATA_UPDATE FROM $System.MDSCHEMA_CUBES Where Cube_Name = ''Sales'''

)

Az utolsó tranzakció dátuma MDX-ből

Withmember LastTransactionDateas

[Date].[Day].Currentmember.name

Select LastTransactionDateon 0

from [Sales]

whereTAIL(NONEMPTY([Date].[Day].[Day].members, [Measures].[Ft]), 1)

Az utolsó tranzakció dátuma Excelből a kocka (Cube)

függvényekkel=CUBERANKEDMEMBER("KapcsolatfájlNeve"; "TAIL(NONEMPTY([Date].[Day].[Day].members, [Measures].[Ft]), 1)"; 1)

|

Ha tetszett, nézze meg a BI projekt blog-ot is

Képlet a pivot táblában

$
0
0

Nem tudtam róla, hogy ha visszaírható az OLAP kocka, akkor abba be lehet írni képleteket. Erre az üzleti felhasználók tanítottak meg, amikor megmutatták hogyan kell egy már elkészült tervet betölteni egy OLAP kockába:

/pics/20130902224026/image001.png

 

Képlet a Pivot táblában

Hiába. Az ember mindig tud valami újat tanulni a felhasználóktól. Különösen azoktól, akik „nem akarnak ínhüvelygyulladást kapni” :-)

Korrekciók háttérszínének módosítása

$
0
0

OLAP kockákban át szoktam álltani azoknak a celláknak a háttérszínét, amelyeket a felhasználók töltenek fel. (Pl tervezéskor, korrekciók rögzítésekor, mi lenne ha modellezések alkalmával) hogy mindenki lássa, hogy azok az értékek nem más adatbázisokból jönnek, hanem azokat a felhasználók rögzítették.

/pics/20130902224700/image001.png

Korrekció oszlop háttérszínének állíása

Hogyan változtatom meg egy mező háttérszínét?  A BACK_COLOR() utasítással az MDX Scriptben megadva. Mutatom:

BACK_COLOR([Measures].[Korrekció]) = RGB(255, 255, 204);

Korrekciók háttérszínének módosítása 2

$
0
0

Arról már írtam, a korrekciók háttérszínének módosítása című cikk első részében, hogy hogyan állítható be OLAP (Analysis Services) oldalon egy measure (tehát nem egy számított mező) háttérszíne. Most következzen az, hogy hogyan állítható be a Pivot táblában a háttérszín úgy, hogy a felhasználó a korrekciók rögzítésekor egyből lássa, hogy melyik cellába írhat és melyikbe nem.

Mivel csak tényadatot korrigálhat, ezért azokat a cellákat, amelyekhez tartozik tényadat sárgára színeztem. Mutatom:

/pics/20130908213410/image001.png

A sárga háttérszínű cellákba rögzíthet a felhasználó korrekciókat, a fehérbe nem

A képlet (MDX Script), amit a színezéshez használtam:

BACK_COLOR([Measures].[Korrekció])

= IIF(

                ISEMPTY([Measures].[Tény])

                , RGB(255, 255, 255)

                , RGB(255, 255, 204)

);

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2014. február 18.-i Önkiszolgáló BI workshopra. Részletek >>

  

|

Ha tetszett, nézze meg a BI projekt blog-ot is


Magyar reklámfilm a BI-ról

$
0
0

Elkészült az első Magyarországon játszódó üzleti intelligencia (BI) témájú reklámfilm. Az ismerős helyeket bemutató hangosfilm 1 perc hosszú, és két, az Andokból hazatérő turista Magyarországra gyakorolt hatását elemzi.

A drámai fordulatokat rejtő film érdekessége, hogy Excellel, illetve egy ahhoz ingyenesen letölthető Power map nevű bővítménnyel készült.

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2014. február 18.-i Önkiszolgáló BI workshopra. Részletek >>

  


Már úton a következő cikk. Iratkozzon fel az értesítőre!

|

Miért kell a PowerPivot alá adattárház?

$
0
0

Ugyanazért mint amiért a forrásrendszerekre sem futtatunk ad-hoc riportokat:

  • A forrásrendszereket nem terheljük közvetlen adatlekérdezésekkel
  • A forrásrendszerek adatbázisainak lekérdezése az üzleti felhasználók számára reménytelen feladat (többezer tábla, nem beszédes megnevezések, ismeretlen adatkapcsolatok, ...)
  • A forrásadatbázis lekérdezéséhez nincs joguk az üzleti felhasználóknak (Az alkalmazáshoz van, de az adatbázishoz már nincs)

És a PowerPivottal épített önkiszolgáló BI rendszer nem helyettesíti az adattárházat

  • Technikailag sem adattárházra tervezték (Memóriában futó adatbázis kezelő, inkrementálisan nem tölthető, egyszerű jogosultság kezelés, nem nagyon tunningolható, stb)
  • Nem tud megvalósulni az „igazság egy verziója" (Nincs központi adatbázis, nincs egy kézben a fejlesztés, )
  • Nem tudja kezelni a historikus változásokat, nem auditálható, ...

Biztosan van még más is, de elsőre ezek jutottak eszembe.

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2014. február 18.-i Önkiszolgáló BI workshopra. Részletek >>

  

|

Ha tetszett, nézze meg a BI projekt blog-ot is

Egy VIR bevezetés előtt álló cégnek miért fontos az önkiszolgáló BI?

$
0
0

Vezetői információs rendszer (VIR) kell. Pont. De milyen legyen a VIR? Ki építse fel? Oldjuk meg házon belül vagy pályáztassuk meg? Adattárház kell vagy elég csak egy vezetői információs rendszer?

Mit tesz ilyen helyzetben egy VIR bevezetése előtt álló szervezet? Megnéz jó néhány termékbemutatót, tájékozódik az interneten, felhív olyan ismerősöket, akik már éltek át VIR bevezetést és kifaggatja őket hogy mik a tapasztalatok.

De ez még általában kevés. Ahogy egy autót is ki akarunk próbálni vásárlás előtt, úgy egy VIR-t is jó lenne kipróbálni. Mit tud majd a VIR? Hogy fog működni? Mennyire lesz rugalmas? Hogyan tudjuk majd bővíteni? Mindezekről csak úgy győződhetünk meg, ha kipróbáljuk.

Építsünk prototípust!

Egyre szélesebb körben, egyre több helyen használjuk az önkiszolgáló BI eszközöket a fenti kérdések megválaszolására alkalmas prototípus építésére. Ingyenes, vagy az Excel részét képező eszközökkel modellezzük a cég vagy szervezeti egység problémáját és közben gyűjtjük a tapasztalatokat, keressük az eszköz korlátait, elemezzük a buktatókat és alternatívákat keresünk a megoldásukra.

Az elkészült prototípust aztán bemutatjuk cégen belül a döntéshozóknak/kulcsfelhasználóknak, akik aztán visszajelzéseikkel megerősítik, hogy jó úton járunk-e vagy sem, esetleg újabb igényeket fogalmaznak meg és teljes vállszélességgel az ügy mellé állnak (és alig várják hogy kész legyen a VIR :-))

És ehhez nem kell több hónap. Egy-két hét alatt fel lehet építeni azt a prototípust, ami segít megválaszolni a kérdéseket.

Ki építse fel a prototípust?

A prototípus felépítésére megkérhetjük a potenciális szállítót is, de önkiszolgáló BI eszközökkel mi magunk is felépíthetjük azt. (Ha elakadna, tudok segíteni. Van erre tantermi-és on-the-job képzésem is) A belső megvalósításnak ráadásul megvan az az előnye, hogy nem kell kiadnunk szenzitív infókat külső cégeknek addig, amig pontosan nem tudjuk, hogy mit akarunk. Márpedig egy vezetői információs rendszer bevezetésénél ez lehet nagyon fontos.

Összefoglalva: Egy VIR bevezetés előtt álló cégnek érdemes megismerkednie az önkiszolgáló BI lehetőségeivel. Ma már egy egynapos képzés keretei között megtanulhatja, hogy mit hozhat ki ezekből az eszközökből, milyen követelményeket támaszthat a majdani VIR-rel szemben.

Aztán érdemes a tanfolyam után prototípust építeni mert ez fogja igazán megmutatni, hogy hogyan fog viselkedni a szervezet egy VIR bevezetése során. Hozzáférünk automatizált módon a szervezetben található adatokhoz? Integrálni fogjuk tudni őket egy közös adatbázisba? Tényleg jól definiáltak az üzleti folyamataink, fogalmaink, mutatószámaink?

Mindezen kérdések megválaszolása mellett a prototípus felépítésével

  1. Felszínre kerülnek mindazok a buktatók, amik veszélyeztethetik a sikeres bevezetést
  2. Nem kell kiadni infót egy külsős cégnek, addig amíg nem tudjuk pontosan mit akarunk
  3. El tudjuk dönteni néhány nap alatt, hogy magunk akarjuk-e/tudjuk-e felépíteni vagy külső segítséget kell majd bevonni
  4. A prototípust be tudjuk mutatni a vezetőknek, a szervezet többi döntéshozójának, akik vissza tudják igazolni hogy erre van szükségük.
  5. A prototípus remek eszköz az igények felszínre hozására és megfogalmazására egy olyan szervezetnél, ahol nincs még határozott elképzelés a VIR-ről.
  6. Ha használható eredmény jön ki a prototípusból, akkor azt kis ráfordítással élesbe lehet állítani :-)

Úgyhogy érdemes prototipizálni és ebben az önkiszolgáló BI eszközök verhetetlenek.

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2014. február 18.-i Önkiszolgáló BI workshopra. Részletek >>

  


Már úton a következő cikk. Iratkozzon fel az értesítőre!

|

Ki építse fel a vállalat önkiszolgáló BI rendszerét?

$
0
0

Kire bízzuk az önkiszolgáló BI rendszer felépítését? Az IT-ra? Az üzleti felhasználókra? Esetleg BI specialistákra?

Az IT-ra?

Aligha. Ha az IT-ra bízzuk az önkiszolgáló BI rendszer felépítését, akkor pont a lényegét veszítjük el az önkiszolgáló BI filozófiának. Az IT-nak fontos szerepe lesz az alapadatok elérhetőségének biztosításában és a projekt végén az elkészült megoldások időzített frissítésének megoldásában, jogosultságok kiosztásában, de a rendszer felépítése nem az ő feladatuk.

Az üzleti területre?

Az üzleti terület szereti az Excelt, de nem ért az adatmodellezéshez, nem ismeri a forrásrendszereket. Ugyanakkor nyitottak az adatbázisok világa felé. Adatbázisokból dolgoztak eddig is, Accessben is csodákra voltak képesek. Ha nem volt a cégnél adattárház, hát építettek valami hasonlót. Úgyhogy ők ismerik az Excelt, nyitottak az adatbázis világa felé, érdemes lehet rájuk bízni az önkiszolgáló BI rendszer felépítését.

BI specialistákra?

Na ez jó kérdés. És megmondom őszintén a válasz cégtől is és üzleti problémától is függ. Mondok egy példát. Adott egy vállalat. Van adattárháza, van OLAP rendszere is, van belső BI csapata néhány BI specialistával. És van egy probléma is, amit adattárház oldalon kéne megoldani, de olyan a külső környezet, hogy a BI csapat nem tud olyan gyorsan fejleszteni, mint amilyen dinamikusan a környezet változására reagálni kell.

Kézenfekvő, hogy az alapadatokat tegyük adattárházba. De mit csináljunk a „gyorsan változó résszel?" Adjuk oda az üzleti felhasználókkal, hogy azt kezeljék ők. Legyen így, de ki építse fel? Mivel a probléma bonyolult, a határidők szűkösek, ezért úgy döntünk, hogy csinálja meg a belső BI csapat és a fejlesztést adja át az üzletnek, aki szép lassan megtanulja, átveszi.

Eredmény? Az üzleti terület „szép lassan" átvette és megszerette. Ma már professzionálisan használják, de az átvétel nagyon lassan ment. Féltek belenyúlni az éles „rendszerbe", nem volt idejük a napi munka mellett ezzel is foglalkozni így jó háromnegyed év volt mire magukénak érezték és merték módosítani.

Mai fejjel is így csinálnánk? Nem. Ez volt az egyike az első önkiszolgáló BI projekteknek. A technológiát uraltuk, a vállalat BI stratégiájába be tudtuk illeszteni az önkiszolgáló BI-t, de a szervezeti kultúrába történő beillesztés módjáról még csak vízióink voltak. Ma már valószínűleg csinálnánk a problémára egy on-the-job BI tréningetés a felhasználókkal KÖZÖSENépítenénk fel a rendszert. Még ha ez lassabb is. Még ha ez több szervezést, kommunikációt, együttgondolkodást is igényel. De megéri, mert jóval hamarabb jutnak el a felhasználók a magabiztos szintre, jóval hamarabb tudják majd alkalmazni a technikát más problémák megoldására is és ezáltal jóval gyorsabban reagálhatnak majd a piaci környezet változásaira.

Tudjon meg többet az itt elhangzottakról és jöjjön el a 2014. április 8.-i BI és adattárház projektvezető képzésre. Részletek >>

  

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2014. február 18.-i Önkiszolgáló BI workshopra. Részletek >>

  


Már úton a következő cikk. Iratkozzon fel az értesítőre!

Üres cellák nullává konvertálása kocka függvények használatakor

$
0
0

Adott a következő probléma: Kocka függvényeket tartalmazó Excel cellákat akarunk megformázni úgy, hogy

  • Ha a kocka függvény üres értékkel tér vissza, akkor a cellában 0 legyen
  • Egyébként pedig a kockából visszakapott érték

Miért akarunk 0-át kapni? Mert akocka függvény visszatérő üres értéke szöveges típusú, és mint ilyen nem lehet hozzáadni például egy egész számhoz

Megoldási alternatívák:

IF(ISBLANK(...

Sajnos nem fog működni, mert ha egy cella tartalmaz egy függvényt, akkor az a cella nem üres. Függetlenül attól,hogy a függvény üres értéket ad vissza

Cellaformázás

OLAP oldalon szoktunk úgy NULL helyett NULLÁt visszaadni,hogy a FORMAT_STRING property-vel játszunk. Pl.: a #,##0 formázás hatására az üres cella 0 értéket fog visszaadni. No ez az ami Excel oldalon a kocka függvényekkel nem működik. Hiába álltjuk be ezt a custom cellaformázási lehetőségeknél, a cellába nem kerül nulla üres érték esetén

IFERROR(CUBEVALUE()+0; 0)

Ez az ami tökéletesen működik. Ha a kocka függvény által visszaadott üres értékhez hozzáadunk nullát,akkor hibát kapunk és ezt a hibát már le tudjuk kezelni úgy hogy 0 kerüljön a cellába.

Viewing all 129 articles
Browse latest View live