Az adattárház projektek a fejlesztési feladatokon belül is specifikus irányt képviselnek, hiszen nagyon változatosak, és nagyon nehéz részletes követelményt összeállítani előre – de mi most ebben a cikkben megpróbáljuk megválaszolni a leggyakoribb kérdéseket.
Már több mint 25 éve alkalmazunk
Adattárházakat a vállalati információszolgáltatásban. Ez idő alatt rengeteg projekttapasztalat, jógyakorlat és kockázat elkerülő technika alakult ki, amelynek gyakorlatban való alkalmazásával sikeres az adattárház projektjeink lesznek.
A Vállalati Adattárházat jellemzően közép és nagy vállalatok alakítják ki saját maguk számára, hogy a működésüket megvalósító operatív rendszereikből az adatokat átemelve és újraszervezve, jó teljesítményű és egyszerűen kezelhető, a vállalati vezetés támogató beszámolókat, jelentéseket és elemzéseket használhassanak.
A magyarországi gyakorlatban egy vállalati adattárház projekt induló mérete 50-150 mFt, átfutási ideje 8-15 hónap, a teljes projektcsapat létszáma 30-40 fő, amely magába foglalja a fejlesztőket, kulcsfelhasználókat, IT oldali üzemeltető munkatársakat is. Egy ilyen méretű projekten leginkább tapasztalt projektvezetővel és helyes adattárház fejlesztési módszertan alkalmazásával maximazálhatjuk a projekt hasznát, de természetesen egy kiváló fejlesztő csapat is szükséges az eredményekhez.
Mi az szembetűnő legnagyobb különbségek egy korábban alkalmazás fejlesztési projekteken edződött projektvezető számára, mikor egy adattárház projekttel találkozik? Avagy miért nem elegendő egy jó projektvezető, és miért szükséges adattárház tapasztalat is a megfelelő irányításhoz?
Az adattárház projekten szinte lehetetlen a pontos és részletes követelmény összeállítani, sőt rendszerint viszonylag nagyon tág határ között értelmezhető követelmény lista készül el. Ennek oka, hogy a működést alkotó operatív rendszerek is gyakran több ezer használati esetet (use-case) tartalmaznak, és nem ritka, hogy egy adattárház indulásakor 3-5 alaprendszerből kell integrálni az adatokat. A vállalat komplex működését alkotó működési eseteket egy vállalati szakember sem tudja átlátni, de a fejlesztésbe bevont összes kulcsfelhasználó is csak a szükséges információ 20-30%-át adja át az adattárház fejlesztő csapat számára. A többi követelmény-részletet a tervezési, fejlesztési, de még inkább a tesztelési szakaszban derítik fel és vezetik át a rendszeren, és még így is nagyon sok apró részlet rendszerint kidolgozatlan marad – adattárház fejlesztést csak abbahagyni lehet, befejezni sosem. Gyakorlati tapasztalatunk, hogy egy sikeresen projektben a követelményfelmérés és tervezés, a megvalósítás és a tesztelési fázisok 1:1:1 arányú (embernap) erőforrást igényelnek. Kevésbé sikeres projekteken a tesztelési (hibajavítási) fázisban nő meg az erőforrás szükséglet, azaz a tesztelési fázis közepéig gyakran nem látszik a projekten, hogy rossz úton halad.
A követelmények eredendő pontatlansága kihat a rendszer tesztelésére is, hiszen a szokásos tesztelési módszertanok szerinti használati esetekből levezethető white-box és a black-box tesztelési esetek sem feltétlenül vezetnek a siker irányába. Helyette az adattárházakban az a helyes tesztelési koncepció, hogy a rendszertervhez képesti verifikálás helyett a hangsúly a kulcsfelhasználó általi validálásra tevődjön át. A fejlesztés első lépésétől valós adatokon azonnal ellenőrizzük az adatminőséget, a kulcsfelhasználók által átadott információk teljességét és helyességét, prototípusokat készítünk és ezeket minél hamarabb bemutatjuk a kulcsfelhasználóknak. A tesztelési eredmények alapján javítjuk a követelménytervet, rendszertervet, az algoritmusokat és újrateszteljük a rendszert.
Az adattárház fejlesztés egyfajta agilis módon történik, de az elterjedt Scrum módszertant a tapasztalatok szerint még sem lehet jól használni: az adattárház funkciók viszonylag hosszú és tervezhetetlen, valamint egyedileg változó és megjósolhatatlan fejlesztési-tesztelési ciklusszámban fejleszthetők ki, és az egyes funkciók különféle módon és néha felmérhetetlenül korrelálnak egymással. Emiatt a fejlesztési feladatokat szinte lehetetlen belekényszeríti egy olyan állandó 2-4 hetes Scrum idődobozba, aminek céljait az időszak elején definiáljuk. A Scrum helyett inkább célszerű az adattárház tervező, fejlesztő, hibakereső és javító gyártóegységekben (gyártósorokban vagy futószalagban) gondolkodni, amiknek összteljesítményét Kanban módszerrel lehet jól összehangolni. A gyártósorról legördülő új vagy javított adattárház funkciókat heti vagy kétheti rendszerességgel lehet kiadni kulcsfelhasználóknak tesztelésre, bár gyakran csak az utolsó pillanatban dől el melyik javítás vagy új funkció kerülhet kiadásra, pontosabban kulcsfelhasználói tesztelésre.
Ugyanakkor egy induló adattárház fejlesztésnél még egy gyakorlott fejlesztői csapattal is jelentős időbe telik az adattárház fejlesztő gyártósorokat összeállítani, illetve a fejlesztési módszertant lebontani apró szabványos tevékenységekké, valamint a fejlesztőket kiképezni futószalag szerű működésre. A problémák oka, hogy gyakorlatban nincs két egyforma adattárház projekt, projektről projektre nagy a fejlesztők fluktuációja, eltérőek a használt eszközök.
Melyik szereplőkön múlik az adattárház bevezetés sikere?
Az adattárház minősége, használhatósága és sikeressége a fejlesztői oldali üzleti elemző (BA: Business Analyst) és a felhasználói oldal kulcsfelhasználóin múlik leginkább, illetve a kettőjük közötti kommunikáción. Ha e két szereplő között nem jó az együttműködés, akkor lényegesen hosszabban és sokkal több tesztelési ciklusban alakul ki a helyes adattárház rendszer.
Persze ahhoz, hogy az adattárház fejlesztés egyáltalán elinduljon, és az erőforrások rendelkezésre álljanak, valamint a kulcsfelhasználók motivációja és rendelkezésre állása megfelelő legyen, a megfelelő adattárház felsővezetői szponzor támogatása és vasakarata elengedhetetlen.
Mi a sikeres adattárház projekt ismérvei?
- Folyamatos felsővezetői támogatás, erős üzleti oldali szponzor
- Iteratív bevezetés, a felhasználói elvárások folyamatos kezelése
- Az adattárház-bevezetés az adattárház fejlesztők, az üzleti területek és IT közös feladata egy csapatban
- A kulcsfelhasználók központi szerepet töltenek be a teljes bevezetés során,
- A projektet megelőzően az egységes üzleti fogalmak kialakultak, és üzlet terület elfogadja és ismeri a forrásadatokat és ezek adatminőségét
- A bevezetés során a kulcsfelhasználók, valamint szakmai és IT-üzemeltetők folyamatos támogatása és adattárház technológiára való képzése megvalósul, és hasznosul
Milyen kockázatok mellett veszélyes az adattárház bevezetése?
- A projektszponzor nem elég erős az adattárház által kitűzött célok képviseletére
- A bevezetés céljai és a hozzájuk tartozó sikerkritériumok nincsenek meghatározva
- A bevezetésben a kulcsfelhasználók nem vesznek részt aktívan
- Erős szervezeti ellentét van két üzleti terület, vagy az IT között
- Irreális vagy egymásnak ellentmondó felhasználói elvárások az adattárház által szolgáltatott adatok, jelentések, elemzések minőségével, illetve eredményességével kapcsolatban
- A forrásrendszerekben található adatok tartalma nem dokumentált, és a kulcsfelhasználók csak korlátozott mértékben ismerik az adatok tartalmát
- Egyes üzleti igények kielégítéséhez az operatív rendszerek fejlesztése szükséges
- Új, korábban még adattárház bevezetésben nem használt szoftver és hardver eszközök alkalmazása
- Az adattárház bevezetés kiváltó oka nem a remélt üzleti haszon, hanem technológiai szempontok
- A lekérdező eszközök használata túl bonyolult a felhasználók nagy része számára, akik utána nem szívesen használják az eszközöket
Mikor sikeres egy adattárház? Hogyan mérhetjük meg, hogy sikeres-e a bevezetés?
- Egy sikeres adattárház alkalmazásban a felhasználók aktívan használják az adattárházat, elfogadják az adattárház által szolgáltatott jelentésekben és lekérdezésekben szereplő értékeket. Az adattárház aktívan hozzájárult üzleti problémák megoldásához
- Az adattárház adatminősége a bevezetés folyamán fokozatosan javul, a teljes kialakítás után pedig legalább szinten marad
- A felhasználók újabb és újabb igényeket nyújtanak be az adattárházban megtalálható adatok, lekérdezések bővítésére
A mi véleményünk, hogy bár a fenti módszereket és tapasztalatokat ugyan a klasszikus adattárház fejlesztések alapján állítottuk össze, de ugyanúgy használható Big Data adattárházak fejlesztéséhez indított projektjeinkben is.
Mi a véleményetek, hogy projekt sikeresség és kockázatok szempontjából van-e releváns különbség egy klasszikus (small) data és Big Data adattárház építése között? Írd meg nekünk itt!
A szerző a
Stratis Kft. tanácsadója, mely cég vezetői és informatikai megvalósítással és tanácsadással foglalkozik. Ha érdekelnek a hozzájuk kapcsolódó hírek és érdekességek, akkor közvetlenül is követheted az
adatlapjukat, hogy biztos ne maradj le semmiről
