Önkiszolgáló BI eszmefuttatás 2.0

Az előző bejegyzésemben lábtörlő-gyilkos foxterrierként próbáltam szétcincálni Wayne Eckerson bejegyzését az önműködő BI arany-szabályairól.
De lássuk, a "5 legjobb módszer ahhoz, hogy..." típusú bejegyzések könnyű diadalt ígérő porba alázásán túl mit javasolok, és miért gondolom, hogy én majd jól meg mondom a tutit.

Vigyázat, ez egy elég komplex probléma, amiről a legjobb szándék mellett sem tudtam röviden és egyszerűen fogalmazva írni. Aki nem érdeklődik perverzen a BI rendszerek használatának anomáliái után az menjen inkább sétálni, a legelszántabbak pedig előbb pisiljenek, készítsék ki a korsó sört és csak aztán lássanak neki.
Boldog ifjúkoromban, valahogy úgy adódott, hogy egy nagy cég USA béli adattárházának BI adminisztrátora lettem. Kicsit több mint 1200 felhasználója volt a rendszernek, ebből 3-400 aktív és kb 15 power user (vagy inkább hard-core user, napi akár 100+ riport futtatással). Ebben a környezetben eltöltött kb 2 év alatt elég reprezentáns mintán sikerült megfigyeléseket végeznem a BI felhasználói szokások tekintetében.

Az egyik nagy probléma Wayne tanácsaival az, hogy a power user és a szürke, más néven "mezei" user alfaj nem választható szét élesen. Nem egyszer fordult elő, hogy valaki egy derűs hétfő reggelen megkapta a dicső feladatot a főnökétől, hogy uccu neki, állítsa elő a cég készpénzforgalmi előrejelzéséhez szükséges információkat, csináljon erre riportokat, hiszen rendelkezésre áll egy felhasználó barát / self-service BI eszköz, ja, és holnap délre meg kell lennie...
Én ilyenkor sok un. alert SMS-t kaptam éjszaka, és másnap meg sok levelet írtam arról mi az amit meg lehet, DE NEM ÉRDEMES megcsinálni egy BI rendszerben. Tehát a power user egyed sokszor nem igazi törzsfejlődés eredménye, hanem valamilyen generált mutáció hozza létre, és ilyenkor a képzési folyamatok lényegében kimaradnak. Ezen személyek által kreált riportok nem csak lassúak, erőforrás pazarlóak lehetnek, hanem sokszor pontatlanok is (emlékszem olyan álmatlan éjszakára, amikor pár millió dollárt kerestünk a BI rendszerben, míg kiderült, egy tapasztalatlan kolléga a számla beérkezésének dátumát használta szűrési feltételnek a teljesítés dátuma helyett, és ez sokaknál okozott szemöldök rángást hónapzáráskor).
Volt olyan, hogy az egyik osztály (mert a department -et sosem tudom rendesen leírni)  BI fejlesztései élesbe állásakor derült ki, hogy a userek által megvalósított, a saját környezetükben jól működő, "önműködő" módon összekattingatott riportok nem futnak le batch módban a szerveren, mert mindenféle (MS Office) DLL-eket igénylő funkciókat használnak, amiknek persze semmi keresnivalójuk a szerveren.

A másik probléma: Sokszor láttam olyat, hogy feltörekvő konzultáns cégek önjelölt BI szakértői - akik ugyan vették a fáradtságot, hogy elolvassák a BI rendszer help-jét, de arra már nem fordítottak időt, hogy utána olvassanak, vagy kiteszteljék, a tervezett adat mennyiségnél melyik funkciót érdemes használni a rendszerben és melyiket nem. Ennek általában az lesz a következménye, hogy a fejlesztés élesbe rakása előtt kialvatlan, zavart tekintetű konzultáns palánták ülnek a net előtt, olvassák a mienknél sokkal több hasznos információt tartalmazó blogokat, majd valamilyen bug-ra, de mindenképp a BI rendszert szállító cég hibájára hivatkozva próbálnak kötbér nélküli csúszást kialkudni az ügyfélnél. Aztán jön a már kifejlesztett megoldások áthegesztése, a nagyobb átmérőjű fa-tengely kifaragása, közismert nevén a gányolás.
És annyiban valóban van felelőssége a technológia gyártóknak, hogy a self-service -nél nem hívják föl a vásárlók figyelmét arra, hogy vannak határai, ezek kb hol találhatóak, mi az a komplexitás, adat mennyiség, stb, ahonnan már javasolt kivenni a gép kezéből a sarlót, kalapácsot.

