Üzleti Intelligencia Hírek, újdonságok és tesztek az üzleti intelligencia és az adattárházak világából

Open Source BI&DW&ETL 3.

A nyári szezon kellős közepén mi is szeretjük a strandon a hideg sört megpihentetni a kockás hasizmunkon, miközben a szemünk is táplálkozik - de persze koránt sem annyira, mint az OS BI eszközök felhasználásának lehetőségeiről és mikéntjéről elmélkedni. Le is írom, min elmélkedtem a Balaton partján.

Mai témám az OS-t bevezető cégek (mind ügyfél, mind konzultáns oldalról) szervezeti és projekt menedzsment szükségletei. Egyszerűbben: elgondolkozom rajta, milyen emberekre, milyen szervezeti struktúrában, milyen projekt vezetési módszerekre van szükség ahhoz, hogy egy OS BI bevezetés / használat sikeres legyen.

Emberi erőforrások:

• szükség van természetesen olyan emberekre (mint minden BI projekt esetén) akik az adott felhasználó cég üzleti modelljét, működését, a BI eszközzel támogatni kívánt terület adatait és azok felhasználását ismerik. Ilyen ember triviálisan a felhasználó cég bugyraiban található, persze nem biztos, hogy egy BI projektre dedikálják a kellő mértékben, vagy hogy ő képes / hajlandó a BI projekt nyűgeit a sajátjának érezni és azok megoldásán buzgólkodni. Ennél a feladatkörnél nem kritikus az OS szemlélet és tapasztalat megléte - inkább a profi hozzáállás és a szükséges üzleti, szervezeti információk magas szintű szolgáltatása a nyerő.
• A fenti szaktudást érdemes kiegészíteni egy olyan erőforrással (ne hívjuk egyszerűen csak embernek, hiszen több annál), aki bizonyos mértékben járatos mind az üzleti, mind a technikai területeken és sokan csak BA-nak, azaz Business Analyst-nak hívják, félik, tisztelik. Jellemzően vagy technológiai oldalról jött és hozzá tanulja az üzleti dolgokat, vagy fordítva - de legtöbbször valamelyik oldalra sántít is kicsit. Kevesen vannak az igazán felkészült, profi BA-k, akik valódi hidat tudnak képezni a két terület között, én legalábbis keveset ismerek. Nekik már nem árt, ha az OS BI rendszerek lelkivilágával, a hagyományos rendszerektől eltérő jellemzőivel is tisztában vannak, és nem macerálják a fejlesztőket fölösleges hülyeségekkel (mint hogy "muszáj" MS 2007 XLS formátumba menteni a riportot, mert az ő gépén az fut...).
  A jó BA kérdez, a nagyon jó BA jó embertől kérdez, az annál is jobb BA keres az interneten és sokat olvas, aki még annál is jobb BA, az már projektvezető...
• Van ugye a projektvezető, aki nagyon kell. Nehezen lennék képes arra, hogy a BI projektekben, különösen az OS BI bevezetéseknél szükséges projektvezetői képességeket szépen csokorba szedjem, inkább csak általánosságokra szorítkozom: viseltessék kellő alázattal mind a projekt céljai mind az erőforrások (akár sw akár ember) lehetőségei iránt, legyen találékony, legyen tapasztalt, ne átalljon informálódni mielőtt dönt, rendelkezzen hajlékony gerinccel, szeresse a sört és tudjon szájharmónikázni.
  A technológiai döntések meghozatala itt elég komplex folyamat lehet: az OS rendszereknél fokozottan igaz, hogy nehéz konkrét összehasonlító mátrixot, listákat találni, amikből kiderül, melyik verzióban (pl community edition vs. professional) mi van, milyen feladatra milyen megoldást, eszközt, kiegészítést, patch-et szükséges használni. Az erőforrás tervezésnél érdemes minél több tartalékot képezni a kutató, kereső, olvasó, próbálgató időszakokra, és tökre nem ciki megkérdezni a fejlesztőket a véleményükről, tapasztalataikról.
