Olvasási idő: 7 perc

Egy adattárház aktuális megítélését rengeteg tényező befolyásolja, erről szélesebb kitekintésben fogunk írni egy másik posztban. Most egy olyan tényezőt fogok részletesen megvizsgálni, ami nem közvetlenül hat, hanem hosszú távon befolyásolja egy adattárház működését és használhatóságát: az adattárház változáskezelési folyamatait.

Fontos megfelelően beállítani mind a technikai mind az üzleti szempontú változáskezelést. Mindkettőt jól ki kell egyensúlyozni egy adattárház hosszú távú sikere érdekében. Ebben a posztban néhány példát hozok mindkettő elcsúszására, illetve általunk látott jó gyakorlatokra.

Technikai kontroll

Két hibába is lehet esni ezen a területen. Ha a technikai változásmanagement túl gyenge vagy túl erős, az egyaránt rossz hatással van hosszú távon az adattárház minőségére.

Kontrollhiány

Az egyik hiba, ha túl laza a változásmanagement. Ha nincs, vagy nem elég erős a fejlesztési szabályzat vagy a keretrendszer, amit az adattárház használ. Ha egy adattárházban sem a fejlesztési szabályzat, sem a felhasznált technológia nem tiltja hogy rossz minőségű kód töltse be az adatokat, akkor előbb-utóbb elkerülhetetlenül rossz minőségű kód fogja tölteni az adatok egyre nagyobb részét. Ez többféle problémához is vezethet: 

• Nagyobb eséllyel kerül hibás vagy inkonzisztens adat az adattárházba. 
• Még ha az adatbetöltés helyes is, sérülhet a bekerült adat auditálhatósága. 
• Gyakoribbá válhatnak a leállások. 
• A rossz minőségű kód, nehezen fenntartható kód is egyben, így egyre drágább és hosszadalmasabb lesz általa mind a hibák megtalálása és kijavítása, mind az új funkciók fejlesztése. 

Szerencsére ilyen típusú problémahalmazzal ritkán szembesülünk az ügyfeleinknél. Egy cég életében inkább az adattárház létrejötte előtti időszak riportolási technológiáit jellemzik ilyen problémák, melyek szerepet játszhatnak abban, hogy a vezetés egy adattárház létrehozása mellett dönt.

Cseberből vederbe

A másik hiba pedig, ha az ellenkező irányba megyünk el túl messzire, és túl szigorúvá és komplexszé tesszük az adattárházat támogató keretrendszert és fejlesztési folyamatokat. Ezzel a problémával élőben is találkozunk némely ügyfelünknél. Az adattárház fejlesztési folyamatának minden lépése alaposan dokumentálva és auditálva történt egy nagyon magas, absztrakciós szintű rendszerben. Ez elsőre előnynek tűnhet, de sajnos  elérte azt a szintet, hogy a visszájára fordult. A rendszer legalább annyira nehezítette, mint segítette a fejlesztést, és a fejlesztéshez szükséges speciális szaktudást külső forrásból kellett beszerezni. A munkák kiszervezése körül kialakult folyamatok roppant időigényessé és drágává tettek minden változtatást. Így  egyrészt gyakran buktak el adattárház-fejlesztési projektek, akár a büdzsé, akár az időtartam növekedése miatt. Másrészt az esetleges tervezési hibák szükséges javítása sem mindig történt meg a magas költség miatt. Az adattárház bukásának egyértelmű jeleit figyelhettük itt meg, az okok között valószínűleg szerepelt a technikai change control túl magas szintje is.

Jó gyakorlatok

Nincs természetesen a technikai változásmanagementnek olyan szintje, ami minden adattárháznak egyaránt megfelel. Az adattárház méretével, komplexitásával, az iparági szabályozás szorosságával radikálisan változhat a szükséges change control szintje. Egész másfajta folyamatokra van szükség egy jelenléti ív- vagy egy banki adatokat tartalmazó adattárház fejlesztésénél, de néhány jól működő példát bemutatok.

Üzleti oldalról egyik ügyfelünknél láttunk egy nagyon jó gyakorlatot. Az adattárházat mi valósítottuk meg néhány éve, és a további fejlesztéseket azóta is mindig ránk bízzák. Könnyen vezethetett volna ez számukra az előző rossz példához hasonló helyzethez, ahol a legkisebb fejlesztést/hibajavítást is egy hosszadalmas beszerzési- és alkufolyamat előzi meg vagy lehetetleníti el. Ezt úgy tudták elkerülni, hogy meghatároztak egy rendszeres negyedéves support keretet, amiből (a ritka javítások mellett) alacsony szintű döntéssel meg tudnak rendelni kisebb fejlesztéseket is.

Azt gondolom, a Hiflylabs keretrendszere egy jó kompromisszum ezen a területen. Az auditálhatóság különböző szintjei projekt- vagy akár tábla-szinten is beállíthatóak. A fejlesztést segítő eszközök és az automatizált betöltők nagyban egyszerűsítik a fejlesztést, de nem olyan komplexek hogy egy viszonylag tapasztalt adattárházi szakembernek gondot okozzon az elsajátításuk. Az automatizálásnál mindig ügyelünk arra, hogy az adott eszköz kapacitásánál bonyolultabb feladatok könnyen beilleszthetőek legyenek a rendszerbe, így a rendszer nem válik merevvé. Ha elérte az adattárház azt a komplexitási szintet, hogy egyáltalán szükség van keretrendszerre, akkor már érdemes alkalmazni, és viszonylag magas bonyolultsági szinten és auditálhatósági elvárások mellett is megállja a helyét.