A harmadik problémát ott látom, hogy Wayne barátunk gondolatai abból a feltételezésből indulnak ki, hogy a BI-t használó cégeknél - legalábbis a BI rendszerek használatához kapcsolódóan - logikus döntések születnek. Ez ott bukik meg, hogy a BI rendszereket nem cégek, hanem emberek (bocsánat, userek) használják. És ugyan ők is igyekeznek logikus döntéseket hozni, csakhogy a döntéseik alapjául szolgáló szabály rendszerek élesen elkülönülhetnek az őket alkalmazó cégek döntési szabály rendszerétől, de még a többi user-étől is.
Ez így bonyi, de lássunk egy példát: egy BI rendszert bevezető cégnek, mint a legtöbb reál gazdasági szereplőnek a legfőbb célja a profitjának maximalizálása (bevétel nőjön, kiadás csökkenjen, szakszervezet kussoljon), ennek rendel alá mindent. A cégnél dolgozó ember, aki a BI rendszer kapcsán  user-é lényegül át, más célok lebegnek a szeme előtt: a fizetése nőjön, a munka mennyisége csökkenjen, időben odaérjen a menzára, hogy még legyen bableves, a céges bulin jöjjön össze az új szőke titkárnővel, időben adja oda a főnökének a jelentéseket anélkül, hogy a főnököt tenisz partija közben zavarni kéne.

Ezekből a priorításokból kiindulva a user nem fog túl sok időt fecsérelni a BI rendszerekkel, illetve a self-service-vel kapcsolatos szabályok megismerésére és betartására, hanem a legkönyebb utat keresve (ha nem talál a céljainak megfelelő kész riportokat) mindjárt élni fog az önkiszolgálás nyújtotta lehetőségek garmadájával, okádni fogja a munkájához nem kritikusan szükséges riportokat. Ez rövidtávon működik is, amikor meg kezd a BI rendszer agonizálni a sok önkiszolgálástól, a főnök meg rájön, hogy a riportok amiket kapott nem sokkal több releváns információt tartalmaznak a Blikk Zámbó Árpival foglalkozó cikkénél, akkor a user még hivatkozhat a közismerten vacak BI technológiákra, a hold és a merkúr együttállására, vagy addigra előléptetik főnökké és egy napos hétfő reggelen megkérheti egyik beosztottját, szerezzen gyorsan adatokat a BI rendszerből, hiszen az self-service...

Tényleg ennyire tragikus lenne a helyzet? Dobjuk ki a BI rendszereket, helyette inkább vegyünk földet és küldjük ki az alkalmazottakat répát kapálni?
A répa ugyan nagyon egészséges, a mozgás sem árt a guris székektől tyúkszemes fenekű irodai harcosoknak, én önös érdekből mégis inkább az alábbiakat javaslom kipróbálni, hátha lesz egy működő és BIZONYOS SZINTIG önkiszolgáló BI rendszerünk:

