CAPITOLUL 3

IMPLICAREA PERSONALULUI N APLICAREA

DEPOZITELOR DE DATE
Sumar:
3.1. Roluri cheie n dezvoltarea unui depozit de date
3.2. Ini(ierea yi sus(inerea proiectului
3.3. Rolul personalului de specialitate
3.4. Conducerea proiectului

60 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
3.1. ROLURI CHEIE N DEZVOLTAREA UNUI DEPOZIT DE
DATE
Desi ntr-un proiect care are n vedere crearea, implementarea si ntretinerea
unui depozit de date sunt implicate mai multe categorii de personal, se disting trei
roluri cheie care au o responsabilitate Ioarte mare n ceea ce priveste reusita
proiectului: susjintorul proiectului, managerul I1 si managerul proiectului.
Neglijarea oricruia dintre cele trei roluri poate conduce la nereusita unui plan bine
intentionat.
Sus(intorul proiectului. Fiecare initiativ n domeniul depozitelor de date
are un sustintor un personaj situat la un nivel nalt n ierarhia organizatiei care
oIer sustinere strategic si directioneaz mersul proiectului. Sustintorul proiectului
are rolul de a asigura c obiectivele proiectului sunt n concordant cu obiectivele
strategice ale organizatiei si, de asemenea, trebuie s Iac un lobby eIicient n cadrul
organizatiei pentru alocarea Iondurilor necesare.
Managerul IT. Acest personaj cheie este responsabil cu punerea n lucru a
resurselor umane si tehnologice alocate pentru proiect pentru a Ii ndeplinite cerintele
strategice, decizionale si operationale pe linie inIormational. Tehnologia depozitelor
de date este una de vrI la ora actual, ns are ca speciIic Iaptul c este dependent de
sistemele operationale traditionale, ceea ce implic utilizarea unor resurse aIlate la
dispozitia managerului IT. Rolul acestui personaj este important att n Iazele initiale
ale dezvoltrii si implementrii depozitului de date, precum si n perioada de
ntretinere.
Managerul de proiect. Acest personaj este responsabil cu toate activittile
tehnice reIeritoare la implementarea unui depozit de date. Ideal pentru acest rol este
un proIesionist IT, cu experient n cadrul ntreprinderii, ns se poate apela, de
asemenea, la 'stranieri n cazul n care este vorba despre un proiect pilot sau de o
complexitate care depseste capacittile personalului existent.
3.2. INITIEREA $I SUSTINEREA PROIECTULUI
nainte ca sustintorul proiectului s Iie de acord cu acest rol, el se va inIorma
n legtur cu viitorul proiect, iar cei care i propun acest rol trebuie s Iie capabili s-i
Depozite de date 61
Iurnizeze rspunsuri n msur s-l conving. n continuare vom analiza un set de
ntrebri Irecvente pentru astIel de situatii:
Cum vor Ii aIectate procesele decizionale n urma implementrii
depozitului de date?
Cum va reusi depozitul de date s mbuntteasc procesele Iinanciare,
activittile de marketing si activittile operationale?
Cnd se justiIic un proiect data warehouse?
Care sunt costurile unui proiect data warehouse?
Ce riscuri potentiale pot aIecta un proiect data warehouse?
Cnd organizatia este pregtit pentru implementarea unui depozit de
date?
Care sunt avantajele si rezultatele unui depozit de date si cum se
msoar acestea?
3.2.1. Cum vor fi afectate procesele decizionale n urma
implementrii depozitului de date?
Am Ii naivi dac ne-am astepta la o schimbare imediat si spectaculoas n
privinta proceselor decizionale ntr-o organizatie n care tehnologia depozitelor de
date ptrunde pentru prima dat. Utilizatorii Iinali vor Ii la nceput preocupati mai
mult s nvete cum s Ioloseasc depozitul de date dect s schimbe modul de
obtinere a inIormatiilor si de luare a deciziilor. De asemenea, este de asteptat ca
primele seturi de rapoarte predeIinite si interogri care sunt posibile prin exploatarea
depozitului de date s diIere de rapoartele deja existente.
Decidentii vor experimenta diverse niveluri de diIicultate n privinta utilizrii
depozitului de date; utilizarea eIicient presupune ns abilitti de lucru cu
calculatorul, cunoasterea datelor si ntelegerea aIacerii.
Abilit(i de lucru cu calculatorul. Nu toti decidentii sunt Iamiliarizati cu
tehnica de calcul si, de aceea, nu am Ii realisti dac am presupune c toti decidentii
dintr-o organizatie vor Iolosi direct si personal instrumentele puse la dispozitie de
depozitul de date. Pe de alt parte, exist utilizatori care agreeaz lucrul cu
calculatorul, sunt Ioarte Iamiliarizati cu programele de calcul tabelar si ca atare vor Ii
ncntati de noua tehnologie, Iortndu-i limitele cu interogri si cereri de rapoarte.
Cunoayterea datelor. Este deosebit de important ca utilizatorii Iinali,
decidentii, s Iie Iamiliarizati cu continutul depozitului de date nainte de a-l Iolosi.
62 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
Acest Iapt presupune ca limitele ntre care se ntinde depozitul de date s Iie
communicate utilizatorilor pentru ca acestia s stie ce pot si ce nu pot solicita de la
noul sistem. n acelasi timp utilizatorii trebuie s cunoasc si modul de utilizare a
instrumentelor cu ajutorul crora pot exploata datele existente.
n(elegerea afacerii. Utilizatorii depozitului de date trebuie s aib o
ntelegere proIund a naturii aIacerii lor si a problemelor legate de aceasta.
Rspunsurile pe care le oIer depozitul de date vor Ii Iolositoare doar n msura n
care ntrebrile sunt puse corect.
Pe msur ce utilizatorii capt ncredere n abilittile lor si n veridicitatea
continutului depozitului de date, gradul de Iolosire si de sustinere depozitului de date
va creste. Utilizatorii vor 'depsi rapoartele clasice si se vor orienta din ce n ce mai
mult ctre stilul ad-hoc de anliz permis de depozitul de date. De asemenea, una
dintre tendinte va Ii aceea de a genera rapoarte suplimentare din depozitul de date,
ceea ce va conduce la Ienomenul de 'suIocare a decidentilor; acestia din urm vor
preIera s-si micsoreze gradul de dependent Iat de rapoartele periodice, programate
si vor dori s ia decizii pe baza rapoartelor generate de exceptii sau de sistemele de
alertare.
Rapoartele generate de excep(ii. n loc s parcurg rapoartele programate
linie cu linie, decidentii vor dori s primeasc rapoarte care cuprind doar elementele
care ndeplinesc conditia lor de 'exceptie. De exemplu, n loc s primeasc raportul
de vnzri realizate de companie pe Iiecare regiune, un manager de vnzri va preIera
s primeasc un raport de vnzri care s cuprind doar regiunile care au o abatere
mai mare de 10 Iat de valorile prognozate.
Sistemele de alertare. Aceste sisteme Iunctioneaz dup acelasi principiu ca
rapoartele generate de exceptii si au rolul de a scoate n evident si de a atentiona doar
abaterile sau exceptiile. DiIerenta const n Iaptul c n loc de rapoarte, decidentii vor
primi notiIicri prin alte canale, de exemplu mesaje e-mail.
Pe msur de depozitul de date va Ii acceptat, stilul de luare a deciziilor va
evolua de la practica actual de a astepta rapoartele programate de la departamentul IT
ctre Iolosirea depozitului de date pentru a ntelege situatia n care se aIl organizatia
si deci ctre Iolosirea acestei tehnologii ca baz pentru deciziile strategice.
Depozite de date 63
3.2.2. Cum va mbunt(i depozitul de date derularea proceselor
financiare, a activit(ii de marketing yi a ctivit(ilor
opera(ionale?
Un eIort de construire si implementare a unui depozit de date care se va
Iinaliza cu succes va mbuntti procesele operationale, de marketing si Iinanciare
prin Iaptul c exist o viziune integrat asupra datelor organizatiei. Integrarea datelor
va duce n mod Iiresc la o standardizare a termenilor utilizati (de exemplu, o deIinitie
standard pentru client si profit n ntreaga organizatie).
3.2.2.1. Procesele financiare
Rapoartele Iinanciare consolidate, analizele de proIitabilitate, monitorizarea
riscurilor mbunttesc procesele Iinanciare ale organizatiei, n mod special n
organizatiile care au ca obiect de activitate prestarea de servicii Iinanciare (bnci,
societti de asigurri, Ionduri mutuale etc.). Procesul de consolidare necesit Iolosirea
unui vocabular comun si mbuntteste ntelegerea operatiunilor eIectuate de diverse
grupuri din organizatie.
Este ns important de stiut Iaptul c depozitul de date poate Iurniza inIormatii
doar pe baza datelor deja existente. De exemplu, una dintre cele mai populare
aplicatii bancare pe domeniul depozitelor de date este analiza proIitabilittii. Din
neIericire, organizatia poate avea un soc atunci cnd va constata c veniturile si
cheltuielile nu sunt nregistrate la acelasi nivel de detaliere. Bncile de regul
nregistreaz cheltuielile pe categorii Iunctionale, dar doresc s calculeze
proIitabilitatea pe Iiecare client n parte. Cu veniturile nregistrate la nivel de client si
costurile la nivel Iunctional, nu exist practic posibilitatea de a se calcula indicatorul
dorit.
3.2.2.2. Activit(ile de marketing
Tehnologia depozitelor de date sprijin deciziile de marketing prin oIerirea
unei viziuni cuprinztoare asupra Iiecrui client si a relatiilor sale cu ntreprinderea.
De-a lungul anilor, eIortul de marketing si-a schimbat Iocalizarea; clientii nu mai sunt
vzuti doar ca niste simple simboluri de conturi si sunt priviti ca entitti individuale
cu diIerite caracteristici. Conceptul de client individual cu personalitate proprie Iace,
de asemenea, posibil segmentarea si gsirea de proIiluri care s ajute la eIicientizarea
64 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
eIortului de marketing. Disponibilitatea datelor istorice si instrumentele de analiz
utilizate permit identiIicarea tendintelor n comportamentul consumatorului, cu eIect
direct n sporirea veniturilor realizate.
3.2.2.3. Activit(ile opera(ionale
Depozitele de date oIer managementului inIormatii pe baza crora sunt luate
si aplicate diverse decizii. Aceste decizii vor avea o inIluent direct asupra
operatiunilor eIectuate n organizatie. IdentiIicarea oportunittilor si a riscurilor
determin schimbri n modul n care organizatia se deplaseaz spre obiectivul
propus.
3.2.3. Cnd se justific un proiect de depozit de date?
Pot exista mai multe motive care s conduc la necesitatea unui depozit de
date; literatura de specialitate
1
prezint mai multe situatii n care un depozit de date
este oportun pentru rezolvarea problemelor aprute:
Insuficienta partajare a informa(iilor;
Grupuri diferite produc rapoarte contradictorii;
Procesul de creare a rapoartelor este foarte anevoios;
Rapoartele nu sunt dinamice yi nu favorizeaz stilul de
interogare ad-hoc;
Rapoartele care necesit date istorice sunt dificil de
realizat.

Insuficienta partajare a informa(iilor. Compartimentele sau departamentele
au aceiasi clienti, dar nu comunic inIormatiile ntre ele. Ca urmare, se pierd
oportunittile reIeritoare la stabilirea proIilului real al clientilor. De asemenea, clientii
pot Ii plictisiti de Iaptul c departamente din cadrul aceleiasi organizatie le solicit de
mai multe ori aceleasi inIormatii. Rezolvarea acestei probleme duce la urmtoarele
avantaje:
pot Ii luate decizii mai eIiciente n domeniul gestiunii clientilor;

1
Humphries, M., Hawkins, M., Dy, M., Data Warehousing. Architecture and Implementation, Prentice
Hall PTR, Upper Saddle River, New Jersey, 1999, pp. 55-57.
Depozite de date 65
clientii sunt tratati ca entitti individuale;
pot Ii explorate noi oportunitti de aIaceri.
Grupuri diferite produc rapoarte contradictorii. Datele din sisteme
operationale diIerite conduc la inIormatii diIerite despre acelasi subiect. Folosirea
inconsistent a termenilor duce la reguli diIerite pentru acelasi subiect. AstIel, Iaptele
sunt interpretate diIerit, iar n organizatie vor exista mai multe versiuni ale
'adevrului. Decidentii trebuie s analizeze date conIlictuale si si pot pierde
credibilitatea n Iata clientilor, Iurnizorilor, etc.
Rezolvarea acestei probleme conduce la urmtoarele beneIicii:
se poate vorbi de o viziune consistent asupra operatiunilor
ntreprinderii;
se pot lua decizii mai bune, bazate pe analize corecte.
Procesul de creare a rapoartelor este foarte anevoios. Rapoartele de
important critic necesit prea mult timp pentru a Ii produse, ceea ce Iace ca atunci
cnd sunt disponibile s nu mai Iie necesare. Preluarea datelor ntr-un raport complex
din mai multe sisteme operationale poate conduce la inconsistente sau erori. Ca
urmare deciziile luate pe baza acestor rapoarte pot Ii eronate. Analistii din organizatie
pierd prea mult timp operatiunile de colectare a datelor de care au nevoie, iar pentru
analiza propriu-zis le rmne prea putin timp. Concurentii care nu au asemenea
probleme beneIiciaz n mod clar de un avantaj competitiv. Rezolvarea acestei
probleme conduce la urmtoarele rezultate pozitive pentru organizatie:
procesul de creare a rapoartelor este n mod vizibil mbunttit;
rmne mai mult timp pentru analiza eIectiv a datelor;
decidentii nu sunt nevoiti s lucreze cu date 'nvechite.
Rapoartele nu sunt dinamice yi nu favorizeaz stilul de interogare ad-hoc.
Rapoartele prezentate managementului superior nu sunt dinamice si nu au capacitatea
de a oIeri Iacilitti drill-down pentru detalierea datelor. Ca urmare, cnd un raport
prezint o situatie de alarm sau de exceptie, decidentul nu poate vedea mai multe
detalii despre situatia respectiv. Odat rezolvat aceast problem, decidentii pot
obtine mai multe detalii atunci cnd au nevoie, iar analizele reIeritoare la tendinte si la
relatii cauzale vor Ii posibile.
Rapoartele care necesit date istorice sunt dificil de realizat. Datele
istorice despre clienti, produse si operatiuni Iinanciare nu sunt stocate n sistemele
66 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
operationale. ncercarea de a ncorpora datele mai vechi n noile rapoarte se poate lovi
de impedimentul nepotrivirii vechilor structuri de date cu cele actuale. Ca urmare,
raportele nu pot Ii produse la timp sau chiar deloc, iar decidentii nu vor avea
posibilitatea de a eIectua analize de trend de-a lungul unei perioade de timp mai mari.
Organizatia nu va Ii capabil s anticipeze evenimentele si schimbrile de
comportament; cererile consumatorilor vor veni ca o adevrat surpriz, iar
organizatia va trebui s se Iorteze pentru a le satisIace.
n plus, Iat de problemele anterioare care pot Ii rezolvate prin tehnologia
depozitelor de date, mai exist si alte motive care pot duce la aceast necesitate:
Sprijin pentru strategia organizatiei.
Sprijinirea organizatiei n mrirea proIitabilittii.
Date integrate.
Costurile eIorturilor curente sunt mari.
Concurentii Iolosesc deja tehnologia data warehouse.
Sprijin pentru strategia organiza(iei. Tehnologia depozitelor de date este un
Iactor cheie care contribuie la aplicarea cu succes a uneia sau a mai multor
componente ale strategiei, incluznd cresterea veniturilor, controlul costurilor.
Spijinirea organiza(iei n mrirea profitabilit(ii. Depozitul de date creste
gradul de Iocalizare si oIer posibilitatea unei mai bune perceptii asupra clientilor si
produselor.
Date integrate. Depozitul de date oIer o colectie integrat de date reIeritoare
la aIacerile ntreprinderii.
Costurile eforturilor curente. Costurile curente necesare producerii
rapoartelor programate standard sunt de obicei ascunse si greu de identiIicat. Un
studiu asupra acestor costuri poate conduce la rezultate care s sugereze necesitatea
unui depozit de date.
Concuren(ii folosesc deja tehnologia depozitelor de date. Faptul c unii
concurenti Iolosesc tehnologia data warehouse nu nseamn neaprat c este cea mai
bun, ns trebuie s dea serios de gndit managerilor organizatiei.
3.2.4. Care sunt costurile depozitelor de date?
Costurile asociate dezvoltarii, implementrii si ntretinerii unui depozit de
date se mpart de obicei n urmtoarele categorii:
Hardware;
Depozite de date 67
SoItware;
Servicii externe;
Personal propriu.
Costurile reIeritoare la hardware pot atinge uneori pn la 50 la sut din
valoarea ntregului proiect data warehouse. Se recomand Iolosirea unui server
separat pentru depozitul de date astIel nct operatiunile ce se eIectueaz n depozit s
nu aIecteze sistemele operationale. Sistemele operationale si decizionale pot Ii
conectate prin reteaua organizatiei n cazul n care se introduc instrumente automate
de extragere a datelor din sistemul operational sau cnd se Iolsoseste tehnica replicrii
datelor operationale.
Organizatiile care se bazeaz pe sisteme mainIrame pentru procesarea
tranzactiilor pot apela la tehnologia client/ server pentru solutiile data warehouse.
Costurile din aceast categorie sunt n general mai mari la nceputul
proiectului de dezvoltare a depozitului de date datorit achizitiilor noilor componente
hardware. Este cunoscut tendinta ca depozitul de date initial s se mreasc rapid,
ceea ce va necesita achizitii de noi componente. O modalitate eIicient de a reduce
costurile legate de hardware const n achizitia unei tehnologii client/server care s
aib un nalt grad de scalabilitate. Pe msura cresterii depozitului de date, vor Ii
necesare investitii doar pentru componentele care se adaug, Ir a mai Ii nevoie s se
nlocuiasc sau s se modiIice cele existente.
Software-ul cuprinde acele aplicatii si instrumente necesare pentru crearea,
conIigurarea, popularea, utilizarea si ntretinerea depozitului de date. Instrumentele
data warehouse moderne oIer diverse posibilitti la preturi variate. Necesittile
Iiecrei organizatii vor Ii satisIcute de o combinatie de instrumente, iar optiunea
Iinal trebuie s tin cont de dotarea tehnic de care dispune (sau poate dispune)
sistemul operational. Cheltuielile legate de aceast component pot varia ntre 25 si
30 din valoarea ntregului proiect.
Serviciile externe ale consultantilor sau ale dezvoltatorilor sistemului sunt
deseori necesare pentru a gestiona si integra componente diIerite ale depozitului de
date. Varianta apelrii la servicii externe se preteaz atunci cnd organizatia nu are
specialistii necesari si nici unele instrumente hardware sau soItware.
Apelarea la serviciile consultantilor este binevenit mai ales n Iazele de
nceput ale dezvoltrii proiectului depozitului de date, deoarece n aceste momente
68 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
personalul propriu nu este bine Iamiliarizat cu problemele speciIice ale tehnologiei
data warehouse. Costurile serviciilor externe pot atinge 30-35 din valoarea
ntregului proiect, dar se vor diminua considerabil n etapa de ntretinere a depozitului
de date prin scderea dependentei organizatiei de consultanta extern.
Costurile aIerente personalului propriu apar ca urmare a alocrii resurselor
umane proiectului de dezvoltare a depozitului de date. Alocarea timpului diIer n
Iunctie de etapa n care se aIl proiectul: astIel, personalul din compartimentul IT al
organizatiei va Ii solicitat n etapele de planiIicare, proiectare, implementare, populare
si ntretinere a depozitului de date; participarea utilizatorilor Iinali n Iaza de
planiIicare este, de asemenea, important. Pe parcursul ntregului proiect vor Ii
implicate cele trei personaje cheie: sustintorul proiectului, managerul IT si
managerul de proiect.
Costurile tipice pentru dezvoltarea unui depozit de date ntr-un interval de 3-6
luni se situeaz ntre 0.8 si 2 milioane dolari (vezi tabelul nr.3.1.), n Iunctie de
combinatia care se realizeaz ntre hardware, soItware si servicii de consultant.
Tabel nr. 3.1 - Costuri implicate n dezvoltarea unui depozit de date
Articole Minim
Pondere n
total
Maxim
Pondere n
total
lardWare 100.000 19.2 1.000.000 51.81
3ollWare 132.000 1.2 330.000 1Z.10
3erv|c|| exlerre 280.000 31.18 00.000 31.09
T0TAL 812.000 1.930.000
Sursa: Humphries, M., Hawkins, M., Dy, M., Data Warehousing. Architecture and
Implementation, Prentice Hall PTR, Upper Saddle River, New Jersey, 1999, p. 60.

3.2.5. Riscuri asociate unui proiect data warehouse
Riscurile tipice care se pot produce n timpul dezvoltrii unui depozit de date
pot Ii mprtite n urmtoarele categorii:
Riscuri organiza(ionale.
Riscuri tehnologice.
Riscuri legate de managementul proiectului.
Riscuri legate de proiectarea depozitului de date.
Depozite de date 69
3.2.5.1. Riscurile organiza(ionale
Aceste riscuri tin de att de structura echipei de dezvoltare, ct si de cultura
organizatiei. Sustintorul proiectului trebuie s provin din zona conducerii strategice
a aIacerii si nu din zona strategic IT. Avnd n vedere dimensiunea si scopul, o
initiativ data warehouse trebuie s Iie orientat pe aIacere, altIel organizatia va
considera ntregul eIort ca pe un experiment tehnologic. Sustintorul proiectului
trebuie s Iie o persoan care va utiliza depozitul de date si care si poate asuma
responsabilitatea initiativei.
Acest rol nu poate Ii delegat unui comitet. Din pcate, multe organizatii
preIer s stabileasc un comitet nsrcinat cu proiectul data warehouse pentru a
dispersa responsabilittile. Dac este stabilit un astIel de comitet, se recomand ca
presedintele comitetului s Iie sustintorul proiectului.
Riscurile organizationale provin si de la utilizatorii Iinali care pot obstructiona,
intentionat sau nu, evolutia proiectului. n Iunctie de cunostintele tehnice pe care le au
si de cultura organizational, utilizatorii vor Ii n msur s precizeze cu grade diIerite
de acuratete cerintele pe care le au, necesittile privind securitatea sistemului etc. O
comunitate de utilizatori care nu are cunostinte inIormatice sau nu este de acord cu
proiectul poate constitui o premis pentru un insucces.
3.2.5.2. Riscurile tehnologice
Aceste riscuri se reIer la tehnologiile selectate pentru planiIicarea si Iolosirea
depozitului de date. Riscurile tehnologice pot proveni att de la sistemul operational
actual, ct si din maniera n care se realizeaz integrrile noilor tehnologii n
arhitectura IT a organizatiei.
n aceast categorie se ncadreaz Iolosirea inadecvat a tehnologiilor data
warehouse, calitatea sczut a sistemelor operationale existente, utilizarea de
instrumente nepotrivite pentru utilizatorul Iinal.
Folosirea inadecvat a tehnologiilor depozitelor de date apare atunci cnd se
ncearc utilizarea lor n scopul rezolvrii problemelor operationale ale organizatiei
sau pentru a se implementa solutii n timp real. De asemenea, utilizarea mai multor
minidepozite de date disparate nu poate constitui un Iactor de succes sigur, deoarece
sistemul inIormational din cadrul organizatiei trebuie s Iunctioneze ntr-un cadru
unic.
70 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
Calitatea sczut a sistemelor operationale poate determina echipa de
dezvoltare a depozitului de date s-si concentreze atentia mai mult pe 'curtirea si
veriIicarea datelor de intrare, neglijnd esentialul depozitului de date. n acelasi timp,
un sistem operational deIectuos va ridica probleme la extragerea, transIormarea si
ncrcarea datelor n depozitul de date. Utilizatorii potentiali ai depozitului de date nu
vor Iace uz de el dac inIormatiile pe care le oIer sistemul sunt eronate sau dubioase.
Ceea ce conteaz Ioarte mult este perceptia asupra calittii datelor, indiIerent dac
datele sunt corecte sau nu.
Aria larg de instrumente pentru utilizatorii Iinali trebuie bine analizat nainte
de a decide ce instrument va Iolosi Iiecare categorie de utilizatori. Dac de exemplu
pentru conducerea executiv se va opta pentru un set de instrumente care s necesite
cunostinte inIormatice avansate, proiectul este cu sigurant sortit esecului. n acelasi
mod pot reactiona utilizatorii versati care se vor simti Irustrati n cazul n care
instrumentele de Iolosire si gestionare a depozitului de date vor Ii prea simple.
3.2.5.3. Riscurile ce (in de managementul proiectului
Aceste riscuri sunt prezente n majoritatea proiectelor, dar mai ales n privinta
proiectelor data warehouse, datorit resurselor implicate si complexittii crescute.
Unul din aceste riscuri este determinat de deIinirea nerealist a anvergurii proiectului.
Literatura de specialitate recomand ca un astIel de proiect s nceap cu o etap pilot
si apoi depozitul de date s Iie dezvoltat incremental. Specialistii consider c
organizatiile care mizeaz pe proiecte monolitice de amploare Ioarte mare vor
ntmpina diIicultti n gestionarea situatiilor care apar si vor avea sanse Ioarte mici
de a termina cu bine ceea ce au nceput. n contrast, dezvoltarea incremental reduce
riscurile si minimeaz pierderile.
Multe proiecte data warehouse au esuat datorit subestimrii timpului necesar
operatiunilor de extragere, integrare si transIormare a datelor. Desi poate prea
neobisnuit, este realist ca pentru aceste operatiuni s se aloce un timp important din
durata ntregului proiect. Practica a dovedit c pentru operatiunilor back-end
(extragere, integrare, veriIicarea calittii, agregare, ncrcare) trebuie s se aloce ntre
60-80 din durata proiectului, iar pentru operatiunile Iront-end (instrumente OLAP,
rapoarte, interogri) ntre 20-40 (vezi Iig.nr. 3.1.) Echipa de dezvoltare trebuie s
se concentreze atent pe partea de back-end deoarece pe ea se sprijin cealalt
Depozite de date 71
component (Iront-end) care nu poate Ii implementat pn cnd nu este Iunctional
prima.


Figura nr.3.1. Distributia tipic a eIorturilor de realizare a unui depozit de date
Sursa: Humphries, M., Hawkins, M., Dy, M., Data Warehousing. Architecture and
Implementation, Prentice Hall PTR, Upper Saddle River, New Jersey, 1999, p. 65.


Conducerea proiectului trebuie s se preocupe si de ceea ce se ntmpl
dincolo de implementarea depozitului de date: utilizatorii noi care au acces la
Iunctionalittile depozitului trebuie instruiti, utilizatorii vechi trebuie nstiintati despre
modiIicrile care apar si, de asemenea, se recomand o monitorizare a activittii
depozitului de date n primul an (contorizare nregistrri Irecvente, statistici despre
cutrile care se eIectueaz) pentru a optimiza structura nregistrrilor si interogrile.
3.2.5.4. Riscurile legate de proiectarea depozitului de date
Tehnologia data warehouse necesit un set nou de tehnici de proiectare care
diIer semniIicativ de practicile acceptate n privinta dezvoltrii sistemelor OLTP.
Echipa de proiectare trebuie s Iac o distinctie net ntre metodele Iolosite n cazul
sistemelor OLTP si cele de tip data warehouse. n timp ce sistemele OLTP mizeaz pe
normalizarea relatiilor si pe nregistrarea eIicient a tranzactiilor, depozitul de date
trebuie gndit ca un cub de date multidimensional care contine tabele denormalizate,
agregri, variabile etc.
72 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
O greseal Irecvent care se Iace const n alegerea gresit a gradului de
granularitate. Depozitul de date contine att date atomice ct si date sintetice
(agregate). O granularitate prea mare nu permite obtinerea rapoartelor detaliate de
care au uneori nevoie managerii, n timp ce un grad sczut de granularitate conduce la
necesitatea eIecturii unui numr mare de agregri si la capacitti sporite de stocare.
3.2.6. Cnd organiza(ia este pregtit pentru depozitul de date?
Desi nu exist reguli clare care s stabileasc dac o organizatie este sau nu
pregtit pentru o initiativ data warehouse, indiciile urmtoare pot aprecia n Ioarte
msur acest lucru:
Deciden(ii simt nevoia unei schimbri;
Utilizatorii cer date integrate pentru a putea lua
decizii;
Sistemele opera(ionale sunt stabile;
Exist personal care poate fi alocat unui proiect
data warehouse;
Exist fonduri care s finan(eze o astfel de
ini(iativ.
3.2.7. Care sunt rezultatele aplicrii depozitelor de date yi cum se
msoar ele
Rezultatele depozitului de date apar sub diverse Iorme si pot Ii apreciate prin
unul din urmtoarele moduri sau indicatori:
Sprijin pentru ob(inerea de noi rapoarte/interogri;
Reducerea timpului pentru ob(inerea informa(iilor
necesare;
Rapoarte generate de excep(ii;
Numr de utilizatori activi;
Frecven(a utilizrii depozitului de date;
Durata sesiunilor de utilizare a depozitului de date;
Depozite de date 73
Profilul interogrilor relizate de utilizatori;
Cererile pentru noi func(ionalit(i;
Schimbrile pe care le determin deciziile luate pe baza
informa(iilor extrase din depozitul de date.
3.3. ROLUL PERSONALULUI DE SPECIALITATE
Managerul IT este responsabil de gestiunea resurselor inIormationale si de
coordonarea cerintelor inIormationale la nivel strategic, decizional si operational.
Data warehousing cu zonele adiacente ale noilor tehnologii sunt dependente de
sistemele operationale si, n mod natural, solicitrile de resurse tehnologice si de
resurse umane trebuie s Iie sub jurisdictia managerului IT.
ntrebrile cele mai uzuale pe care le va pune managerul IT atunci cnd va lua
primul contact cu tehnologia data warehouse sunt urmtoarele:
Care este rolul managerului IT n sprijinirea procesului de
implementare a depozitului de date?
Cum va evolua depozitul de date?
Cine va Ii implicat ntr-un proiect data warehouse?
Care vor Ii noile abilitti pe care vor trebui s le capete salariatii?
Cu cti Iurnizori va trebui s lum legtura?
Cum vor Ii aIectate sistemele existente de proiectul data warehouse?
Cnd nu este oportun o initiativ data warehouse?
Cum se conduc si se gestioneaz activittile legate de proiectul data
warehouse?
3.3.1. Rolul managerului IT n sprijinirea procesului de
implementare a depozitului de date
Dup ce depozitul de date este pus n lucru, sunt necesare diIerite servicii care
s asigure succesul implementrii, cum ar Ii: ncrcarea regulat a depozitului de date,
ntretinerea aplicatiilor, optimizarea depozitului de date, sprijinirea utilizatorilor.
ncrcarea regulat a depozitului de date. Depozitul de date trebuie s Iie
permanent ncrcat cu date noi. Volumul de munc ce se depune pentru ncrcarea
datelor n depozit depinde de rezultatele Iazelor de extragere si transIormare a datelor
74 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
din sistemele operationale, precum si de Irecventa cu care se realizeaz actualizrile.
Aceast Irecvent este determinat de cerintele utilizatorilor si poate varia de la o zi la
o sptmn sau o lun, n Iunctie de necesitti. Activitatea de ncrcare a depozitului
de date cade n sarcina echipei de ntretinere a depozitului de date, echip care este
subordonat direct managerului IT.
Aplica(iile. Dup ce depozitul de date este implementat, departamentul IT va
Ii solicitat de diverse departamente ale organizatiei s realizeze aplicatii diverse care
s se sprijine pe continutul depozitului de date. Aceste aplicatii vor tinde s devin din
ce n ce mai personalizate, n Iunctie de cerintele speciIice Iiecrui grup de utilizatori.
Aplicatiile vor Ii dezvoltate de o echip care va Ii direct coordonat de ctre
managerul IT.
Optimizarea depozitului de date. Administratorul depozitului de date trebuie
s monitorizeze activittile legate de Iolosirea datelor, n sensul realizrii unor
statistici reIeritoare la interogrile cele mai Irecvente care se eIectueaz si la Irecventa
apelrilor. Structura depozitului va Ii apoi raIinat si optimizat, n special n zona
agregrilor stocate si a strategiilor de indexare.
Sprijinirea utilizatorilor. Ca pentru orice sistem inIormational din cadrul
unei organizatiei, trebuie s existe o component 'help desk care s oIere
utilizatorilor rspunsuri si indicatii utile la problemele cu care se conIrunt n
exploatarea depozitului de date. ntrebrile cele mai Irecvente vor Ii analizate si se vor
lua msuri pentru mbunttirea sistemului.
3.3.2. Cum va evolua depozitul de date?
Una dintre deciziile pe care trebuie s le ia cel ce planiIic depozitul de date
este aceea reIeritoare la modul n care va evolua sistemul. Fiecare nou extensie a
sistemului va determina cresterea complexittii (domeniul de acoperire, gestiunea
depozitului de date, optimizarea etc.). De regul, evolutia unui depozit de date are n
vedere urmtoarele zone: datele, utilizatorii, aIacerile, Iunctionalitatea aplicatiei.
Datele. Evolutia n acest domeniu rezult ca urmare a lrgirii domeniului pe
care-l acoper depozitul de date, desi o descrestere nu este imposibil. Subsistemul de
extragere a datelor va Ii modiIicat n cazul n care se modiIic sursele primare sau
dac sunt avute n vedere noi componente ale sistemului operational.
Depozite de date 75
Utilizatorii. Cu timpul, noi utilizatori vor avea acces la Iunctionalittile
depozitului de date, iar utilizatorii deja existenti vor Ii instruiti pentru a putea Iolosi
noile capacitti oIerite de sistem.
Afacerea. ModiIicrile care apar n domeniul de aIaceri al organizatiei vor
produce schimbri n sistemele operationale, vor determina noi necesitti de
monitorizare si analiz, ceea ce va duce la modiIicare depozitului de date.
Func(ionalitatea aplica(iei. Noi Iunctionalitti vor putea Ii adugate la
instrumentele OLAP deja existente pentru a satisIace cerintele utilizatorilor.
3.3.3. Cine va fi implicat ntr-un proiect data warehouse?
Fiecare proiect data warehouse are o echip cu diIerite abilitti si roluri (vezi
Iig.nr. 3.2). Evolutia personalului alocat proiectului pe parcursul dezvoltrii
depozitului de date este esential. Nu toate rolurile din echip pot Ii ndeplinite de
oameni din aIara organizatiei; se recomand ca urmtoarele roluri s Iie ndeplinite de
personalul propriu al organizatiei:
Comitetul de conducere
Grupul reprezentativ al utilizatorilor
Managerul de proiect
Analistii
Proiectantul depozitului de date
Administratorul metadatelor
Programatorii (pentru extragere, transIormare si ncrcare date)
Administratorul depozitului de date
Sustintorul proiectului
Aceeasi persoan poate ndeplini simultan mai multe roluri, ns pentru
eIicient se recomand separarea activittilor.
Comitetul de conducere este compus din reprezentanti ai nivelului executiv
superior pentru Iiecare tip de utilizatori care va accesa depozitul de date. Sustintorul
proiectului este membru al acestui comitet. n cele mai multe cazuri el este seIul
acestui comitet. Comitetul de conducere trebuie s Iie deja Iormat la momentul
nceperii implementrii depozitului de date, totusi existenta comitetului de conducere
nu este o conditie pentru planiIicarea depozitului de date. n timpul implementrii,
comitetul de conducere primeste rapoarte periodice de la echipa proiectului si
76 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
intervine pentru a redirecta eIorturile de proiectare n concordant cu obiectivele
stabilite.
Grupul utilizatorilor trebuie s Iie reprezentativ pentru utilizatorii comuni, n
mod curent nivelul managerial mediu si analisti. Utilizatorii Iurnizeaz intrrile critice
pentru proiectele data warehousing prin speciIicarea detaliat a datelor cerute, a
regulilor de aIaceri, a interogrilor predeIinite, a Iormatelor de rapoarte. De asemenea,
grupul utilizatorilor testeaz iesirile din depozitul de date. Nu este neobisnuit pentru
grupul de utilizatori s cheltuie pn la 80 din timp pentru proiect, n special pe
durata analizei cerintelor si activittii de proiectare. La sIrsitul proiectului pn la
80 din timp este aIectat pentru testarea utilittii si corectitudinii depozitului de date.
Reprezentantii utilizatorilor Iinali particip la ntlnirile curente si la interviuri
cu echipa care lucreaz la depozitul de date.



Figura nr.3.2. Structura echipei de dezvoltare a proiectului data warehouse

Conductorul depozitului raporteaz comitetului de conducere, asigurnd c
proiectul evolueaz n directia bun. Este responsabil pentru ntlnirile stabilite la
termenele de predare a proiectului. Conductorul depozitului de date este manager
economic dar este responsabil de deIinirea strategiei depozitului de date (cu asistenta
managerului de proiect) si de planiIicarea si gestiunea implementrii depozitului de
date la nivel operational. De asemenea, el comunic obiectivele depozitului de date
altor departamente ale organizatiei.
Depozite de date 77
Managerul proiectului este o persoan care are o experient bogat n
domeniul IT si n gestiunea proiectelor. Managerul de proiect colaboreaz cu
conductorul depozitului si deIinesc mpreun strategia depozitului de date.
Managerul de proiect este responsabil de implementarea proiectului.
Analiytii economici Iac legtura dintre utilizatorii si tehnicienii din echipa de
proiectare. Prin intervievarea membrilor grupului de reIerint analistii identiIic,
documenteaz si modeleaz cerintele curente ale activittii. Analistii joac un rol
critic n gestiunea asteptrilor utilizatorilor Iinali.
Arhitectul depozitului de date elaboreaz si ntretine view-urile de date ale
depozitului. Analizeaz cerintele inIormationale speciIicate de utilizatori si
proiecteaz structurile de date din depozit. Arhitectul depozitului de date are un rol
sporit n evolutia depozitului. La Iiecare parcurgere a spiralei de evolutie arhitectul
trebuie s rezolve problemele genrate de extinderea depozitului.
Administratorul de metadate deIineste metadatele standard si gestioneaz
dictionarul de metadate din depozit.
3.3.4. Care vor fi noile abilit(i pe care vor trebui s le capete
salaria(ii?
ProIesionistii IT si utilizatorii Iinali vor trebui s-si nsuseasc noi abilitti.
Acestea sunt descrise n rndurile ce urmeaz.
Aoi abilitji pentru profesioniytii I1
Noi abilit(i referitoare la proiectarea bazelor de
date impuse de trecerea la noua tehnologie a
depozitelor de date;
Noi capabilit(i tehnice impuse de modificrile
hardware yi software;
Familiarizarea cu noi instrumente de proiectare yi
gestiune a datelor;
Cunoayterea proceselor de afaceri din firm;
Sprijinirea utilizatorilor finali din organiza(ie.
78 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
ProIesionistii IT trebuie s-si Iocalizeze atentia spre satisIacerea cerintelor
inIormationale ale utilizatorilor.
Aoi abilitji pentru utilizatorii finali
Abilit(i legate de folosirea calculatorului pentru
a avea acces direct la informa(iile oferite de
depozitul de date;
Cunoayterea proceselor de afaceri din organiza(ie;
Cunoayterea datelor pentru a putea ob(ine
informa(iile care sunt necesare.
3.3.5. Care sunt furnizorii poten(iali de componente ale tehnologiilor
data warehouse?
Un proiect data warehouse, ca orice alt proiect IT, necesit o combinatie de
hardware, soItware si servicii externe care nu pot Ii oIerite de un singur Iurnizor. O
posibilitate ar Ii de a angaja un integrator de sisteme care s se ocupe de contactarea
Iurnizorilor, dar alte organizatii preIer contactul direct cu Iiecare Iurnizor asumndu-
si si sarcina integrrii. Furnizorii pot Ii mprtiti n urmtoarele categorii:
Furnizori de hardware si sisteme de operare
Furnizori pentru instrumente de extragere si transIormare a datelor
Furnizori de sisteme de gestiune a bazelor de date relationale
Furnizori de servicii de integrare si consultant
Furnizori pentru instrumente OLAP, acces la date, asistare a deciziilor.
3.3.6. Cum vor fi afectate sistemele existente de proiectul data
warehouse?
Sistemele operationale existente constituie sursa pentru datele din depozit.
Extragerea datelor poate avea loc doar n pauzele sistemului operational, de regul
dup orele de lucru normale. Dac aceste pauze sunt suIiciente, activittile legate de
depozitul de date nu ar trebui s aIecteze operatiunile cu caracter curent.
Depozite de date 79
3.3.7. Cnd nu este oportun o ini(iativ data warehouse?
Nu toate organizatiile sunt pregtite pentru o initiativ data warehouse;
cazurile cele mai Irecvente sunt urmtoarele:
Sistemele operationale nu sunt corespunztoare (date neconsistente,
sisteme instabile, integrare slab etc.).
Cerinta major const n integrarea operational (un depozit de date nu
poate avea rezultate dac sistemele operationale nu sunt bine integrate).
3.3.8. Cum se conduc yi gestioneaz activit(ile legate de proiectul
data warehouse?
Exist mai multe moduri de a gestiona si controla un proiect data warehouse:
Jaloane (milestones) bine deIinite care trebuie atinse, asa cum se
procedeaz n managementul proiectelor;
Dezvoltare incremental, pe Iaze;
PlaniIicarea scalabilittii;
Motivarea membrilor echipei (premii, gratiIicatii, evidentieri etc.).
3.4. CONDUCEREA PROIECTULUI
La Iel ca si ceilalti membri cheie ntr-o initiativ data warehouse, managerul
de proiect va avea propriile ntrebri legate de acest domeniu:
n ce manier va evolua un proiect data
warehouse?
Ce tehnologii sunt implicate?
Se pot folosi n continuare bazele de date
rela(ionale pentru depozitul de date?
Prin ce difer un proiect data warehouse fa( de
alte proiecte IT?
Care sunt factorii de succes pentru un proiect
data warehouse?
80 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
3.4.1. n ce manier va evolua un proiect data warehouse?
Literatura de specialitate recomand trei etape importante n evolutia unui
depozit de date:
Activitatea de planiIicare a depozitului de date;
Implementarea unui depozit de date pilot;
Extinderea incremental a Iunctionalittilor.
n cadrul etapei de planificare vor Ii avute n vedere urmtoarele activitti:
analiza cerintelor decizionale;
auditul sistemelor surs;
proiectarea preliminar a arhitecturii logice si Iizice a depozitului de
date.
Implementarea unui depozit pilot are avantajul c este mai usor de gestionat si
de realizat; complexitatea creste proportional cu numrul surselor de date, al
utilizatorilor si al locatiilor n care se extinde proiectul.
Extinderea incremental a func(ionalit(ilor se poate Iace n mai multe
moduri: top-down, bottom-up, back-end, Iront-end.
Top-down. Se porneste de la analiza cerintelor decizionale si se continu pn
la nivelul datelor. De remarcat c toate cerintele decizionale sunt ntr-o continu
schimbare, deci trebuie evitat capcana analizei prea detaliate.
Bottom-up. n timp ce o parte din membrii echipei realizeaz analiza top-
down, altii vor analiza cu precdere datele externe si sursele interne. Utilizatorii Iinali
trebuie s Iie inIormati despre limitele sistemului, limite impuse de sistemele surs.
Back-end. n acest caz se au n vedere operatiunile de extragere, integrare,
transIormare, agregare si ncrcare a depozitului de date.
Front-end. Principalele obiective le constituie extinderea Iunctionalittilor
instrumentelor OLAP, a rapoartelor si a interogrilor care se pot eIectua asupra
depozitului de date.
3.4.3. Ce tehnologii sunt implicate?
Pentru a Iace posibil dezvoltarea unui depozit de date sunt Iolosite cteva
tipuri de tehnologii:
Depozite de date 81
Sisteme surs. n aceast categorie sunt incluse sistemele operationale
ale ntreprinderii, ns depozitul de date poate ncorpora si date din
surse externe.
Tehnologii de extragere, integrare yi transformare. Aceste
instrumente extrag si reorganizeaz datele din sisteme surs variate; de
asemenea, instrumentele diIer din punct de vedere al complexittii,
Iunctionalittii si pretului.
Instrumente pentru calitatea datelor. Acestea au rolul de a identiIica
si corecta erorile datelor din sistemele surs. Din neIericire, majoritatea
activittilor de 'curtare a datelor nc se eIectueaz manual.
Tehnologii pentru stocarea datelor. Datele din depozitul de date sunt
stocate printr-un sistem de gestiune a bazelor de date, care poate Ii
relational (Oracle, InIormix, Sybase etc.) sau multidimensional
(Essbase, BrioQuery, Express Server etc.).
Tehnologii de accesare a datelor. n aceast categorie sunt incluse
instrumente destinate utilizatorilor Iinali (sisteme de generare a
graIicelor, instrumente pentru data mining, rapoarte etc.).
Instrumente pentru modelarea datelor. Aceste instrumente sunt
Iolosite pentru a genera si ntretine modelul datelor din sistemul
operational si din depozitul de date.
3.4.3. Cum pot fi folosite bazele de date rela(ionale pentru depozitele
de date?
n literatura de specialitate prerile sunt mprtite n privinta tehnologiei de
stocare a datelor dintr-un depozit de date. La ora actual exist clasica posibilitate a
bazelor de date relationale precum si varianta bazelor de date multidimensionale.
Alegerea Iinal trebuie Icut tinnd seama de costurile si perIormantele Iiecrei
variante. AstIel, modelul relational este potrivit n cazul n care se are n vedere o
economie de spatiu de memorare, n timp ce modelul multidimensional se preteaz
pentru timpi de rspuns Ioarte mici la interogrile care se Iormuleaz. De asemenea,
modelul multidimensional are avantajul c poate stoca si valori agregate.|
n conIormitate cu tehnolgia de stocare aleas, se vor dezvolta si instrumente
corespunztoare pentru utilizatorul Iinal (ROLAP Relational OLAP sau MOLAP
Multidimensional OLAP).
82 Capitolul 3, Implicarea personalului n aplicarea depozitelor de date
3.4.4. Diferen(e ale proiectelor data warehouse fa( de alte proiecte
IT?
Deoarece majoritatea activittilor inIormatice s-au concentrat asupra cerintelor
operationale, proIesionistii IT au o tendint natural de a aplica aceleasi metodologii
sau tehnici n proiectele data warehouse. Totusi, trebuie avute n vedere deosebirile
Iat de proiectele 'clasice:
Un proiect data warehouse nu este un proiect de implementare a
unui produs-program. Acest lucru se datoreaz Iaptului c un depozit
de date necesit utilitare si instrumente soItware care sunt disponibile
de la Iurnizori diIeriti. n prezent nu exist nc un singur produs care
s poat automatiza ntregul eIort de dezvoltare a unui depozit de date.
Un depozit de date nu se va opri niciodat din evolu(ie; el se
modific odat cu organiza(ia. Depozitul de date trebuie s se
adapteze continuu la noile cerinte inIormationale ale decidentilor.
Depozitele de date sunt imense. Fr a exagera, ntr-o organizatie,
dimensiunile depozitului de date tind s creasc pn la cote
impresionante datorit acumulrii datelor n timp si a stocrii valorilor
agregate. Gestionarea unui astIel de volum de date este o rspundere
urias.
3.4.5. Care sunt factorii de succes pentru un proiect data warehouse?
Desi lista de mai jos nu cuprinde totalitatea Iactorilor de succes, ea cuprinde
acele aspecte esentiale pentru ca un proiect data warehouse s Iie o reusit:
PlaniIicarea corect a proiectului;
Dezvoltarea unui depozit de date pilot
Dezvoltarea incremental a depozitului de date;
Implicarea activ a personajelor cheie (sustintorul proiectului,
managerul IT, managerul proiectului);
Comunicarea si antrenarea utilizatorilor;
Managementul atent al schimbrilor.