Üzleti kontroll

A hosszú távú sikerhez nem elég az adattárház változásmanagementjét technikai szempontból jól kiegyensúlyozni, fontos az üzleti szempontú change control folyamatait is megfelelően kialakítani. Itt is ugyanabba a két hibába lehet beleesni. 

Gyenge kontroll

Ha nincs egy egységes BI szakmai felügyelet az adattárház felett, minden üzleti terület szabadon rángathatja az adattárházat a saját szempontjai szerint. Ezért szükség van egy az adattárházért felelős BI csapatra, amelyiknek  megfelelő elemzői erőforrása van a fejlesztési igények érdemi felügyeletére, illetve kellő tekintéllyel rendelkezik a cégen belül, hogy az igényeket és a megvalósítást érdemben befolyásolni tudja. Ha ez a csapat hiányzik, vagy nem elég erős, akkor az egyes fejlesztések nem egymásra épülve, hanem egymástól függetlenül, vagy akár egymás ellenében is implementálásra kerülhetnek. Ha minden üzleti területnek az összes igénye megvalósításra kerül, anélkül hogy valaki előbb megvizsgálná a hatását más funkciókra, kiválthatóságát már meglévő funkciókkal, vagy egyeztetne más üzleti területekkel, amelyeknek várhatóan hasonló funkcióra lesz szüksége, az hosszú távon nagyban rontja az adattárház minőségét. Ugyanaz a funkció többször is megvalósításra kerül, akár egymásnak ellentmondó tartalommal, miközben hiányoznak azok a funkciók, amik minden üzleti területnek egyaránt hasznára válnak. Az adattárház egyik legfontosabb funkciója, a fogalom egységesítés vész el. Az üzleti területek elégedetlenek az adatok minőségével, frusztrálja őket, hogy a kimutatásaik ellentmondanak egymásnak, miközben a szükségesnél sokkal több erőforrást fordítanak az adattárház fejlesztésére.

A ló másik oldala

Másrészt, ha a BI csapat szakmai kontrollja olyan erőssé válik, hogy az már akadályává válik az üzleti területek számára szükséges fejlesztéseknek, azok más forrásból fogják beszerezni a számukra szükséges adatokat, és az adattárház előbb-utóbb eljelentéktelenedik. 

Egyszer egy cég globális adattárház csapatának vezetője egy szakmai beszélgetésen a „szentség” kifejezést használta az adattárházban lévő adatokkal kapcsolatban. Ennek a hozzáállásnak a pozitív és a negatív következményei egyaránt látszottak az általa felügyelt adattárházon. Minden bent lévő adat nagyon jól kitalált, egységes struktúrában volt, nagyon jól használható felhasználói felülettel. Elegánsan kezelte a különböző forrásrendszerekből származó adatok integrálásának problémáit, a manuálisan karbantartott meta-adatokat azok gazdái felhasználóbarát intuitív felületen tudták bevinni. Összességében tehát az adattárházban lévő adatokat öröm volt használni. Viszont az árnyoldalon a 10.000+ fős globálisan működő cég működésének mindössze két aspektusát fedte le az adattárház. Természetesen ez egyik szervezetnek sem volt elég, és virágoztak a cégben a helyi, regionális, illetve üzleti területek szerinti kiegészítő funkciójú (és változatos minőségű) adattárházak.

Jó gyakorlat

Ezen a területen is fontos az egyensúly megfelelő beállítása. Kell hogy legyen egy erős BI csapat amelyiknek megfelelő az elemzői kapacitása és kellő autoritással bír az adattárház felett, hogy egységes adattárházi struktúrát tudjon kikényszeríteni. De ennek a csapatnak folyamatosan oda kell figyelnie az üzleti igényekre is, nem szabad az adattárház belső működésére koncentrálva szem elől veszíteni a felhasználók elvárásait.

Találkoztam olyan belsős BI csapattal, akik, noha nem számláztak a belsős “ügyfeleknek” kizárólag a változás hasznát pénzben is kifejező üzleti indoklással fogadtak el változtatás kéréseket az üzleti területektől. Nem biztos hogy egy ilyen modell minden helyzetben megvalósítható, és önmagában nem is véd meg a túl erős (vagy akár a túl gyenge) változáskezelés hibájától. Ezzel együtt is azt gondolom, ha egy BI csapatnak jól kiegyensúlyozott víziója van az adattárházról, egy ehhez hasonló rendszer segíthet abban hogy az a vízió meg is valósuljon.

Tanulság

Legtöbbször, amikor egy adattárházat tervezünk vagy implementálunk, az adattárházra, mint egy üzleti probléma technikai megoldására tekintünk. Azt gondoljuk, hogy ha a megoldásunk megfelel a megrendelő üzleti igényeinek, akkor az adattárház várhatóan sikeres lesz, és ez rövid távon gyakran így is van. Nem szabad azonban arról megfeledkeznünk, hogy az adattárházak hosszú távú sikerét még a megvalósítás színvonalánál is sokkal inkább meghatározzák a körülötte kiépülő üzleti struktúrák és folyamatok.

Szerző:
Bárász Tamás – Senior BI Consultant