1. Kritikusan fogadjuk az önkiszolgáló BI rendszerekről szóló, marketing jellegű állításokat. Valóban vannak self-service lehetőségek a legtöbb BI rendszerben, de ezek minden határon túli kiterjesztése a különböző üzleti területek, mindenféle igények lefedésére - igencsak költséges lehet. Pl olyan bonyolult szemantikus réteg kialakítása, amelyik az önkiszolgáló módon összerakott riportoknál is figyelembe veszi, hogy mi a lekérdező user cégen belüli pozíciója, mik a hozzá hasonló pozícióban lévő user-ek lekérdezési best-practice-i, az aktuális piaci trendek milyen korrekció használatát indokolják éppen, hány éves a kapitány, stb-stb, elvileg nem lehetetlen. Gyakorlatilag sokkal-sokkal többe kerülne (és valószínűleg belátható időn belül nem működne jól), mint alkalmazni egy BI konzultánst, aki lefejleszti az egyes userek, user csoportok igényeire testreszabott riport halmazokat.
2. Határozzuk meg, mekkora szabadságfokot adunk a BI usereknek (meddig terjedjen az önkiszolgálás lehetősége), és a határokat jól láthatóan jelezzük a technológia segítségével. SIKÍTSON a BI eszköz, ha valaki a self-service határait feszegeti (adat méret, lekérdezés ideje, riportok komplexítása, egy user-hez tartozó riportok száma, stb). A határok meghúzásánál is célszerű a költségeket alapul venni - a felhasználók saját érdekeiket szem előtt tartva általában sok mozgásteret akarnak, de a BI technológiától, illetve az igények komplexításától függően ennek lehet jó magas a költsége. Ha szükséges, kérjünk profi segítséget a BI rendszer felhasználási szabályainak és a szabályok betartását ösztönző korlátok tervezéséhez, megvalósításához is.
3. Sikítás után a BI rendszer mindjárt kínáljon föl segítséget, pl egy workflow rendszert, amin keresztül KÖZVETLENÜL el lehet érni a BI csapatot, lehet riport fejlesztést igényelni, kérdezni, anyázni, stb. Óvakodjunk egy általános célú Helpdesk közbe iktatásától, a BI rendszerek jellemzően túl komplexek ahhoz, hogy egy "általános" informatikus hatékony megoldást tudjon nyújtani, a kérések, kérdések jelentős része úgyis a BI csapatnál köt ki. Cserébe viszont a Helpdesk közbeiktatása lassíthatja és elriaszthatja a BI-ra éhes felhasználókat.
4. Ne kényszerítsünk tréningre, BI rendszer használatra mindenkit, illetve klasszifikáljuk a felhasználókat egyéni képességeik (és nem pozíciójuk) alapján. Ez miért jó? Egyrészt pénz kidobás tréningezni olyan embereket, akiknek a munka idejük optimalizálása az elsődleges priorításuk. Ők ezt büntetésnek élik meg, igyekeznek ellógni a tréningekről, illetve soha nem fogják használni a BI rendszert önkiszolgáló módon, ha ez előbb komoly, több napos munka-befektetést igényel. Ha mégis használják, és bármilyen nehézségbe ütköznének az önkiszolgálás során, akkor viszont boldogan passzolják le a feladatot a BI csapatnak, vagy keresnek olyan megoldást, ami csak munka időre - és nem performanciára, erőforrás felhasználásra optimalizált (pl batch futtatása azoknak a riportoknak, amik nap közben túl sokáig futnak). A tréning budget elköltése helyett esetleg megkérdezhetjük ezeket az embereket, nem akarnak-e inkább ebből finanszírozni egy BI fejlesztést, aminek az eredménye képpen  kaphatnak egy a saját felhasználási területükre testre szabott, akár a már használt rendszereikbe beágyazott BI alkalmazást.
   Viszont érdemes foglalkozni azokkal az emberekkel, akik - még ha a munkakörük nem is indokolja - érdeklődnek a BI rendszer iránt. Őket meg lehet győzni, hogy az adatbázis szintű előszűrése az adatoknak nem ekvivalens megoldás a riportba letöltött 28 millió sor képernyőn történő szűrésével, és ha megfelelő szellemi képességekkel rendelkeznek, még azt is megkérdezik, hogy miért. Lehet, hogy egy ilyen ember de-facto nem minősül power user-nek, de azért vigyük el sörözni, simogassuk meg a buksiját néha - nagy hasznunkra lehet, ha az ő üzleti területét érintő BI fejlesztésnél be akarjuk vonni.
5. Fogadjuk el tényként: a Télapó és az ingyen ebéd nem létezik - a BI rendszerek használata mindig költségekkel jár - akármit is mondanak nekünk az öltönyös emberek. Persze ez a költség jelentősen eltérhet (pl open source vs proprietary) a különböző BI rendzsreknél, a jó hír az, hogy bizonyos pontossággal ez azért becsülhető, tervezhető.
   Akkor használjuk a BI-t (akár önkiszolgáló módon, akár előre gyártott BI tartalmat igénybe véve), amikor a felhasználás TCO-ja kisebb, mint a használatukból várható bevétel növekedés, és költség csökkenés összege. Ha a self-service igények valamennyire körülírhatóak - támogassuk ezeket az architektúra, illetve a szemantikus réteg  megfelelő kialakításával. Ilyenek lehetnek pl homokozó környezetek fölállítása és pár user kontrollált hozzáférésének biztosítása, vagy a szemantikus réteg könnyű kiterjeszthetőségének, modularításának figyelembe vétele, a jövőbeni potenciális BI felhasználási területek adatköreinek elérhetővé tétele a BI tartalmak fejlesztésénél. Ha ezeknek a költségei becsülhetően magasabbak lesznek, mint amit erre áldozni akarunk, vagy már a BI rendszerbe épített határokat feszegetik a felhasználóink, akkor üljünk le inkább beszélgetni az érdekelt felhasználói csoportokkal, hogy mennyi pénzük lenne egy BI projektre...

És ennyi. Sok frázist elpuffogtathatok még, pl azt, hogy minden IT rendszer csak annyit ér, amennyit a konyhára hoz, meg hogy többe kerül a leves, mint a hús, de már nekem is nagyon ész-osztó típusúra sikeredett ez a poszt. Aki mégis elolvasta, köszönöm a figyelmét.

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.