• És a fejlesztő-konzultáns-technikai ember, aki ugye viszi a lapátot, cementtel keveri a biteket és rakja egymásra a DW-BI rendszerek építő köveit. Itt általában a cégek a költségek miatt megelégszenek az "átlagos" fejlesztővel. Aki megcsinálja amit mondanak neki. De legalábbis megpróbálja. Túlórázik ha kell. Ismer 1-2 technológiát és jellemzően mindent ezekkel akar megvalósítani. Nem nagyon kíváncsi, kevés dolog érdekli az adott technológia - feladat kérdéskörén kívül. Nagyon rendes ember, szereti a családját, csak ritkán marad ki otthonról és csak kicsit homofób. A rossz hír, hogy az ilyen emberek a hagyományos BI projektekben (amik szintén elég komplexek tudnak lenni) is tud késést, buktát okozni. Azonban egy OS BI projektben, ahol "mozog" a kezünk alatt a technológia, sok helyről, sok forrásból integrálhatjuk össze az igényeinknek megfelelő eszközöket, minden órában döntéshelyzetbe kerülnek a fejlesztők (is). Azok, akik nem kellően innovatívak, motiváltak, nem akarják / tudják az új technológiákat gyorsan az eszköztárukba építeni, nem látják át, hogy a nekik kielégíteni szükséges követelmény rendszerek milyen megoldásokat igényelnek - könnyen elbukhatnak, de legalábbis csúszásokat okoznak.

Általában elmondható, hogy a az OS rendszerek bevezetését, fejlesztését végző csapatnak szüksége van olyan tagokra, akik képesek gyorsan újat tanulni, a sok helyen föllelhető információ morzsákat egybe építeni - ez erodálja a tekintélyét az olyan embereknek akik egy technológiában évtizedes tapasztalatot szereztek ugyan, de mindjárt be kell dobni két felest ha az OTN-en nem található meg azonnal egy funkció leírása. Gondoljunk arra, hogy az ilyen helyzetek feszültséget generálhatnak a projekt csapatban, tervezzünk be sok sörözést, esetleg tartsunk házi Fight Club-ot a stresz kezelésére.

A szervezeti struktúra esetében is a kellően laza, sok mindent kibíró, kevés kőbe vésett szabályt és hierarchiát tartalmazó struktúrák lehetnek működőképesek egy OS BI projektben. Nehéz elképzelni, hogy egy szép keddi délelőttön fölmerülő adatbázis probléma (mondjuk észrevesszük, hogy az EnterpriseDB nem azt érti bitmap index alatt, amit szerintünk kéne, így lassúak a lekérdezések), amit egy agilis fejlesztő egy technológia upgarde-el, egy patch alkalmazásával ha nem is  saját hatáskörben, de legfeljebb 1-2 kolléga és a projektvezető bevonásával meg is tudna oldani izibe, és az egész okozna teszteléssel együtt max 2 nap csúszást, bevárja a következő hétfői projekt meetinget ahol eszkalálják a projekt board-hoz, akik nem biztos hogy értik miről van szó, így esetleg bevonnak egy külső tanácsadó céget a kockázatok csökkentésére...
Az OS eszközöknek éppen az az egyik szépségük, hogy sok mozgásteret adnak a fejlesztőknek - emiatt különösen kritikus, hogy megbízható technológiai csapat álljon a hátunk mögött - és a megbízhatóságot lehet kondícionálni a fejlesztési folyamatokba épített kontrolokkal. Az üzleti felhasználóknak, projektvezetőknek nem kell az elszabadult fejlesztő hordák garázdálkodásától félniük, inkább arra kell ügyelni, hogy az OS fejlesztések, módosítások is a saját céges szabványok szerint follyanak, dokumentáltak, verzió kezeltek legyenek, illetve megfelelő erőforrást kell rendelni a teszteléshez is. Azért minden területen egy fejlesztőben sem lehet megbízni, pl egy szép sorbarendező algoritmusért hajlandóak eladni a családi ezüstöt, vagy lemondani a magyar karakterekről is, azokat úgyis csak a lúzerek használják...
 

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.