Business Intelligence - Noua Generaţie de Sisteme de Asistare A Deciziilor

Business Intelligence – noua generaţie de sisteme de asistare a deciziilor 26
Business Intelligence – noua generaţie

de sisteme de asistare a deciziilor
Activitatea economică generează un „ocean de date” (sau, cum le place altora
să spună, „suntem aşezați pe un munte de date” – „ce este mai mare: oceanul sau
muntele?” ră mâ ne să aleagă fiecare). Fiecare dată reprezintă o pă rticică a afacerii şi
se gă seşte în diferite locații ori departamente, uneori în mai multe regiuni
geografice. Adesea, este captivă pe un hard disk dezafectat sau într‐o arhivă pră fuită .
În afaceri, adevărul – adică slăbiciunile, punctele tari şi tendinţele – este în date. Prin
sistemele Business Intelligence sunt adunate toate datele, acestea sunt prelucrate în
informații, care bine analizate, pot fi utilizate în luarea deciziilor şi în final puse în
acțiune1.
În condițiile actualului mediu de afaceri, calitatea şi promptitudinea
informațiilor reprezintă pentru firmă nu o alegere între profit şi pierdere, ci o
chestiune de supraviețuire sau faliment. Beneficiile unui sistem Business Intelligence
(BI) sunt evidente – analiştii sunt optimişti, ară tâ nd că în anii care vin milioane de
oameni vor folosi zi de zi instrumente vizuale de analiză şi BI. Piața este deja
saturată în ceea ce priveşte oferta de aplicații analitice dintre cele mai diverse, care
pot efectua tot soiul de analize în sprijinul procesului decizional la toate nivelurile.
În jurul acestui concept s‐au lansat alți termeni legați de analiza
performanțelor organizaționale, precum BPM – Business Performance Management,
CPM – Corporate Performance Management, EPM – Enterprise Performance
Management, BA – Business Analytics, câ t şi BAM – Business Activity Monitoring,
Balanced Scorecards sau Performance Dashboards, unele incluse în BI, altele râ vnind
să ‐l înlocuiască.
8.1. Definirea conceptului de Business Intelligence

şi a beneficiilor sale
Ră dăcinile acestui concept se gă sesc în anii ’70 în sistemele de raportare ale

mainframe‐urilor, câ nd rapoartele erau statice, bidimensionale şi fă ră facilită ți
analitice. Dorința şi cererea de sisteme de raportare dinamice, multidimensionale,
cu suport pentru decizii predictive, au determinat dezvoltarea BI, care a devenit
realitate odată cu emergența noilor tehnologii. Analistul Howard Dresner, de la
Gartner Group, a propus utilizarea termenului BI 2 în 19893. La momentul acela, puțini
au înțeles ce a vrut să spună Dresner, termenul a ră mas un timp într‐un grup select
de dezvoltatori, în timp ce vocile opoziției au spus despre el că este un oximoron 4.
Evoluția din anii ’90 a extins şi perfecționat domeniul BI şi a confirmat previziunea
1 E. Vitt, Business Intelligence: Making better decisions faster, Microsoft Press, 2002.
2 La momentul respectiv, se utilizau mai ales termenii legați de tipologia sistemelor informaționale: DSS
(sisteme de asistare a deciziilor) sau EIS (sisteme informaționale executive). Dresner a propus
termenul Business Intelligence pentru a defini un sistem informatic bazat pe analiza cantitativă a
datelor, care oferă rezultatele în diverse forme de prezentare.
3 Vezi referirile la http://www.computerworld.com/s/article/266298/BI_at_age_17
4 Şi disputa pe această temă continuă, părerile sunt în continuare împărțite; vezi
http://blogs.techrepublic. com/decisioncentral/?p=142 sau
http://www.informationweek.com/blog/main/archives/2008/07/ business_ intell_2.htm
lui Dresner, conform că reia „BI va deveni parte integrantă a sistemului

informațional al întreprinderii"5.
Înainte de a defini BI, o să spunem ce nu este şi ce nu face BI, adică prelucrarea
tranzacțiilor. Cele mai comune aplicații economice se regă sesc în sistemele de
prelucrare a tranzacţiilor. Acestea au menirea de a înregistra „tot ce mişcă ” într‐o
întreprindere şi de a întreține bazele de date operaționale. Modulele ERP de bază
lucrează în acest fel, ca şi unele componente ale sistemelor SCM ori CRM. Un sistem
de prelucrare a tranzacțiilor (SPT) este un sistem informatic în care calculatorul
ră spunde imediat cererilor utilizatorului6. Fiecare cerere este considerată o
tranzacţie şi se va materializa prin înregistrarea unui eveniment concret, precum o
intrare de bunuri în depozit sau plata unui furnizor. Cu alte cuvinte, o tranzacție
determină adă ugarea de date în una sau mai multe tabele ale bazei de date de o
manieră completă, pe baza unor reguli şi validă ri prestabilite. Pe câ t de eficient
lucrează un SPT la întreținerea bazelor de date ale întreprinderii, pe atâ t de greu îi
este să ră spundă interogă rilor ad hoc şi să analizeze datele stocate. Bă trâ nele
mainframe‐uri ajunseseră să fie numite „găuri negre”, căci înghițeau volume imense
de date, dar greu puteai scoate ceva înapoi, cu excepția rapoartelor predefinite,
obținute periodic. Odată cu arhitectura client/server, sistemele ERP au adus sisteme
de raportare mai prietenoase, dar limitele s‐au menținut, astfel că s‐au că utat noi
soluții software care să ‐i mulțumească pe utilizatorii manageri. S‐a dorit şi s‐a
realizat trecerea de la OLTP la OLAP, prin depozite de date, analiză
multidimensională şi aplicații analitice, ajungâ nd în noul mileniu la consacrarea
termenului de business intelligence.
Pornind de la acest context de apariție, unii autori7 definesc BI ca sisteme
informaţionale care îi asistă pe manageri şi alţi utilizatori în analiza activităţilor
trecute şi curente şi în previziunea evenimentelor viitoare. Spre deosebire de SPT, BI
nu sprijină activită țile operaționale precum înregistrarea comenzilor sau
prelucrarea mişcă rilor de stocuri, ci oferă suport managerial prin informare, analiză ,
planificare şi control8.
Într‐o altă definiție9, business intelligence constituie o arhitectură şi o
colecţie de aplicaţii şi baze de date operaţionale integrate, precum şi de sisteme de
asistenţă a deciziilor, care furnizează utilizatorilor acces mai uşor la datele despre
afacere. Aplicațiile BI de asistare a deciziilor facilitează multe activită ți, incluzâ nd şi
analiză multidimesională , data mining, capacitatea de previziune, analiza afacerii,
facilită ți de interogare, raportare, realizare a graficelor, analiză geospațială,
managementul cunoştințelor etc.
5 H. Dresner, Why enterprises must make business intelligence an imperative, 2001, raport disponibil la
http://www.gartnergroup.com
6 Termenul original care descrie aceste sisteme este Online Transaction Processing (OLTP).
7 D. Kroenke, D. Auer, Database concepts, Pearson Education, 2008, p. 350.
8 D. Airinei, D. Homocianu, „DSS vs. Business Intelligence”, The Proceedings of the International
Economic Conference: Integrative Relations between the European Union Institutions and the Member
States, Lucian Blaga University Publishing House, Sibiu, 2008.
9 L. Moss, S. Atre, Business Intelligence Roadmap, Addison‐Wesley Professional, 2003, p. 14.
Deşi este legat de aplicațiile de întreprindere, în opinia noastră BI nu este un

produs sau un sistem, ci este un conceptumbrelă10, care „adăposteşte” arhitecturi,
aplicaţii şi baze de date. Menirea sa este accesul câ t mai simplu la date al
utilizatorilor dintr‐o organizație prin accesarea interactivă şi în timp real a datelor,
manipularea şi analiza acestora. Prin analiza datelor istorice, BI realizează o
valoroasă introspecție asupra activită ților şi situațiilor de afaceri, iar managerii sunt
sprijiniți concret în luarea deciziilor prin informații de esență , inclusiv cele de
comportament şi de previziune.
Cheia înțelegerii BI stă în înțelegerea modului în care datele sunt prelucrate în
informații şi cum sunt ele apoi analizate şi în încadrarea acestor procese în
arhitectura, instrumentele şi aplicațiile BI. Trebuie lă murit faptul că BI nu produce
date, ci utilizează datele produse de aplicațiile de întreprindere: ERP, CRM, SCM etc.
În ultimele două decenii, în special în anii ’90, în organizații s‐au adunat
volume imense de date în cadrul nou‐implementatelor sisteme ERP, bazate pe OLTP.
A urmat firesc nevoia de a reorganiza aceste date în vederea valorifică rii lor: s‐au
construit depozite de date şi magazii de date, au fost implementate instrumente ETL
(extragere‐transformare‐încă rcare) pentru exploatarea acestora. Totuşi, specialiştii
sunt de pă rere că, şi în aceste condiții, prea puține date au fost transformate în
informații, iar cele efectiv utilizate ca suport decizional au fost şi mai puține. Cauza?
Lipsa instrumentelor potrivite pentru gă sirea şi analiza datelor. BI a acoperit această
lipsă.
„Drumul” de la datele aflate în sistemele informatice ale organizației la decizia
luată de omul de afaceri, trecâ nd prin depozite de date, instrumente ETL şi
instrumente de raportare şi analiză specifice, este ilustrat în figura 8.1, într‐o
adaptare după W.A. Giovinazzo11.
Astă zi, vorbim deja despre sisteme „tradiționale” de business intelligence,
livrate prin implementă ri clasice client/server şi sisteme moderne, cu implementare
bazată pe web şi oferită utilizatorului prin conexiuni internet sau intranet, precum şi
aplicații BI optimizate pentru dispozitive mobile, pentru smartphone sau e‐mail.
Cele mai importante domenii de aplicare a soluţiilor BI sunt:
 raportă ri generale;
 analiza vâ nză rilor şi marketing;
 planificare şi previziune;
 consolidare financiară ;
 bugetare;
 analiza profitabilită ții.
Efectele instală rii unui sistem BI sunt uimitoare, deoarece acesta produce
informația care trebuie la momentul la care aceasta este necesară , asigurâ nd unul
dintre ingredientele succesului în afaceri. BI este arta de a şti şi de a valorifica
informațiile, câ ştigâ nd avantaje competiționale. BI poate oferi ră spunsuri la
10 Ideea de termen „umbrelă ” îi aparține lui M. Raisinghani, autor al uneia dintre primele că rți de succes
în domeniul BI: Business Intelligence in the digital economy (The Idea Group, 2004).
11 W.A. Giovinazzo, Internet – Enabled Business Intelligence, Prentice Hall, 2002, p. 23.
problemele esențiale ale unei organizații, ajutâ nd‐o să ia decizii pentru rezolvarea
acestora. Gă sirea ră spunsurilor se bazează pe analiza şi compararea datelor istorice,
atâ t a celor create în cadrul organizației, câ t şi a datelor din surse externe. Adunarea
şi analiza acestor date permit înțelegerea tendințelor afacerii, a punctelor tari şi a
slă biciunilor, analiza competitorilor şi a situației de pe piață .
Sursa: Mă ză reanu, V., „«Inteligență » în Business Intelligence”, Analele Ştiinţifice ale

Universităţii Alexandru Ioan Cuza, Iaşi, Tomul LII/LIII, 2005/2006, p. 362.
Figura 8.1. De la date din sistemele operaţionale la strategii de afaceri
Beneficiile utiliză rii sistemelor BI pot fi sistematizate astfel:

 rapoarte mai corecte, obținute mai rapid;
 îmbună tă țirea procesului decizional;
 apropierea de clienți;
 venituri mai mari;
 economii de costuri IT şi non‐IT.
Sondajele de opinie (OLAP 3 Report, disponibil la adresa
www.survey.com/olap) asupra beneficiilor BI sunt încurajatoare: 60% dintre
companiile care au implementat un sistem BI spun că şi‐au atins obiectivele, iar
19%, chiar că le‐au întrecut (vezi şi tabelul 8.1). Într‐un alt studiu, realizat de
Eckerson 2003, pe primele locuri s‐au situat: economia de timp (60%), obținerea
unei singure versiuni a adevă rului (59%), strategii şi planuri mai bune (57%) şi un
proces decizional îmbună tă țit (56%). Aşa cum se poate observa, multe dintre
beneficiile BI sunt intangibile, motiv pentru care nu se recomandă o analiză de
fezabilitate sub raportul costurilor în cazul acestor proiecte.
Beneficiarii soluțiilor BI sunt unanimi în privința rezultatelor implementă rii
acestora vizavi de implementarea altor soluții din familia ERP. Beneficiile sunt
apreciate ca fiind mai mari şi vizibile mai rapid. Totuşi, trebuie să ară tă m că
beneficiile BI se clă desc pe cele ale ERP – acestea oferă datele necesare constituirii
depozitelor de date. Aşa cum am mai ară tat, BI scot la iveală informațiile esențiale
din sistemele ERP, oferind un excelent suport decizional, dar nu ar avea nicio şansă
dacă depozitele nu ar fi corect alimentate cu toate datele organizației.
Tabelul 8.1
Beneficiile BI conform OLAP 3 Report
Beneficii % companii care leau realizat
Rapoarte mai rapide şi mai corecte 81
Proces decizional îmbună tățit 78
Relații cu clienții îmbună tățite 56
Venituri mai mari 49
Economii de costuri non‐IT 50
Economii de costuri IT 40
Promovarea acestui nou tip de „inteligență economică ” nu i‐a lă sat indiferenți

pe managerii organizațiilor. Un aspect este deosebit de important în ceea ce priveşte
achiziția unui sistem BI: nefiind un produs „cu mă rime universală ”, nu se potriveşte
la fel tuturor beneficiarilor, fiecare organizație este unică în privința proceselor
economice şi a regulilor de afaceri. Simpla personalizare sau localizare a aplicațiilor
nu este suficientă pentru a implementa un sistem BI eficient.
Alegerea şi implementarea sistemului BI potrivit trebuie să aibă în vedere
cerințele funcționale şi nevoile utilizatorilor, aspectele tehnice, precum şi bugetul.
Convergența dintre nevoile organizației şi caracteristicile sistemului ales este
esențială pentru succesul proiectului.
8.2. Arhitectura şi componentele unui sistem BI

Dacă primele sisteme de BI erau alcă tuite în principal din depozitul de date, în
jurul că ruia se brodau diverse instrumente de analiză , astă zi ele au o arhitectură
mult mai complexă. Prezentarea noastră se concentrează asupra componentelor
principale ale acesteia şi detaliză într‐un paragraf distinct depozitul de date, care
ră mâ ne piesa centrală a unui sistem de BI.
8.2.1. Componentele unei soluţii BI
Un sistem BI are patru componente importante:

 depozitul de date, care este sursa de date a sistemului;
 aplicaţii analitice (business analytics), o colecție de instrumente pentru
manipularea, mineritul şi analiza datelor din depozitul de date;
 business performance management (BPM) pentru monitorizarea şi analiza
performanței;
 interfaţa utilizator.
Relația dintre aceste componente este ilustrată în figura 8.2. Se poate observa
că există o zonă tehnică ce cuprinde depozitul de date, crearea şi întreținerea lui, o
zonă a analizei în care activează utilizatorii curenți, şi o a treia zonă de performanță
şi strategie, în care top‐managerii stau de regulă în fața unui tablou de bord.
Sursa: Adaptare după Eckerson, W., Smart companies in the 21st Century: the secrets of creating
successful Business Intelligence solutions, The Data Warehousing Institute, 2003, p. 32.
Figura 8.2. Arhitectura unui sistem Business Intelligence
Într‐un sistem BI se regă seşte o combinație de arhitecturi şi tehnologii

software. În structura specifică BI12, sunt reunite urmă toarele instrumente (vezi
figura 8.3): depozite şi magazii de date (Data Warehouse, Data Mart), ETL (Extract
Transfer Load), instrumente de interogare şi raportare (Reporting and Query),
instrumente de vizualizare (data visualization), tabloul de bord (dashboard), OLAP
(OnLine Analytical Processing), minerit de date (Data Mining), sisteme de alertare şi
notificare (alerting and notification systems), care vor fi analizate pe scurt în
continuare.
Depozite de date. Diversele surse de date (OLTP, ERP, CRM, SCM, alte
aplicații de întreprindere, surse externe) înseamnă efectiv baze de date diferite, cu
formate şi structuri de date specifice. Reunirea acestora este deosebit de
importantă , de aceea depozitul de date (DD), care asigură captarea şi unificarea
datelor, este considerat jucă torul numă rul 1 în sistemul BI, cel mai însemnat şi
mai costisitor.
„Pă stră torul” tuturor datelor sprijină procesul de luare a deciziilor pentru
conducerea tactică şi operațională că reia îi oferă variante multiple de vizualizare şi
analiză a datelor, dar se mulează şi pe cerințele informaționale ale top‐managerilor.
Datele extrase din depozit la nivel departamental sunt adunate în aşa‐numita
magazie de date (data mart), ce asigură accesul mai rapid şi mai simplu (exemple:
date marketing, date producție, date vâ nză ri etc.). Uneori, se confundă DD şi
funcțiunile BI. Diferența este că DD poate funcționa în afara sistemului BI. Invers nu
se poate. Apare firesc întrebarea „de ce mai avem nevoie de BI?”. Pentru că valorifică
la maximum potențialul DD – infrastructura BI este completă , oferind, pe de o parte,
flexibilitatea de a alege între diferite instrumente, iar pe de altă parte, asigurarea
finalită ții, prin valorificarea informațiilor obținute.
12C. Kelley, „Navigating Business Intelligence – An Architected Data Approach”, 2004, disponibil la
http://www.businessintelligence.com
Explorare
Instrumente
Data Mining
CRM
DD
ETL
CPM
ETL
ETL
BSC
Sisteme-sursă
Sisteme sursă BDO Cunoaştere
(baze de date
operaţionale)
Tablou de bord
Figura 8.3. Vedere structurală asupra sistemelor Business Intelligence
Instrumente ETL. Procesul de populare a DD se realizează prin activită țile

ETL: extragere, transformare, încă rcare, ce constituie de fapt trei funcțiuni distincte.
Prima, extragerea, citeşte datele dintr‐o sursă şi extrage setul de date dorit. Apoi,
funcțiunea de transformare lucrează cu datele extrase – utilizâ nd reguli ori tabele de
căutare şi creâ nd combinații cu alte date – converteşte datele în forma dorită . În fine,
încă rcarea scrie datele obținute în baza de date‐țintă , asigurâ nd conversia între
bazele de date şi migrația de pe o platformă pe alta.
Instrumente de raportare şi vizualizare. Una dintre funcțiunile principale
ale BI, raportarea, desemnează procesul de accesare a datelor, formatarea acestora
şi livrarea lor sub formă de informații. Rapoartele şi cererile sunt obținute cu
ajutorul limbajului de interogare SQL. Instrumentele de vizualizare îi ajută pe
utilizatori să „vadă ” mai clar datele. Forma preferată o constituie reprezentă rile
grafice. Cu ajutorul acestor instrumente sunt interpretate informațiile şi relațiile
dintre date. Pot fi combinate reprezentă ri diferite de seturi de date multiple, se pot
obține vederi multiple ale unui singur set de date.
Business Performance Management prin Balanced Scorecards. Instru‐
mentele BSC sunt menite să‐l ajute pe utilizator să pună strategia în practică . Este
vorba despre un sistem de mă surare a performanțelor, derivat din obiectivele şi
strategia organizației, ce reflectă cele mai importante aspecte ale afacerii. BSC poate
fi vă zut ca o listă centrală de numere predefinite, fiecare corespunză toare unei
componente‐cheie a succesului afacerii. BSC se concentrează asupra nivelului
strategic al obiectivelor managementului; prin intermediul acestui instrument,
managerii de la toate nivelurile monitorizează rezultatele în zonele‐cheie ale
afacerii.
Tabloul de bord (dashboard). Oferă o viziune comprehensivă asupra

performanței organizației, prin intermediul unui set de indicatori de mă surare
specifici (KPI – key performance indicators), câ t şi prin semnalarea tendințelor şi a
excepțiilor. Un dashboard integrează informații din toate ariile de business şi le
oferă în formă grafică , ară tâ nd evoluțiile efective în comparație cu cele dorite, ceea
ce indică dintr‐o privire „starea de să nă tate" a firmei.
OLAP. Această componentă (prelucrare analitică online, din engl. online
analytical processing) permite utilizatorului extragerea şi prezentarea facilă şi
selectivă a datelor, din diferite puncte de vedere. Această analiză este posibilă doar
în baze de date multidimensionale. Elementul principal este serverul OLAP, situat
între client şi SGBD. Instrumentele OLAP permit analiza pe diferite dimensiuni a
datelor multidimensionale şi se utilizează frecvent în mineritul de date (data
mining).
Minerit de date (MD). Denumirea acestor instrumente indică clar scopul lor,
iar comparația este reuşită : adesea trebuie să „sapi” destul de mult pentru a ajunge
la informațiile utile. Instrumentele MD extrag informațiile ascunse în bazele de date
şi pot căuta după diferite şabloane în bazele de date tranzacționale. Diferența față de
OLAP se poate exprima astfel: dacă OLAP ră spunde întrebă rilor care i se pun, MD
ră spunde şi întrebă rilor care nu i se pun. Instrumentele de data mining „excavează ”
în volume imense de date tranzacționale pentru a scoate la iveală posibile legă turi
interesante precum obiceiurile de consum individuale şi nivelul cheltuielilor în
restaurante, de exemplu. Se utilizează tehnici ale analizei statistice sau de inteligență
artificială, care permit descoperirea de corelații, reguli şi cunoştințe utile sprijinirii
deciziilor.
Sisteme de alertare şi notificare. Acestea funcționează proactiv, oferind
utilizatorilor informații pe baza unor criterii prestabilite, odată ce se produc
evenimentele. Utilizatorii sunt continuu la curent cu producerea evenimentelor
importante – mesajele le parvin la birou, acasă sau pe drum, prin e‐mail sau alte
tehnologii wireless.
8.2.2. Locul depozitelor de date întrun sistem BI
Depozitele de date au fost definite în foarte multe moduri, astfel încâ t este
destul de dificil de formulat o definiție riguroasă . În sens larg, un depozit de date
reprezintă o bază de date care este întreținută separat de bazele de date
operaționale ale organizației. Datele din sistemele‐sursă sunt extrase, cură țate,
transformate şi stocate în depozite speciale în scopul sprijinirii proceselor
decizionale. Depozitele de date sprijină procesarea informațiilor, furnizâ nd o
platformă solidă de consolidare a datelor istorice pentru analiză . Un depozit de date
este o sumă de date consistentă din punct de vedere semantic, care serveşte la o
implementare fizică a unui model de date pentru sprijinirea deciziei şi stochează
informații pe care o organizație le solicită în luarea deciziilor strategice.
8.2.2.1. Definire şi caracteristici
După W.H. Inmon, pă rintele conceptului de data warehouse, „un depozit de

date este o colecție de date orientate pe subiecte, integrate, istorice şi persistente,
destinată sprijinirii procesului de luare a deciziilor manageriale” 13. Această definiție
exprimă caracteristicile majore ale depozitelor de date: orientarea pe subiecte,
integrarea, caracterul istoric, persistența datelor.
Orientarea pe subiecte. Un depozit de date este organizat în sensul unor
subiecte majore cum ar fi: clienți, furnizori, producție, vâ nză ri etc. Mai curâ nd decâ t
a concentra procesarea operațiilor şi tranzacțiilor zilnice într‐o organizație, un
depozit de date se focalizează pe modelarea şi analiza datelor pentru luarea
deciziilor. Din acest motiv, depozitele de date oferă , în mod tipic, o viziune simplă şi
concisă relativă la un subiect particular, excluzâ nd datele care nu sunt utile în
procesul de sprijinire a deciziei.
Integrarea. Un depozit de date este, în mod uzual, construit prin integrarea
unor multiple surse eterogene: baze de date relaționale, fişiere, înregistră ri privind
tranzacții online etc. Tehnicile de cură țare a datelor (data cleaning) şi de integrare
sunt aplicate pentru a asigura concordanța în convențiile de atribuire a numelor, de
codificare a structurilor, de atribuire a valorilor etc.
Caracterul istoric. Datele sunt stocate pentru a furniza informații în
perspectivă istorică (ex. 5‐15 ani în urmă ). Astfel, decidenții pot consulta valorile
succesive ale aceloraşi date pentru a determina evoluția în timp şi a calcula
tendințele anumitor indicatori.
Persistenţa datelor. Datele dintr‐un depozit sunt permanente şi nu pot fi
modificate. O actualizare a depozitului de date, ca urmare a modifică rilor efectuate
în datele‐sursă înseamnă adă ugare de date noi fă ră a modifica sau şterge datele
existente. Un depozit de date este întotdeauna memorat separat, din punct de
vedere fizic, de datele transformate din alte aplicații. Datorită acestei separă ri, un
depozit de date nu necesită mecanisme de procesare a concurenței; în mod uzual
solicită numai două operațiuni: încă rcarea inițială a datelor şi accesul la date.
În legă tură cu depozitele de date, o noțiune frecvent utilizată este cea de data
warehousing, care desemnează procesul de construire şi utilizare a depozitelor de
date. Construirea unui depozit de date necesită integrarea datelor, cură țarea şi
consolidarea datelor. Utilizarea unui depozit de date necesită adesea o colecție de
tehnologii de asistare a deciziilor. Alți autori utilizează termenul de data
warehousing pentru a se referi numai procesul de construire a depozitului de date,
în timp ce termenul de „warehouse DBMS” este folosit pentru construirea şi
utilizarea depozitului de date14.
13W.H. Inmon, Building the Data Warehouse, John Wiley & Sons, New York, 1996, p. 3.
14 J.
Han, M. Kamber, Data Mining: Concepts and Techniques, Morgan Kaufman Publishers, San Francisco,
2001, p. 41.
În privința utiliză rii datelor din depozitele de date, trebuie precizat că multe
organizații folosesc aceste informații pentru sprijinirea luă rii deciziilor în diferite
domenii de activitate cum ar fi:
 sporirea focaliză rii pe clienți, care include analize ale vâ nză rilor
(preferințe, periodicitate, cicluri bugetare, apetit pentru cumpă rare, factori de
influență a actului de cumpă rare etc.);
 reorientarea producției şi gestionarea portofoliului de produse, comparâ nd
performanțele vâ nză rilor pe trimestre, ani, zone geografice, în ordinea celor mai
bune strategii de producție;
 analiza operațiilor şi căutarea surselor de profit;
 gestionarea relațiilor cu clienții.
Data warehousing este, de asemenea, foarte util din punctul de vedere al
integră rii surselor de date eterogene. Multe organizații colectează, în mod obişnuit,
diferite tipuri de date şi întrețin baze de date mari din surse de informații multiple,
eterogene, autonome şi distributive. Integrarea acestor date şi obținerea unui acces
eficient la ele este lucrul cel mai dorit. Multe eforturi au fost depuse în industria
bazelor de date şi în comunită țile de cercetare pentru îndeplinirea acestui scop.
În concepția bazelor de date tradiționale, integrarea bazelor de date eterogene
este realizată de „wrappers” şi integratori (integrators) sau mediatori (mediators)
asupra bazelor de date multiple (ex.: IBM Data Joiner, Informix Data Blade). Câ nd o
interogare este adresată unui site server, un dicționar de metadate este utilizat la
transformarea interogă rii în interogă ri corespunză toare site‐urilor eterogene
implicate. Aceste interogă ri sunt atunci mapate şi transmise proceselor locale de
interogare. Rezultatele primite de la diferite site‐uri sunt integrate în ră spunsul
global.
Acest concept de interogare necesită procese complexe de filtrare şi integrare,
care concurează la resursele de procesare. Este ineficient şi potențial scump pentru
interogă ri frecvente, în special pentru interogă ri care solicită agregă ri. Data
warehousing furnizează o alternativă interesantă la conceptul tradițional de
integrare a bazelor de date eterogene; folosind conceptul de „update‐driven”, în care
informațiile din surse multiple, eterogene, sunt interogate în avans şi stocate în
depozitul de date pentru integrare directă şi analiză . Spre deosebire de bazele de
date cu procesare online, depozitele de date nu conțin întotdeauna informațiile cele
mai proaspete. Cu toate acestea, un depozit de date determină o performanță înaltă
prin integrarea datelor eterogene, întrucâ t datele sunt copiate, preprocesate,
integrate, adnotate, însumate şi restructurate într‐o colecție semantică de date
(semantic data store). În plus, procesul de interogare din depozitul de date nu
interferează cu procesele din sursele locale.
În sinteză, scopurile unui depozit de date sunt urmă toarele15:
 să furnizeze utilizatorilor accesul sporit la date;
 să furnizeze o singură versiune a adevă rului;
 să înregistreze cu acuratețe trecutul;
15 D. Airinei, Depozite de date, Editura Polirom, Iaşi, 2002, pp. 21‐22.

 să „jongleze” cu nivelurile de acces sinteză /detaliu la date;

 să separe prelucră rile de nivel operațional şi analitic.
Accesul sporit la date pentru utilizatori. Depozitul de date furnizează
accesul la datele integrate ale întreprinderii, anterior blocat prin interfețe neprie‐
tenoase, rigide. Utilizatorii trebuie să poată stabili, cu un minim efort, o conexiune
garantată la depozitul de date prin intermediul unui microcalculator. Securitatea
este sporită prin the warehouse frontend application, prin serverul bazei de date sau
prin ambele.
O singură versiune a adevărului. Datele din depozitele de date sunt
consistente şi au calitatea asigurată înainte de a fi puse la dispoziția utilizatorilor
finali. În mă sura în care se utilizează o sursă comună de date, depozitele de date pun
capă t dezbaterilor privind veridicitatea datelor utilizate sau citate în şedințele de
lucru. Depozitul de date începe să fie resursa comună de date pentru nivelurile
decizionale din organizații. Menționă m că „o singură versiune a adevă rului” este
adesea posibilă numai după multe discuții şi dezbateri asupra termenilor utilizați în
organizație. De exemplu, termenul de „client ră u‐platnic” poate avea mai multe
înțelesuri: client care nu plă teşte la timp, client care nu plă teşte decâ t parțial, client
care nu plă teşte niciodată etc. Ar putea fi stabilită şi o altă accepție: clienți care au
datorii mai vechi de o lună . În mod sigur, aceste accepții au influență asupra
proceselor decizionale şi asupra persistenței deciziilor.
Înregistrarea cu acurateţe a trecutului. Multe date primite de manageri nu
sunt semnificative, dacă nu sunt comparate cu datele anterioare. De exemplu,
rapoartele care compară performanțele actuale ale companiei cu cele din anul
precedent sunt comune. Rapoartele care arată performanțele companiei pentru
fiecare lună din ultimii trei ani pot fi foarte interesante pentru decidenți. Sistemele
operaționale permit mai greu obținerea unor astfel de informații. Un depozit de date
va fi utilizat pentru înregistrarea cu acuratețe a trecutului, lă sâ nd sistemele OLTP
libere pentru a realiza focalizarea pe înregistrarea corectă a tranzacțiilor. Datele
istorice sunt încă rcate şi integrate cu alte date în depozit pentru un acces rapid.
Acces combinat sinteză/detaliu la date. Rapoartele dinamice şi instru‐
mentele de interogare OLAP permit utilizatorilor să vizualizeze informațiile din
depozitul de date sub diferite unghiuri şi la diferite niveluri de detaliere. Aceste
disponibilită ți oferite de depozitele de date reduc timpul şi efortul necesar pentru
colectarea, formatarea şi filtrarea informațiilor, plecâ nd de la date.
Separarea prelucrărilor de nivel operaţional şi analitic. Procesele
decizionale şi procesele operaționale sunt totalmente divergente arhitectural. În
încercarea de a se reuni în acelaşi sistem, informațiile decizionale şi operaționale
determină ca întreținerea sistemului să devină o problemă .
O comparaţie între bazele de date şi depozitele de date este în mă sură să
ofere o imagine coerentă privind rolul depozitelor de date în organizații, precum şi
raporturile cu alte tipuri de sisteme informatice. Atâ t bazele de date, câ t şi
depozitele de date conțin mari cantită ți de date structurate care pot fi consultate
rapid datorită structurilor de acces optimizate şi se bazează , în majoritatea
cazurilor, pe tehnologii relaționale. Totuşi, ele nu au fost proiectate pornind de la

aceleaşi obiective şi se diferențiază prin numeroase aspecte.
Bazele de date din sistemele operaționale conțin date curente, detaliate, care
trebuie actualizate şi interogate rapid, în condiții de deplină securitate, constituind
suportul sistemelor informaționale de prelucrare a tranzacțiilor.
Depozitele de date sunt concepute special pentru sprijinirea luă rii deciziilor.
Interogă rile obişnuite într‐un depozit de date sunt mai complexe şi mai variate decâ t
cele din sistemele de gestiune a bazelor de date. Ele se aplică unor volume foarte
mari de date şi presupun calcule complexe (analiza tendinței, medii, dispersii etc.),
care necesită adesea agregă ri. Deosebirile majore între OLTP (baze de date) şi OLAP
(depozite de date) sunt sintetizate în tabelul 8.2 şi iau în considerare mai multe
tră să turi.
Tabelul 8.2
Comparaţie între sistemele OLTP şi OLAP
Trăsătură OLTP (BD) OLAP (DD)
Destinația Procese operaționale Procese informaționale
Orientarea sistemului Tranzacții Analize
Utilizatori Funcționari, Specialişti, manageri executivi,
administratori BD, analişti
profesionişti BD
Funcții Operații zilnice Cerințe informaționale pe termen
lung, asistarea deciziei
Instrumente folosite în Diagrame E‐R Modelarea star/snowflake
proiectare
Caracterul datelor Curente, noutate garantată Istorice, precizie menținută în
timp
Nivelul de sinteză Primitive, detaliere Sintetizare, consolidare
ridicată
Unitatea de lucru Scurtă , tranzacții simple Interogă ri complexe
Scheme de acces Read/Write Aproape întotdeauna Read
Focalizare Culegere date Furnizare informații
Numă r de înregistră ri Zeci Milioane
accesate
Numă r de utilizatori Mii Sute
Mă rimea bazei de date 100 MB – GB 100 GB – EB
Priorită ți Performanțe ridicate, Flexibilitate ridicată, autonomie
disponibilitate ridicată utilizatori finali
Sistem de evaluare Tranzacții culese Interogă ri culese, timp de ră spuns
Un sistem OLTP este orientat pe client şi este utilizat pentru procesarea

tranzacțiilor şi interogă rilor. Un sistem OLAP este orientat spre piață şi este utilizat
de manageri, analişti şi specialişti. Din punctul de vedere al datelor conținute, un
OLTP gestionează date curente care, în mod obişnuit, sunt destul de detaliate pentru
a fi uşor utilizate în luarea deciziilor curente. Un sistem OLAP gestionează volume
mari de date istorice, furnizâ nd facilită ți pentru sintetizare şi agregare, precum şi
pentru stocarea şi gestionarea informațiilor cu diferite niveluri de granularitate.

Aceste aspecte fac ca datele să fie uşor utilizate de decidenți, mai ales în domeniile
tactic şi strategic. De asemenea, un sistem OLTP este focalizat în principal pe datele
curente dintr‐o organizație sau dintr‐un departament, fă ră a face referire la date
istorice sau date din alte organizații. În constrast, un sistem OLAP cuprinde date
istorice şi date care provin de la diferite organizații, integrâ nd informații din surse
eterogene.
De ce nu se execută procesă ri analitice online (OLAP) direct pe bazele de date
existente, decâ t a cheltui timp şi resurse pentru a construi separat un depozit de
date? Este o întrebare pertinentă , iar ră spunsul poate explica şi fundamenta
investiția într‐un depozit de date. Argumentul forte pentru această separare este
promovarea performanței ridicate în ambele sisteme.
O bază de date relațională este proiectată şi adaptată pornind de la sarcini şi
activită ți cunoscute cum ar fi indexarea, utilizarea cheilor primare, căutarea unor
înregistră ri specifice, optimizarea interogă rilor. Pe de altă parte, interogă rile unui
depozit de date sunt adesea complexe. Ele implică efectuarea de calcule asupra unor
grupuri mari de date, cu totaliză ri pe diferite niveluri, care pot necesita utilizarea de
metode speciale de organizare a datelor, de acces şi implementare bazate pe viziuni
multidimensionale. Procesâ nd interogă rile OLAP într‐o bază de date operațională , s‐
ar degrada substanțial performanțele sarcinilor operaționale. De altfel, o bază de
date operațională sprijină procesarea concurentă a tranzacțiilor multiple. Controlul
concurenței şi mecanismele de verificare sunt necesare pentru a asigura consistența
şi robustețea tranzacțiilor. O interogare OLAP are nevoie adesea de acces read‐only
la înregistră ri pentru sumarizare şi agregare. Mecanismele de control al concurenței
pot încetini execuția tranzacțiilor concurente şi astfel să reducă substanțial
performanța unui sistem OLTP.
În final, separarea dintre bazele de date operaționale şi depozitele de date se
bazează pe structuri, conținut, utilizatori şi date diferite. Luarea deciziilor necesită
date istorice, pe câ nd bazele de date operaționale nu conțin, în mod obişnuit, date
istorice. În acest context, datele operaționale, deşi abundente, sunt departe de a fi
suficiente pentru luarea deciziilor. Asistarea deciziei solicită consolidarea datelor
(totaliză ri şi agregă ri) din diferite surse, rezultâ nd date de înaltă calitate, curate şi
integrate. În contrast, bazele de date operaționale conțin numai date neprelucrate
(primare), detaliate, cum sunt tranzacțiile care trebuie consolidate înaintea
analizelor. Dat fiind faptul că cele două sisteme au funcționalită ți diferite şi necesită
tipuri diferite de date, este necesar să le menținem în baze de date separate. Totuşi,
mulți vâ nză tori de SGBD‐uri operaționale au început optimizarea acestor sisteme,
aşa încâ t ele suportă interogă rile OLAP. Pe linia acestui trend, separarea dintre
sistemele OLTP şi cele OLAP este de aşteptat să scadă .
Discuțiile despre depozitele de date conduc, în mod natural, la magazine de
date (Operational Data Stores – ODS), care la prima vedere nu se deosebesc de
depozitele de date. Deşi ambele tehnologii sprijină decidenții, ele sunt diferite,
deoarece au scopul de a acoperi anumite tipuri de cerințe informaționale.
Inmon şi Battas definesc un ODS ca „o construcție arhitecturală unde este

stocată o colecție integrată de date operaționale”. ODS poate fi definit, de asemenea,
ca o colecție de baze de date proiectate pentru sprijinul controlului operațional. Spre
deosebire de bazele de date din aplicațiile OLTP (care sunt operaționale sau
orientate pe funcții), ODS cuprind date orientate pe subiecte din întreprinderi mari.
Spre deosebire de depozitele de date, datele din ODS sunt volatile şi detaliate. ODS
furnizează o viziune integrată asupra datelor din sistemele operaționale.
Tabelul 8.3
Depozite de date şi magazine de date
Data Warehouse Operational Data Store
Scopuri Sprijinirea deciziilor strategice Control operațional
Asemă nă ri Date integrate Date integrate
Orientare pe subiecte Orientare pe subiecte
Deosebiri Date statice Date volatile
Date istorice Date curente
Date sintetice Detaliere ridicată
Literatura de specialitate prezintă mai multe situații în care un depozit de date

este oportun pentru rezolvarea problemelor apă rute16: insuficienta partajare a
informațiilor, grupuri diferite care produc rapoarte contradictorii, proces foarte
anevoios în privința realiză rii rapoartelor, rapoarte statice care nu favorizează stilul
de interogare ad hoc.
Insuficienta partajare a informaţiilor. De exemplu, serviciile sau
departamentele care au aceiaşi clienți nu comunică informațiile între ele. Ca urmare,
se pierd oportunită țile referitoare la stabilirea profilului real al clienților. De
asemenea, clienții pot fi plictisiți sau agasați de faptul că departamente din cadrul
aceleiaşi organizații le solicită de mai multe ori aceleaşi informații. Rezolvarea
acestei probleme, prin tehnologia depozitelor de date, duce la urmă toarele avantaje:
 pot fi luate decizii mai eficiente în domeniul gestiunii clienților;
 clienții sunt tratați ca entită ți individuale;
 pot fi explorate noi oportunită ți de afaceri.
Grupuri diferite care produc rapoarte contradictorii. Datele din sistemele
operaționale diferite conduc la informații diferite despre acelaşi subiect. Folosirea
inconsistentă a termenilor duce la reguli diferite pentru acelaşi subiect. Astfel,
faptele sunt interpretate diferit, iar în organizație vor exista mai multe versiuni ale
„adevă rului”. Decidenții trebuie să analizeze date conflictuale şi îşi pot pierde
credibilitatea în fața clienților, furnizorilor sau autorită ților statului. Soluția
depozitelor de date conduce la urmă toarele beneficii:
 o viziune consistentă asupra operațiunilor întreprinderii;
 decizii mai bune, bazate pe analize corecte.
16M. Humpries, M. Hawkins, M. Dy, Data Warehousing. Architecture and Implementation, Prentice Hall
PTR, Upper Saddle River, New Jersey, 1999, pp. 55‐57.
Procesul de creare a rapoartelor este foarte anevoios. Rapoartele de

importanță critică necesită prea mult timp pentru a fi produse, ceea ce face ca,
atunci câ nd sunt disponibile, să nu mai fie necesare. Preluarea datelor într‐un raport
complex din mai multe sisteme operaționale poate conduce la inconsistențe sau
erori. Ca urmare, deciziile luate pe baza acestor rapoarte pot fi eronate. Analiştii din
organizație pierd prea mult timp cu colectarea datelor de care au nevoie, iar pentru
analiza propriu‐zisă le ră mâ ne prea puțin timp. Concurenții care nu au asemenea
probleme beneficiază în mod clar de un avantaj competitiv. Rezolvarea acestei
probleme conduce la urmă toarele rezultate pozitive pentru organizație:
 procesul de creare a rapoartelor este în mod vizibil îmbună tă țit;
 ră mâ ne mai mult timp pentru analiza efectivă a datelor;
 decidenții nu sunt nevoiți să lucreze cu date „învechite”.
Rapoartele nu sunt dinamice şi nu favorizează stilul de interogare ad
hoc. Acest lucru înseamnă că rapoartele prezentate managementului superior nu
sunt dinamice şi nu au capacitatea de a oferi facilită ți drilldown pentru detalierea
datelor. Ca urmare, câ nd un raport prezintă o situație de alarmă sau de excepție,
decidentul nu poate vedea mai multe detalii despre situația respectivă . Odată
rezolvată această problemă , decidenții pot obține mai multe detalii atunci câ nd au
nevoie, iar analizele referitoare la tendințe şi la relații cauzale vor fi posibile.
Rapoartele care necesită date istorice sunt dificil de realizat. Există cazuri
câ nd datele istorice despre clienți, produse şi operațiuni financiare nu sunt stocate
în sistemele operaționale. Încercarea de a încorpora datele mai vechi în noile
rapoarte se poate lovi de impedimentul nepotrivirii vechilor structuri cu cele
actuale. Ca urmare, rapoartele nu pot fi produse la timp sau chiar deloc, iar
decidenții nu vor avea posibilitatea de a efectua analize de trend de‐a lungul unei
perioade de timp mai mari. Organizația nu va fi capabilă să anticipeze evenimentele
şi schimbă rile de comportament; cererile consumatorilor vor ven i ca o adevă rată
surpriză , iar organizația va trebui să se forțeze pentru a le satisface.
8.2.2.2. Arhitecturi pentru depozite de date
Succesul unui proiect de tip data warehouse depinde foarte mult de tipul de
arhitectură pentru care se optează. Astfel, implementatorul va avea posibilitatea să
opteze pentru o arhitectură simplificată sau pentru una cu mai multe straturi. Vom
prezenta spre ilustrare primul tip, arhitectura simplificată a unui depozit de date17
care este reprezentată în figura 8.4.
În depozitul de date întâ lnim mai multe tipuri de date care corespund
diferitelor cerințe informaționale ale utilizatorilor: date detaliate, date agregate,
metadate. Metadatele descriu datele conținute în depozitul de date şi modul în care
ele sunt obținute şi stocate. Prin intermediul metadatelor se precizează structura
datelor, proveniența lor, regulile de transformare, de agregare şi de calcul.
17Preluare din D. Airinei, O. Dospinescu, „Depozite de date”, în volumul Sisteme informaţionale pentru
afaceri, Editura Polirom, Iaşi, 2002, pp. 312‐313.
Metadatele joacă un rol esențial în alimentarea depozitului de date; ele sunt utilizate
în toate etapele de încă rcare a datelor şi sunt consultate şi actualizate pe parcursul
întregului ciclu de viață al depozitului. Includerea datelor agregate în depozit, deşi
determină o creştere a redundanței datelor, este necesară deoarece în acest fel se
poate asigura un timp mediu de ră spuns câ t mai redus.
Date externe
Depozit de
date
Instrumente pentru accesare şi utilizare

Metadate
Date puternic agregate Datamart
Date interne
Date uşor agregagte
Datamart
Date detaliate
Datamart
Date vechi
arhivate
Figura 8.4. Arhitectura simplificată a unui depozit de date
Sursele de date pentru depozitele de date sunt: bazele de date operaționale

curente, bazele de date vechi arhivate, precum şi baze de date externe. Construirea
depozitului de date presupune parcurgerea urmă toarelor etape:
 un proces de extragere a datelor din bazele de date operaționale sau din
surse externe, urmat de copierea lor în depozitul de date. Acest proces trebuie cel
mai adesea să transforme datele în structura şi formatul intern al depozitului.
 un proces de curăţare a datelor, pentru a exista certitudinea că datele sunt
corecte şi pot fi utilizate pentru luarea deciziilor;
 un proces de încărcare a datelor corecte în depozitul de date;
 un proces de creare a unei multitudini de agregări ale datelor: totaluri
precalculate, subtotaluri, valori medii etc. care se preconizează că vor fi cerute şi
folosite de utilizatori.
Depozitele de date sunt destinate managerilor, analiştilor şi specialiştilor
angrenați în luarea deciziilor strategice privind dezvoltarea şi viitorul organizațiilor.
Pentru aceasta, ei au nevoie de instrumente performante de accesare şi utilizare a
datelor din depozite, instrumente asigurate prin software‐ul asociat depozitului de
date. Întreaga gamă de instrumente software asociate depozitelor de date este
prezentată în figura 8.5. Pe de o parte, regă sim instrumente necesare utilizatorilor
care au nevoie de acces rapid la informații punctuale, care includ un limbaj de
interogare gen SQL sau generatoare de rapoarte ce transpun informațiile în formate

adecvate. Pe de altă parte, sunt instrumente specializate pentru asistarea deciziilor,
care transformă informațiile în forma cerută de decidenți (grafice, diagrame,
organigrame, simulă ri previzionale vizuale) sau oferă posibilitatea analizei
tendințelor, corelațiilor şi interpretarea acestora. În această categorie se încadrează
instrumentele de tip OLAP şi data mining.
Instrumente de Tehnologii Instrumente de
extragere şi Warehous accesare şi
transformare e utilizare
Date sursã OLAP
Conectivitate cu alte
sisteme
Report Writers
Extragere Data
Warehouse
DSS
Transformare
Data Mining
Asigurarea calitãţii
Metadate
Încãrcare date Sisteme de alertã

transformate
Figura 8.5. Componentele software ale depozitelor de date
Din punctul de vedere al ariei de cuprindere, se întâ lnesc trei modele de

depozite de date: depozite de întreprindere, data mart‐uri şi depozite virtuale.
Un depozit de întreprindere (Enterprise Warehouse) colectează toate
informațiile despre subiecte care privesc întreaga organizație. El furnizează un
volum extins de date; conține date detaliate, dar şi date agregate, iar ca ordin de
mă rime porneşte de la câ țiva GB, putâ nd ajunge la sute de TB sau mai mult. El se
implementează pe superservere performante sau pe platforme cu arhitecturi
paralele. Un depozit de întreprindere necesită cheltuieli foarte mari pentru
modelare şi perioade îndelungate (uneori chiar ani) pentru proiectare şi
implementare.
Un data mart conține un subset al volumului de date din organizație, specific
unui grup de utilizatori, domeniul fiind limitat la subiecte specifice. De exemplu, un
data mart pentru marketing limitează subiectele la clienți, articole, vâ nză ri. Datele
conținute într‐un data mart sunt de obicei agregate. Data mart‐urile sunt, în mod
curent, implementate pe servere departamentale mai ieftine care se bazează pe Unix
sau Windows. Ciclul de implementare a unui data mart este mai curâ nd mă surat în
să ptă mâ ni decâ t în luni sau ani. Ca atare, un data mart poate fi considerat un
subansamblu al unui depozit de date mai uşor de construit şi întreținut şi mai puțin
scump.
Un depozit virtual (Virtual Warehouse) este constituit dintr‐un set de viziuni

(views) asupra bazelor de date operaționale. Pentru eficiența procesă rii
interogă rilor, numai unele dintre viziunile de agregare pot fi materializate. Un
depozit virtual este uşor de construit, dar necesită capacită ți suplimentare pe
serverele de baze de date.
8.2.3. Analiza multidimensională
Globalizarea, evoluțiile economice tot mai dificil de anticipat, acțiunile

neaşteptate ale concurenților, schimbarea preferințelor consumatorilor, evoluțiile
tehnologice tot mai accentuate pun managerii în situații din ce în ce mai dificile în
privința adoptă rii unor decizii corecte, care să conducă organizațiile pe un drum
optim. Perioada empirismului în management a trecut de mult timp, însă chiar şi
tehnicile şi metodele clasice de analiză a mediului de afaceri încep să nu mai dea
rezultatele scontate. Una dintre cauzele determinante o constituie cantitatea uriaşă
de date cu care trebuie să se confrunte managerii de la diferite niveluri şi care
devine sufocantă , nepermițâ nd decidenților să vadă esențialul problemei apă rute.
Bazele de date tradiționale, în marea lor majoritate relaționale, permit
sprijinirea procesului de luare a deciziilor într‐o anumită mă sură, mai ales în
privința problemelor de tip cantitativ: Care este media încasă rilor lunare? Care este
primul client?
Însă economia concurențială actuală obligă managerii să rezolve mai ales
probleme de tip calitativ: De ce o parte a clienților preferă un anumit produs, iar
ceilalți nu? De ce într‐o anumită regiune campaniile promoționale nu dau rezultate?
Sistemele de prelucrare a tranzacțiilor nu au fost proiectate pentru a înlesni
rezolvarea acestui tip de probleme şi, ca urmare, nu pot furniza în timp util un
ră spuns corect managerilor. Decidentul este nevoit să piardă timp pentru a deriva
informația de care are nevoie din sistemul de rapoarte pe care îl are la dispoziție, iar
cei din departamentul IT sunt nevoiți să obțină rapoarte ad hoc din sistemele
operaționale de procesare a tranzacțiilor. De cele mai multe ori, datele solicitate
pentru raportul respectiv sunt „împră ştiate” în mai multe sisteme operaționale, ceea
ce implică în prealabil integrarea lor. Întâ rzierile nu sunt doar consumatoare de
timp, dar pot afecta serios activitatea organizației; câ nd raportul este în sfâ rşit
obținut, este posibil ca datele să fie inconsistente sau incorecte.
Între activită țile operaționale şi activită țile de luare a deciziilor la nivel
strategic există o serie de diferențe majore18, sintetizate în tabelul urmă tor.
Organizațiile încearcă să ră spundă provocă rilor prin mijloace diverse, în
funcție de cultura pe care o au şi de resursele disponibile. Un curent la modă , cu
numeroase implementă ri practice, este cel al depozitelor de date bazate pe
conceptul de date multidimensionale. În strâ nsă legă tură cu depozitele de date, s‐a
cristalizat modelarea multidimensională a datelor.
18 E.
Thomsen, OLAP Solutions. Building multidimensional information systems, Wiley Computer
Publishing, SUA, 2000, p. 9.
Tabelul 8.4
Operaţional versus strategic
Activităţi (decizii) la nivel operaţional Activităţi (decizii) la nivel strategic
Frecvență mare Frecvență redusă
Previzibile Imprevizibile
Volum redus de date interogate Volum mare de date interogate
Necesită îndeosebi date curente Necesită date trecute, prezente şi previziuni
Puține derivă ri complexe Multe derivă ri complexe
Sistemele de procesare a tranzacțiilor folosesc de obicei standardul relațional,

bazat pe normalizare. Structurile normalizate permit sistemelor operaționale să
înregistreze şi să stocheze sute de mii de înregistră ri, tranzacții individuale, fă ră a
exista riscul pierderii sau alteră rii datelor. Deşi bazele de date normalizate sunt
eficiente pentru sistemele OLTP, ele provoacă probleme atunci câ nd sunt utilizate în
sistemele decizionale complexe. Să presupunem exemplul din figura 8.6. Dacă un
manager are nevoie de un raport cu vâ nză rile de produse pe fiecare cumpă ră tor în
parte, programul de interogare trebuie să acceseze tabelele Clienți, Conturi, Tip cont,
Ordine, Linii ordine, Produse, pentru a calcula totalurile dorite. Clauza WHERE din
fraza SQL va fi destul de simplă , dar foarte lungă ; înregistră rile din diferite tabele
trebuie să fie relaționate pentru a furniza rezultatul corect (vezi figura 8.7).
Tip cont
Clienţi Conturi Ordine
Linii ordine
Tip produs Produse
Figura 8.6. Exemplu de structură normalizată

Vânzările de produse pe clienţi

Data: 28 septembrie 2012
Client Denumire produs Valoare vânzări
Client A Produs X 3.400
Produs Y 7.600
Client B Produs X 2.000
… … …
Figura 8.7. Raportul vânzărilor de produse pe clienţi
Pentru a înlesni munca de obținere a datelor, se foloseşte modelarea

dimensională, care oferă tehnici de denormalizare a structurii bazei de date pentru
a crea scheme care sunt convenabile pentru sprijinirea procesului decizional. În
modelarea dimensională sunt utilizate două tipuri de tabele: tabele de fapte şi tabele
de căutare (tabele dimensionale).
Tabelele de fapte sunt folosite pentru a înregistra faptele reale ale afacerii.
Faptele sunt valori numerice pe care utilizatorii le analizează şi le sintetizează
pentru a înțelege mai bine diverse aspecte ale afacerii. Pentru diferite domenii de
afaceri pot fi evidențiate exemple de tabele de fapte:
 comerț cu amă nuntul: numă rul de unită ți vâ ndute, valoarea vâ nză rilor;
 telecomunicații: durata convorbirilor în minute, numă rul mediu de apeluri;
 bă nci: valoarea tranzacțiilor, numă rul mediu de tranzacții;
 asigură ri: valoarea despă gubirilor;
 transport aerian: prețul biletelor, greutatea bagajelor.
Tabelele de căutare (dimensionale) au rolul de a stabili contextul faptelor;
ele conțin câ mpuri care descriu faptele. Din punctul de vedere al viziunii naturale pe
care o are managerul asupra faptelor, putem spune că tabelele de căutare definesc
spațiul în care se realizează orientarea. Exemple de tabele de căutare pentru aceleaşi
domenii de afaceri:
 comerț cu amă nuntul: denumirea magazinului, codul poştal al magazinului,
denumirea produsului, categoria produsului, ziua să ptămâ nii;
 telecomunicații: originea apelului, destinația apelului;
 bă nci: numele clientului, numă rul contului, data, domeniul de activitate al
clientului, numele administratorului de cont;
 asigură ri: tipul poliței de asigurare, bunurile asigurate;
 transport aerian: numă rul zborului, destinația zborului, clasa de călă torie.
Câ nd un manager cere un raport care să prezinte încasă rile pentru magazinul
X, în luna Y, pentru produsul Z, el foloseşte dimensiunile Magazin, Timp şi Produs
pentru a descrie contextul încasă rilor (faptele).
Vizual, o schemă multidimensională are o arhitectură de tip stea, în care
tabelele de fapte se află în centru, iar tabelele de căutare sunt dispuse în jurul lor. În
figura 8.8, dimensiunile sunt Client, Timp, Produs şi Magazin. Câmpurile din aceste
tabele sunt folosite pentru a descrie faptele din tabela de fapte Vâ nză ri.
Figura 8.8. Exemplu de arhitectură tip stea
Unul dintre principiile‐cheie ale modelă rii multidimensionale este folosirea

tabelelor de fapte în formă normalizată, împreună cu tabelele de căutare în formă
denormalizată. În exemplul din figura 8.8, datorită faptului că tabelele de că utare
sunt denormalizate, schema nu mai cuprinde şi alte tabele. În contrast, o dimensiune
Produs pe deplin normalizată au tabelele adiționale din figura 8.9.
Grupa Subgrupa Categorie Produs

produs produs produs
Figura 8.9. Tabele Produs normalizate
Tabelele normalizate sunt cauza dificultă ții cu care un utilizator navighează

prin ele pentru a gă si informațiile de care are nevoie. Prin denormalizarea
dimensiunilor, printr‐o singură tabelă , utilizatorul gă seşte informațiile dorite. Ca
rezultat al denormaliză rii dimensiunilor, fiecare dimensiune va conține ierarhii
care implică gruparea şi structurarea. După cum se arată în figura 8.10, dimensiunea
Timp are o ierarhie ZiLunăTrimestruAn. Similar, dimensiunea Magazin are ierahia
OraşJudeţRegiuneTotal magazine, iar dimensiunea Produs are ierarhia Produs
Categorie produsGrupă produsTotal Produse.
Figura 8.10. Ierarhii dimensionale
Câ nd utilizatorii depozitului de date navighează prin el pentru a afla informații

cu diferite niveluri de detaliere, ei de fapt se poziționează la un anumit nivel din
fiecare ierarhie. De exemplu, un utilizator poate să dorească inițial un raport al
vâ nză rilor cu totalul vâ nză rilor pentru fiecare regiune în fiecare an. Pentru un astfel
de raport, utilizatorul se poziționează la nivelul 1 al ierarhiei Timp, la nivelul 2 al
ierarhiei Magazin şi la nivelul 1 al ierarhiei Produs (vezi figura 8.11).
Figura 8.11. Interogare prin poziţionare în cadrul ierarhiilor
În urma interogă rii prin poziționare în cadrul ierarhiilor se poate obține uşor
raportul dorit, ilustrat în figura 8.12.
Figura 8.12. Raport obţinut prin poziţionarea în cadrul ierarhiilor
Gradul de detaliere poate fi modificat prin operațiunile de drilldown (mai

analitic) sau drillup (mai sintetic). De exemplu, prin drilldown efectuat asupra
dimensiunii Timp se poate obține un raport detaliat pe trimestre (vezi figura 8.13).
Figura 8.13. Raport obţinut prin operaţiunea drilldown
Un aspect important îl reprezintă gradul de granularitate, care indică nivelul

de detaliere stocat în tabela de fapte. Granularitatea tabelei de fapte depinde direct
de gradul de detaliere pe care îl au dimensiunile sale. De exemplu, dacă fiecare
înregistrare Timp reprezintă o zi, fiecare înregistrare Produs reprezintă un produs şi
fiecare înregistrare Magazin reprezintă un magazin, atunci „granula” tabelei de

fapte Vânzări, care are dimensiunile menționate, este: vâ nză ri pe produs pe zi pe
magazin. Faza de analiză a granularită ții unui depozit de date trebuie să fie efectuată
foarte atent, deoarece o granularitate la un nivel prea sintetic nu permite obținerea
de informații suplimentare, în timp ce o granularitate accentuată, cu detaliere
pronunțată , poate creşte exponențial spațiul ocupat de depozitul de date.
Agregarea este unul dintre cele mai importante concepte din lumea
depozitelor de date. Utilizarea corectă a agregă rilor conduce la o creştere
importantă a performanțelor depozitului de date în privința timpului de ră spuns la
interogă ri. O agregare este o valoare precalculată stocată în depozitul de date, de
obicei într‐o schemă separată . Calculul valorilor agregate se face pe baza valorilor de
la nivelul cel mai analitic (în exemplul nostru, nivelul 4 la fiecare dimensiune, cu
valorile: Zi, Oraş, Produs). Avantajul agregă rii constă în faptul că utilizatorul, pentru
a obține informații cu caracter sintetic, poate lansa interogă ri asupra valorilor
agregate, în loc să solicite sistemul cu interogă ri la nivelul înregistră rilor
elementare.
Agregă rile au mai puține înregistră ri decâ t schemele care conțin nivelurile de
bază . În exemplul nostru, se iau în considerare Timp, Produs, Magazin şi urmă toarele
caracteristici:
 granula tabelei de fapte este Produs pe Magazin pe Să ptă mâ nă ;
 sunt zece Magazine;
 sunt 100 de Produse pentru fiecare Marcă ;
 există cel puțin o Vâ nzare pe Produs pe Magazin pe Să ptă mâ nă.
Pe baza acestor premise putem calcula numă rul de înregistră ri de fapte care
sunt necesare pentru fiecare interogare:
Dacă o interogare necesită… Atunci trebuie manipulate

un Produs, un Magazin, o Să ptă mâ nă doar o înregistrare din schemă
un Produs, Toate magazinele, o Să ptă mâ nă 10 înregistră ri din schemă
un Marcă , un Magazin, o Să ptă mâ nă 100 înregistră ri din schemă
un Marcă , Toate magazinele, un An 52.000 înregistră ri din schemă
Dacă agregă rile ar fi calculate şi stocate astfel încâ t fiecare înregistrare

agregată ar conține faptele pentru o marcă pe magazin pe să ptă mâ nă, a treia
interogare din cele de mai sus ar necesita doar o înregistrare în loc de 100. În mod
similar, a patra interogare ar necesita doar 520 de înregistră ri în loc de 52.000.
Câ ştigul de timp obținut este evident.
Un depozit de date poate conține simultan mai multe scheme de tip stea, adică
mai multe tabele de fapte. Fiecare schemă este proiectată pentru a servi un anumit
necesar informațional. De asemenea, este firesc ca o dimensiune (tabelă de că utare)
să fie folosită în mai multe scheme de tip stea.
În concluzie, se poate spune că modelarea multidimensională oferă câ teva
concepte puternice care îi conferă o serie de calită ți care o vor promova în sistemele
moderne de sprijinire a proceselor decizionale:
 este simplă. Oferă posibilitatea proiectanților de depozite de date să

creeze scheme pe care utilizatorii să le poată înțelege şi controla uşor. Nu este
necesar un efort mare pentru a învă ța cum se citesc diagramele, deoarece
dimensiunile imită perfect viziunea multidimensională pe care utilizatorii o au
asupra afacerii;
 promovează calitatea datelor. Schemele de tip stea pă strează integritatea
referențială în interiorul depozitului de date, prin modul de concepere a cheii tabelei
de fapte;
 asigură optimizarea performanţelor prin agregare. Pe mă sură ce
mă rimea depozitului creşte, ră spunsurile la interogă ri se obțin tot mai greu.
Agregă rile reprezintă una dintre cele mai la îndemâ nă modalită ți de a creşte
performanța sistemului de interogare.
8.2.4. Tehnologii OLAP
În anul 1993, E.F. Codd, creatorul modelului relațional pentru bazele de date, a
introdus termenul OLAP (On Line Analytical Processing)19. Codd considera la acel
moment că bazele de date relaționale folosite pentru a gestiona procesarea
tranzacțiilor şi‐au atins performanța maximă în ceea ce priveşte dimensionalitatea
viziunilor asupra datelor disponibile pentru utilizatorul final. El a concluzionat că
datele operaționale şi implicit bazele de date operaționale pur şi simplu nu erau
potrivite pentru a ră spunde întrebă rilor din categoria celor adresate de regulă de
manageri.
Tehnologia OLAP presupune oferirea de posibilită ți multiple în ceea ce
priveşte manipularea analitică a datelor (tabele, grafice, sintetiză ri, analize etc.) şi se
bazează de regulă pe utilizarea unui depozit de date în format multidimensional.
Principalele operațiuni OLAP necesare unui decident sunt urmă toarele20:
 drillup;
 drilldown;
 dice;
 slice;
 pivot (rotate).
Operațiunea drillup, denumită şi rollup de unii producă tori, execută agregă ri
pe cubul de date, prin escaladarea ierarhiei pentru o dimensiune sau prin reducerea
dimensiunii. Câ nd drillup este executat prin reducerea dimensiunii, unul sau mai
multe niveluri ierarhice sunt şterse din dimensiune. Drilldown este opusul
operațiunii drillup; parcurgerea ierarhiei se face de la cel mai puțin detaliate
niveluri pâ nă la cele mai detaliate (analitice). Drilldown poate fi realizat prin
parcurgerea descendentă a ierarhiei pentru o dimensiune sau prin introducerea de
dimensiuni suplimentare.
19 Observații preluate din G. Marakas, Decision Support Systems in the 21st Century, 2nd Edition, Prentice
Hall, New Jersey, 2003, pp. 329‐330.
20 D. Airinei, op. cit., pp. 51‐56.
Operațiunea slice execută o selecție pe o dimensiune a unui cub dat, rezultâ nd

un subcub, în timp ce dice defineşte un subcub prin mai multe dimensiuni. Pivot
(rotate) este o operație care roteşte axele de vizualizare a datelor în ordinea cerută
de alternativa prezentă rii lor.
Analizâ nd operațiile principale definite de conceptul OLAP, opinia noastră este
că, la ora actuală, dată fiind eterogenitatea surselor de date (audio, video, text, web,
dispozitive mobile), din punctul de vedere al utilizatorului, este mai puțin important
mediul de stocare a datelor sau tipurile de structuri de date pe care se mapează
interfața utilizator. Aşadar, considerăm că tehnologia OLAP trebuie să se refere cu
precădere la posibilitatea implementării în interfeţele grafice a elementelor adecvate
utilizatorilor de sisteme de asistare a deciziilor. Cu alte cuvinte, predominante pentru
tehnologia OLAP vor fi bibliotecile de controale vizuale capabile să execute în mod
eficient operaţiunile descrise anterior. Gridurile adaptabile, combo‐box‐urile
dinamice, tehnologia ajax, graficele multidimensionale controlabile de utilizator,
precum şi sistemele de prelucrare a vocii decidentului, vor constitui cu siguranță
miezul OLAP‐ului în urmă toarea perioadă de timp.
De regulă, instrumentele OLAP sunt incluse în produse de generare a
interogă rilor şi rapoartelor şi extrag datele primare dintr‐un depozit de date. Într‐o
astfel de arhitectură (vezi figura 8.14), scopul depozitului de date este să integreze
datele din surse eterogene: baze de date operaționale, sisteme moştenite, baze de
date de pe web, baze de date publice. O altă posibilitate este ca aplicația să aibă un
modul OLAP special pentru generarea interogă rilor care sunt apoi transmise unui
generator de rapoarte.
Sisteme
moştenite
Interogãr
i OLAP
Extragere & integrare
Date
publice
Rapoarte
OLAP &
DEPOZIT Server Sursã grafice
Baze de date DE DATE raport
operaţionale
Baze de
Rezultate
date web (dataseturi
)
Sursa: Kimball, R., Ross, M., The Data Warehouse Toolkit, John Wiley & Sons, 2002, p. 67.
Figura 8.14. Arhitectură OLAP bazată pe depozit de date
Un sistem de asistare a deciziilor trebuie să ofere managerilor mai multă

informație decâ t există deja în depozitul de date. Instrumentele de tip data mining
sunt incluse într‐o clasă care oferă posibilită ți de descoperire automată a cunoaşterii
şi permit evidențierea informațiilor ascunse. Analistul uman este ajutat să înțeleagă
datele prin descoperirea unor modele, reguli şi relații care în mod normal nu sunt
vizibile în datele depozitului. Metodele de tip data mining pot fi clasificate în câ teva
categorii de bază 21:
 asocieri, care sunt folosite pentru a descoperi reguli de comportament în
marketing (de exemplu, dacă un client cumpă ră bere, atunci probabilitatea de a
cumpă ra şi câ rnați este de 35%);
 clustering, care este folosit pentru a grupa datele şi a reuşi construirea sau
evidențierea de noi clase specifice;
 similarităţi pentru serii de timp, care presupun gă sirea secvențelor
similare în serii de timp (această metodă este folosită mai ales pentru evidențierea
sezonalită ții în diverse domenii de interes pentru decident);
 modelare secvenţială, care combină avantajele asocierilor cu cele ale
similarită ții seriilor de timp;
 detectarea deviaţiilor, care constă în evidențierea anomaliilor din seturile
de date şi eventual a cauzelor care au determinat aceste anomalii.
Data mining este un concept complex bazat pe tehnici şi metode din diverse
domenii de studiu: statistică , sisteme de gestiune a bazelor de date, depozite de date,
modelare matematică , recunoaşterea modelelor etc. În literatura de specialitate se
consideră că folosirea data mining presupune analiza şi explorarea datelor22.
Utilizatorul are nevoie să „traverseze” în mod flexibil printr‐o bază de date, să
selecteze orice porțiune relevantă din datele existente, să le analizeze la diferite
grade de granularitate şi să prezinte rezultatele în formate diverse.
Astfel, prin combinarea celor două concepte referitoare la depozite de date şi
la OLAP, obținem un nou concept deosebit de puternic: OLAM, ceea ce înseamnă On
Line Analytical Mining. Adeseori este foarte dificil de previzionat de ce fel de
cunoaştere va avea nevoie utilizatorul. Prin integrarea tehnologiilor OLAP cu
funcționalită țile oferite de conceptul data mining, OLAM oferă flexibilitate pentru
utilizatori să selecteze funcțiile data mining şi să efectueze în mod dinamic
„mineritul datelor”.
Pentru sistemele de asistare a deciziilor, o arhitectură mai completă trebuie să
conțină şi un modul de tip data mining care să fie capabil să comunice cu un server
OLAP şi cu un depozit de date, ca în figura 8.15.
21 http://otn.oracle.com/products/oracle9i/htdocs/o9idm_faq.html, http://research.microsoft.com/dmx/,
http: //courses.cs.deu.edu/cse572/presentations/
22 J. Han., M. Kamber, op. cit., 2001, p. 48.
Interfaţa utilizator
OLAP Componentã
Server Data Mining
Depozit de date
Sursa de
date 1
Sursa de
date 2
... Sursa de
date n
Figura 8.15. Arhitectura OLAM
Într‐o astfel de arhitectură , componenta data mining se comportă ca o bază de

modele: în funcție de alegerea utilizatorului, date din depozitul de date sunt
procesate în conformitate cu modelul de analiză curent selectat şi rezultatele sunt
apoi prezentate prin intermediul unei interfețe vizuale. Se observă că utilizatorul
poate să interogheze depozitul de date în mod direct, prin serverul OLAP, iar
serverul accesează apoi modele corespunză toare stocate în modulul OLAM. În final,
rezultatul vine de la componenta data mining, care a fost aplicată datelor din OLAP.
Avantajul conceptului OLAM provine din faptul că decidentul poate folosi
oportunită țile OLAP cu noua cunoaştere oferită de tehnicile data mining. Problema
existentă la ora actuală în piața produselor de acest gen este că producă torii nu
agreează un model standard; fiecare companie doreşte să implementeze propria
arhitectură şi propria tehnologie şi în felul acesta este foarte dificil de obținut un
standard OLAM. Piața produselor care sunt comercializate şi folosite ca instrumente
OLAM este dominată în prezent de mă rcile prezentate în tabelul 8.5.
Tabelul 8.5
Produse OLAM
Producător Denumire produs
Oracle Corporation Darwin
Microsoft SQL Analysis Manager
IBM Intelligent Miner
SurfAid Analysis
SPSS Inc Clementine
Cognos (Oracle) Scenario
Salford Systems MARS
CART
SAS Institute Inc. Enterprise Miner
Deşi tehnologiile depozitelor de date şi OLAP sunt relativ noi, ele tind să se
combine, astfel încâ t rezultatul obținut să fie mai puternic decâ t suma pă rților.
Conceptul OLAM este deja implementat într‐o serie de produse software, dar un
standard uniform încă nu există din pricina intereselor comerciale şi complexită ții
domeniului. Consideră m că viitorul apropiat va transforma OLAM într‐o tehnologie
cu adevă rat matură şi utilă pentru manageri şi organizații.
8.3. Câteva consideraţii privind implementarea sistemelor

Business Intelligence
Ț inta inteligenței economice nu este limitată la companiile mari, ci include la

fel de bine firmele mici şi medii: oricine are nevoie de informații de calitate la
momentul oportun. Există pe piața aplicațiilor marii jucă tori, care se adresează
clienților mari, dar şi furnizori de soluții pentru firmele mijlocii şi mici, precum şi
oferte de instrumente de analiză pentru diverse funcțiuni, ca alternativă la BI, care
acoperă întreg spectrul funcțional al organizației23.
Spre deosebire de tradiţionalul ERP, aplicaţiile de Business Intelligence oferă un
mediu în care utilizatorii primesc mai uşor informaţiile dorite, corecte, consistente
şi pe înţelesul lor. Nevoia de a înțelege dincolo de cifrele din rapoarte şi de a explica
anumite situații, bune sau rele, este acoperită de BI, aplicații care s‐au dovedit nici
scumpe, nici greu de implementat, devenind o necesitate pentru procese decizionale
întemeiate.
Dacă în cazul ERP sau CRM, aria utilizatorilor este destul de clară , în cazul BI
se pune întrebarea despre categoriile de utilizatori care ar avea nevoie sau ar
beneficia de pe urma acestor aplicații. În tabelul 8.6 sunt corelate instrumentele şi
aplicațiile BI, cu toate tipurile posibile de utilizatori dintr‐o firmă .
Tabelul 8.6
Utilizatorii BI
Categorii de Număr de Valoare
Instrumente şi aplicaţii BI
utilizatori utilizatori strategică
IT Câ țiva Dezvoltare de aplicații, definire metadate, Mare
managementul datelor, securitate
Utilizatori Zeci Interogă ri ad hoc, rapoarte OLAP, data Mare
specialişti mining, analize multidimensionale
Manageri Zeci Rapoarte, foi de calcul, vederi OLAP, Medie
funcționali business activity monitoring, business
performance management
Top‐manageri Câ țiva Tablou de bord, BSC (balanced Mare
scorecard), rapoarte personalizate,
business performance management
Utilizatori Sute/mii Rapoarte, foi de calcul Scă zută
ocazionali
23O. Thompson, „BI Approaches of Enterprise Software Vendors”, 2004, disponibil la http://www.
technologyevaluation.com/research/articles/bi‐approaches‐of‐enterprise‐software‐vendors‐17218/
Categorii de Număr de Valoare
Instrumente şi aplicaţii BI
utilizatori utilizatori strategică
Parteneri şi Sute/mii Rapoarte Mare
clienți
Sursa: Adaptare după Turban, E., s.a., Decision Support and Business Intelligence Systems, Pearson
Education, New Jersey, 2007, p. 197.
Aşa cum se observă din tabelul 8.6, implementarea unui BI poate atrage
utilizatori de toate tipurile (într‐o clasificare exotică, Imhoff şi Pettit24 identifică
urmă toarele categorii: fermieri, turişti, operatori, exploratori şi mineri), unii
orientați spre arii operaționale, alții, că tre cele strategice.
Pe lâ ngă selectarea celui mai potrivit produs, succesul unui proiect BI depinde
de mai mulți factori interni, care țin de politica firmei. Deşi implementarea
produsului la nivelul unui singur departament este mai simplă , sistemele fragmen‐
tate ce rezultă vor fi dificil de integrat mai apoi. În plus, experiența demonstrează , ca
în cazul altor tipuri de aplicații de întreprindere, valoarea superioară a proiectelor
interdepartamentale, față de cele de la nivelul unui singur departament.
De asemenea, succesul proiectului depinde esențial de mă sura în care este
urmă rit interesul utilizatorilor: aplicațiile trebuie să ră spundă nevoilor acestora şi
să fie uşor de utilizat.
Criteriile cel mai frecvent luate în discuție la alegerea produsului sunt:
 funcționalitatea;
 integrarea cu aplicațiile existente;
 uşurința de utilizare pentru utilizatorul final;
 prețul;
 performanțele;
 facilită țile de creare de noi aplicații.
BI valorifică avantajul aplicațiilor de întreprindere (ERP, CRM, SCM) deja
instalate, ceea ce maximizează beneficiile investițiilor IT. BI extrage informațiile
prețioase din bazele de date tranzacționale ale firmei. Marile companii, care au
investit enorm în construirea de depozite de date, pot face pasul urmă tor prin
implementarea unui sistem BI, care desă vâ rşeşte eforturile investiționale.
Discuții şi exemple
Următorul studiu de caz se referă la un operator de telecomunicaţii lider mondial, cu peste 91
de milioane de clienţi, prezent în 220 de ţări, pe cinci continente. Această organizaţie are
190.000 de angajaţi şi oferă o gamă completă de servicii de telecomunicaţii: locale,
internaţionale, telefonie mobilă, internet şi multimedia, transport de date şi transmisie TV
prin cablu.
De câţiva ani, organizaţia a folosit sistemul informaţional ca o armă strategică importantă în
lupta cu alţi operatori de telecomunicaţii. Una dintre iniţiativele majore a fost reducerea
24 C. Imhoff, R. Pettit, „The critical shift to flexible Business Intelligence”, Intelligent Solutions, 2004, p. 32.
inconsistenţei datelor şi distribuirea informaţiei mult mai eficient în diferite zone ale
organizaţiei, prin implementarea de standarde pentru administrarea programelor
informatice. Soluţiile software alese au fost: BusinessObjects, pentru extragerea şi analiza
datelor, aplicaţii Oracle, pentru financiarcontabilitate, PeopleSoft CRM şi Genesys, pentru
CRM, PeopleSoft HR, pentru resurse umane, webMethods, pentru aplicaţii globale integrate
şi Documentum, pentru administrarea documentelor.
În prima fază, implementarea BI sa realizat la nivel de departamente, fiind iniţiate peste 140
de proiecte cu produse BusinessObjects. Topmanagerii au înţeles că procesele de business
intelligence joacă un rolcheie în extragerea şi analizarea datelor din resursele corporaţiei.
Dezvoltarea unei platforme de BI la nivelul întregii companii a fost o decizie firească.
Compania a ales tot Business Objects ca standard BI corporativ şi a semnat un contract pentru
70.000 de licenţe, pentru a fi implementate în toate ariile organizaţiei: resurse umane,
management financiar, marketing, vânzări şi distribuţie. Două dintre motivele importante
pentru care sa ales Business Objects au fost gradul înalt de implementare în cadrul
organizaţiei şi satisfacţia utilizatorilor în folosirea sa.
Odată cu decizia de a realiza standardizarea cu Business Objects, cheia succesului acestui
proiect a constat în calitatea suportului oferit managerilor de proiect şi utilizatorilor. A fost
creat un centru de excelenţă în BI format din patru persoane, responsabile să supervizeze
implementările de BI. Este datoria lor să asigure şi să păstreze consistenţa proiectelor care
implică soluţii de BI şi să se asigure de fiecare dată că echipe diferite împărtăşesc cele mai
bune practici.
Lecţiile învăţate: nevoia de pragmatism şi de comunicare puternică. Pragmatismul a constat
în punerea în valoare a celor 140 de implementări de BI existente în cadrul companiei, care,
asociat cu gradul înalt de satisfacţie a utilizatorilor, a crescut considerabil şansa de succes a
proiectului de standardizare BI. Iar o comunicare puternică a fost necesară pentru a
convinge executivul că proiectul este util şi reprezintă o oportunitate pentru ei.
Beneficiile. Compania are acum un mediu de lucru standard carei acoperă toate nevoile de BI.
Compania a realizat economii la taxele pentru licenţe rezultate din achiziţia la nivel de
corporaţie, şi nu pe fiecare proiect în parte. Alegerea unei singure soluţii de BI a permis
reducerea substanţială a costurilor legate de instruirea şi suportul utilizatorilor.
Dezvoltarea profesională a devenit mai uşoară datorită folosirii aceloraşi instrumente în
diferite zone ale organizaţiei, iar aplicaţiile au devenit mai uşor de implementat, de
upgradat şi de întreţinut, rezultând economii de timp şi bani.
(Sursa: http://www.businessobjects.ro/produs_detail.php?id=37)
Totuşi, nu dorim să se înțeleagă de aici că implementarea unui BI este o

decizie uşoară , bazată pe enunțarea unui set coerent de avantaje indubitabile.
Practicienii şi consultanții din sfera BI recomandă şi aici utilizarea unei metodologii
de implementare (una dintre cel mai bine apreciate este cea propusă de Gartner25).
Aceasta descompune activită țile de planificare şi execuție la nivel de organizație,
afacere, funcționalită ți şi componente de infrastructură . La nivelul afacerii şi al
organizației, se porneşte de la obiectivele strategice şi tactice ale implementă rii,
pentru a stabili dacă există competențele şi infrastructura necesare atingerii acelor
Inc. Gartner, Using Business Intelligence to gain a competitive edge. A special Report, 2004,
25
www.gartner.com
obiective. Top‐managerilor le revine sarcina de a armoniza cultura organizațională

cu inițiativa BI, pentru a să di entuziasmul necesar succesului acestui proiect.
Un alt aspect fundamental pentru succesul unei implementă ri BI este
integrarea acestuia în sistemul informatic al organizației, în care există deja alte
aplicații şi sisteme: diverse baze de date, suite ERP, aplicații CRM sau SCM, aplicații
moştenite, aplicații e‐business – toate furnizoare de date pentru noul sistem BI.
Situația în care toate aplicațiile (sau majoritatea) provin de la un singur furnizor este
cea mai fericită din punctul de vedere al efortului de integrare.
Nu în ultimul râ nd, o chestiune spinoasă , mult disputată , este cea a utilizării
efective a aplicaţiilor de BI implementate. Există o diferență uriaşă între
prognoza de utilizare a tehnologiilor BI şi folosirea lor efectivă . Se reproşează
adesea lă sarea „pe dinafară ” a utilizatorilor obişnuiți, iar cauzele identificate26 sunt:
 dificultatea de a utiliza datele furnizate;
 lipsa de timp a utilizatorilor obişnuiți pentru a‐şi dezvolta abilită țile la un
nivel mai ridicat decâ t cel rudimentar;
 nivelul de educație tehnologică al utilizatorilor este limitat;
 furnizorul de soluții BI a exagerat în privința uşurinței de utilizare a soluției
implementate;
 instruirea a fost prea puțină , inadecvată, fă ră sprijin din partea organizației
(cum ar fi centrul de competență în BI);
 problemele de afaceri sunt prea complexe pentru utilizatorul obişnuit.
Utilizarea „pe scară largă ” a aplicațiilor BI presupune o abordare diferită de
cea din proiectele mici, departamentale. Ea cere o abordare holistică , obiective
stabilite la nivel de organizație şi depunerea de eforturi pentru crearea unei
infrastructuri BI de care să beneficieze toată lumea.
Nu toate inițiativele de tip BI sunt realizate cu succes, iar cele care sunt sortite
eşecului aduc pierderi însemnate organizațiilor. Ca orice proiect de anvergură , şi
acesta comportă anumite riscuri. Riscurile tipice unui proiect de implementare a
unei soluții Business Intelligence bazate pe tehnologia depozitelor de date sunt
prezentate în continuare.
Riscurile organizaţionale. Susțină torii proiectului trebuie să provină din
zona conducerii strategice a afacerii, şi nu din zona strategică IT. Avâ nd în vedere
dimensiunea şi scopul, o inițiativă Business Intelligence trebuie să fie orientată pe
afacere, altfel organizația va considera întregul efort ca fiind un experiment
tehnologic. Susțină torul proiectului trebuie să fie o persoană care va utiliza
depozitul de date şi care îşi poate asuma responsabilitatea inițiativei. Riscurile
organizaționale provin şi de la utilizatorii finali care pot obstrucționa, intenționat
sau nu, evoluția proiectului. În funcție de cunoştințele tehnice pe care le au şi de
cultura organizațională , utilizatorii trebuie abordați cu atenție în toate fazele
proiectului.
26M. Biere, The New Era of Enterprise Business Intelligence: Using Analytics to Achieve a Global
Competitive Advantage, IBM Press, 2010, p. 15.
Riscurile tehnologice. În această categorie se încadrează folosirea inadecvată

a tehnologiilor data warehouse, calitatea scă zută a sistemelor operaționale
existente, instrumente nepotrivite pentru utilizatorul final. Folosirea inadecvată a
tehnologiilor depozitelor de date apare atunci câ nd se încearcă utilizarea lor în
scopul rezolvă rii problemelor operaționale ale organizației sau pentru a se
implementa soluții în timp real. De asemenea, utilizarea mai multor minidepozite de
date disparate nu poate constitui un factor de succes sigur, deoarece sistemul
informațional din cadrul organizației trebuie să funcționeze într‐un cadru unic.
Calitatea scă zută a sistemelor operaționale poate determina echipa de dezvoltare a
depozitului de date să‐şi concentreze atenția mai mult pe „cură țarea” şi verificarea
datelor de intrare, neglijâ nd esențialul depozitului de date. În acelaşi timp, un sistem
operațional defectuos va ridica probleme la extragerea, transformarea şi încă rcarea
datelor în depozitul de date. Utilizatorii potențiali ai depozitului de date nu‐l vor
apela dacă informațiile pe care le oferă sistemul sunt eronate sau dubioase. Ceea ce
contează foarte mult este percepţia asupra calită ții datelor, indiferent dacă datele
sunt corecte sau nu. În fine, oferta largă de instrumente pentru utilizatorii finali
trebuie bine analizată înainte de a decide ce instrument va folosi fiecare categorie de
utilizatori.
Riscuri legate de managementul proiectului. Unul dintre aceste riscuri este
determinat de definirea nerealistă a anvergurii proiectului. Literatura de specialitate
recomandă ca un astfel de proiect să înceapă cu o etapă‐pilot şi apoi depozitul de
date să fie dezvoltat incremental. Specialiştii consideră că organizațiile care mizează
pe proiecte monolitice de amploare foarte mare vor întâ mpina dificultă ți în
gestionarea situațiilor care apar şi vor avea şanse foarte mici de a termina cu bine
ceea ce au început. În contrast, dezvoltarea incrementală reduce riscurile şi
minimizează pierderile.
Multe proiecte data warehouse au eşuat din cauza subestimă rii timpului
necesar operațiunilor de extragere, integrare şi transformare a datelor. Deşi poate
pă rea neobişnuit, este realist ca pentru aceste operațiuni să se aloce un timp
important din durata întregului proiect. Practica a dovedit că pentru operațiunile
back‐end (extragere, integrare, verificare calitate, agregare, încă rcare) trebuie să se
aloce între 60 şi 80% din durata proiectului, iar pentru operațiunile front‐end
(instrumente OLAP, rapoarte, interogă ri), între 20 şi 40%27. Echipa de dezvltare
trebuie să se concentreze atent pe partea de back‐end, deoarece pe ea se sprijină
cealaltă componentă , care nu poate fi implementată pâ nă câ nd nu este funcțională
prima.
Managementul proiectului trebuie să se preocupe şi de ceea ce se întâmplă
dincolo de implementarea depozitului de date: utilizatorii noi care au acces la
funcționalită țile depozitului trebuie instruiți, utilizatorii vechi trebuie înştiințați
despre modifică rile care apar şi, de asemenea, se recomandă monitorizarea
activită ții depozitului de date în primul an (contorizare înregistră ri frecvente,
27 M. Humpries, M. Hawkins, M. Dy, op. cit., p. 65.

statistici despre căută rile care se efectuează ) pentru a optimiza structura şi

interogă rile.
Riscuri legate de proiectarea depozitului de date. Echipa tehnică trebuie să
fie bine pregă tită , iar experiența din zona bazelor de date se poate dovedi inutilă. În
timp ce sistemele OLTP relaționale mizează pe normalizarea relațiilor şi pe înregis‐
trarea eficientă a tranzacțiilor, depozitul de date trebuie gâ ndit ca un cub de date
multidimensional care conține tabele denormalizate, agregă ri, variabile etc. O
greşeală frecventă care se face constă în alegerea greşită a gradului de granularitate.
Depozitul de date conține atâ t date atomice, câ t şi date sintetice. O granularitate
prea mare nu permite obținerea rapoartelor detaliate de care au nevoie managerii,
în timp ce un grad scă zut de granularitate conduce la necesitatea efectuă rii unui
numă r mare de agregă ri şi la capacită ți sporite de stocare.
8.4. Oferta de soluţii Business Intelligence
Piața de aplicații business intelligence a trecut prin transformă ri importante în

ultimii patru ani, cea mai notabilă fiind consolidarea ei. Dacă în primii ani ai lansă rii
acestor soluții vorbeam despre o piață fragmentată între numeroşi furnizori mici,
specializați şi independenți, astă zi avem una dominată de cei patru fantastici: SAP,
Oracle, IBM şi Microsoft (în unele prezentă ri se vorbeşte despre The Big Five, care
adaugă în top şi SAS Institute – cei cinci dețin peste 75% din piața BI).
8.4.1. Principalii ofertanţi
Business Objects, Cognos, Hyperion, SAS şi MicroStrategy au creat primele

aplicații de BI, le‐au perfecționat de‐a lungul anilor (toți avâ nd cel puțin 15 ani pe
piața BI în anul 2007) şi au dominat piața de BI la începutul anilor 2000 28. Doar SAS
şi MicroStrategy au rezistat asaltului marilor case de software şi au ră mas furnizori
independenți.
Business Objects era în 2005 o companie cu o cifră de afaceri de un miliard
de dolari care opera exclusiv în domeniul BI. Deşi are un nume pur englezesc,
compania este de origine franceză , fiind înființată la Paris, în 1990. Primul să u client
mare a fost France Telecom, iar în 1994 era prima companie franceză listată la bursa
din New York. Platforma ei de BI se numeşte BusinessObjects şi a cunoscut
numeroase versiuni de la lansarea în 1994. BusinessObjects XI este o suită completă
de BI, de la raportare şi interogare, la facilită ți avansate de management al
performanței. BO are 46.000 de clienți în întreaga lume. Peste 80% dintre
companiile din topul „Fortune 500” sunt clienți Business Objects. Pe 7 octombrie
2007, SAP AG a anunțat achiziția BO, pentru 6,8 miliarde de dolari. Business Objects
a devenit o divizie SAP, iar numele platformei a devenit „SAP BusinessObjects”. Prin
această mişcare, SAP a devenit numă rul 1 mondial şi pe piața BI.
28Business Objects, Cognos, Hyperion au format topul primilor trei furnizori de soluții BI în perioada
2000‐2005.
Hyperion Solutions a fost o companie americană care a activat predilect în

zona aplicațiilor de Business Process Management, avâ nd şi celelalte aplicații pentru
o platformă completă de BI. Anul 2007 i‐a adus recunoaşterea Gartner, care a plasat‐
o în cadranul de lideri, dar a însemnat şi sfâ rşitul unei epoci, deoarece la 18 aprilie
2007 s‐a finalizat achiziția ei de că tre Oracle, pentru 3,3 miliarde de dolari.
Spre deosebire de cazurile SAP şi IBM, Oracle are propria ofertă de soluții BI
(Oracle BI Suite Enterprise Edition şi multe pachete de aplicații analitice cu
specializare funcțională – de exemplu, Oracle Sales Analytics), fiind liderul
incontestabil al pieței depozitelor de date. Marele avantaj vine din faptul că soluțiile
sale BI se integrează cu orice sistem de baze de date din lume, în firme de orice
dimensiune. Succesul să u în domeniul BI este evident: zece din primele zece bă nci
din lume, 20 din primele 20 de companii de telecomunicații şi zece din primele zece
universită ți din lume sunt clienți Oracle.
Cognos a fost o companie canadiană , cu vechime pe piața aplicațiilor pentru
afaceri (1969). În cea mai bună perioadă a sa avea 3.500 de angajați şi 23.000 de
clienți în întreaga lume, iar cifra de afaceri se apropia de un miliard de dolari în
2007. Pe 31 ianuarie 2008 s‐a finalizat achiziția de că tre IBM pentru suma de 4,9
miliarde de dolari, marcâ nd înfrâ ngerea ultimei redute de software BI
independent29. Cognos a devenit parte a diviziei IBM Information Management.
Ultima versiune lansată (2005) este Cognos 8, la care s‐a adă ugat, din 2009, Cognos
Express, un pachet integrat de planificare şi analiză gâ ndit special pentru firmele
medii.
În ianuarie 2010, IBM a finalizat reorganizarea pe zona de software, creâ nd o
nouă divizie denumită Business Analytics, care include ofertele Cognos şi cele de
programe de analiză statistică SPSS, deoarece în iulie 2009 IBM a cumpă rat şi SPSS
Inc. pentru 1,2 miliarde de dolari.
SAS Institute este un producă tor de software cu vechime pe piața americană
(1976), fiind inițial orientat spre dezvoltarea de sisteme de analiză statistică. Astă zi,
oferta sa de aplicații depă şeşte cu mult aceste limite, dar a preferat să mențină
numele, care a că pă tat notorietate în urma succesului primelor programe statistice.
SAS este lider incontestabil pe domeniul aplicațiilor analitice (business analytics) şi
este cel mai mare furnizor independent din sfera BI. Are peste zece mii de angajați
(fericiți, se pare, că ci în 2010 SAS a fost pe primul loc în clasamentul „100 Best
Companies to Work For”, realizat de revista Fortune Magazine) şi peste 45.000 de
clienți în peste 100 de ță ri (91 dintre primele 100 de companii din topul 2010
FORTUNE Global 500 folosesc aplicații SAS).
Cu zece ani în urmă, Microsoft a revoluționat aplicațiile BI30, fă câ nd
instrumentele OLAP şi data mining accesibile profesioniştilor IT direct în bazele de
29 Este bine de ştiut că aceste mişcă ri de fuziuni şi achiziții au avut loc permanent pe piața BI, dar la
valori mult mai mici decâ t cele trei achiziții de răsunet. Însuşi Cognos este campion la cumpă rarea de
firme mici: 4Thought, Relational Matters, LEX2000, Interweave, DecisionStream, NoticeCast, Adaytum,
Frango, Databeacon şi Celequest, iar în 2007 a cumpă rat Applix, un jucă tor mai mare de pe piața BI
(vezi detalii la http://www.bi‐verdict.com/fileadmin/FreeAnalyses/ consolidations.htm).
30 Vezi mai multe detalii la http://en.wikipedia.org/wiki/Microsoft_Analysis_Services
date relaționale (OLAP Services, inclus în SQL Server 7). Platforma sa de BI31 se
bazează pe SQL Server, Microsoft Office şi SharePoint pentru infrastructura întregii
platforme, iar strategia sa actuală 32 este ră spâ ndirea Business Intelligence în întreaga
organizație. Un Business Intelligence invaziv, care este disponibil tuturor, va fi oferit
printr‐o suită bazată pe instrumentele cu care utilizatorii sunt obişnuiți zi de zi
(Office) şi nu o suită cu instrumente specializate, care să necesite o nouă instruire.
Concret, această ofertă poartă numele Microsoft Dynamics GP Business Intelligence.
Dezvoltarea platformei Microsoft BI se face într‐o echipă virtuală, din care fac
parte lideri şi dezvoltatori de Office, SharePoint şi SQL Server. Business Intelligence
Development Studio (BIDS) este mediul de dezvoltare integrat utilizat pentru a
dezvolta aplicații de analiză a datelor şi aplicații BI, utilizâ nd Microsoft SQL Server
Analysis Services, Reporting Services şi Integration Services. Se bazează pe mediul de
dezvoltare Microsoft Visual Studio, customizat cu servicii şi extensii ale SQL Server.
Viziunea Microsoft are în centru lă rgirea bazei de adoptare într‐o firmă (de la
o rată de utilizare între 10 şi 20% indicată de rapoarte la 40, 60 şi chiar 80% din
utilizatorii din firmă ) şi încurajarea utiliză rii. Ea se bazează pe bogatul ecosistem de
parteneri Microsoft, care pot construi şi livra soluții specializate şi nu doar o
platformă generală cu instrumente specializate.
Argumentarea acestei strategii porneşte de la o întrebare simplă : cine ia
deciziile în firmă ? Dacă , la prima vedere, doar persoanele din vâ rful ierarhiei (CEO,
director, preşedinte) trebuie să ia decizii eficiente care să aducă succesul în
organizație, în fapt, planurile eficiente dezvoltate de conducerea de la vâ rf pot eşua
tocmai din cauza deciziilor greşite luate de persoane din pă rțile inferioare ale
ierarhiei în procesul de implementare sau în cel de execuție. Microsoft
argumentează astfel ideea că deciziile eficiente trebuie luate de toți cei din
organizație, indiferent de nivelul ierarhic.
MicroStrategy este o firmă americană fondată în 1989, care s‐a impus pe
piața BI cu aplicații OLAP şi de raportare, avâ nd realiză ri notabile în domeniul
bazelor de date multidimensionale, bazate pe arhitectura ROLAP (Relational OLAP).
Firma se mâ ndreşte să aibă clienți precum: Lowe’s, McDonald’s, Universal Studios
Hollywood, DHL Express sau Priceline.com. Avâ nd o cifră de afaceri de 377 milioane
de dolari (2009) şi operațiuni în 23 de ță ri, nu este o amenințare reală pentru marii
furnizori. Ultima versiune a suitei lor este MicroStrategy 9, lansată în 2009, dar
interesant de urmă rit va fi pachetul MicroStrategy Mobile, lansat în iulie 2010, care
mută aplicațiile BI pe iPhone şi iPad.
Pe lâ ngă aceşti furnizori de top, pe piața BI mai gă sim furnizori de nişă (cu
specializare strictă ) şi vizionari (cei care propun soluții inovatoare). De asemenea,
gă sim furnizori cu oferte de BI on demand, bazate pe modelul SaaS sau cloud
computing, precum şi oferte de soluții BI open source.
31http://www.microsoft.com/bi/productsbi/#
32 Informațiile sunt culese dintr‐un interviu publicat în SQL Server Magazine pe 24 martie 2010,
disponibil la adresa http://www.sqlmag.com/article/business‐intelligence/tom‐casey‐on‐microsoft‐s‐
bi‐strategy.aspx
Soluţiile BI open source au câ ştigat teren în ultimii patru‐cinci ani. Ele nu au

complexitatea celor proprietare, dar cuprind toate funcționalită țile definitorii
pentru BI. Pentaho, unul dintre jucă torii importanți33 oferă Pentaho Open BI Suite,
care include: ETL, raportare operațională şi analitică , data mining şi analize OLAP,
tablou de bord într‐o ofertă de implementare flexibilă, cu plata pe baza unui
abonament anual. O altă ofertă vine de la Jaspersoft34, o firmă cu o creştere
importantă în 2009: JasperSoft Business Intelligence Suite, realizat pe baza
JasperReports, cea mai populară soluție open source Java de reporting, care cuprinde
o gamă largă de produse Business Intelligence, furnizâ nd raportă ri robuste, raportă ri
interactive, analize de date şi capacitatea de integrare a datelor. Din cercetă rile
noastre reiese că Jaspersoft ofertează şi pe piața româ nească prin intermediul unui
partener local35.
8.4.2. Piaţa mondială de aplicaţii de Business Intelligence, aplicaţii

analitice şi de management al performanţelor
Conform rapoartelor Gartner (dintre care vom prezenta mai multe idei şi cifre
în continuare36), piața de soluții BI a fost într‐o continuă creştere, chiar şi în anii
2009 şi 2010, aferenți crizei. Anul 2011 a adus o creştere semnificativă de 17%, ea
temperâ ndu‐se în 2012 la nivelul de 7%, depă şind 13 miliarde de dolari. La fel ca
celelalte categorii de aplicații pentru afaceri, nici BI nu au ră mas imune în fața
recesiunii, creşterea continuă arată că proiectele BI nu au fost abandonate. Conform
raportului (vezi toate cifrele în tabelul 8.7), SAP deține locul 1 cu 22,1% (în uşoară
scă dere față de 2008‐2009, dar în creştere față de 2011), urmat de Oracle (cu
aproape 15%), apoi IBM şi SAS Institute (fiecare cu 12%) şi la oarecare distanță (dar
în creştere) Microsoft (9,1%).
Tabelul 8.7
Piaţa mondială de soluţii BI (în milioane de dolari)
Venit total în Cota de piaţă Venit total Diferenţa 2012
Producători
2012 2012 (%) în 2011 faţă de 2011 (%)
SAP 2.902,5 22,1 2.884,0 +0,6
Oracle 1.952,1 14,9 1.913,5 +2,0
IBM 1.625,0 12,4 1.478,8 +9,9
SAS 1.599,7 12,2 1.542,9 +3,7
Microsoft 1.189,3 9,1 1.059,9 +12,2
Alții 3.861,9 29,3 3.416,0 +13,0
Total 13.131,1 100.0 12.295,1 +6,8%
Sursa: Gartner Press Release, 6 iunie 2013, http://www.gartner.com/newsroom/id/2507915
33 The Pentaho BI Project a fost pornit în 2004 de un grup de veterani ai industriei de Business
Intelligence. Vezi mai multe pe site‐ul firmei: http://www.pentaho.com/
34 http://www.jaspersoft.com/
35 Vezi http://www.apal.ro/
36 Disponibile la http://www.gartner.com/newsroom/id/2507915
Pe segmente de piață (vezi structura în figura 8.16), liderii sunt diferiți: SAP
conduce pe platforme de BI, Oracle este lider pe CPM (managementul performanței),
iar SAS este numă rul 1 în sfera aplicațiilor analitice – la fel ca şi pâ nă acum. Noutatea
vine de la IBM, care a venit puternic din spate în toate cele trei segmente
menționate.
Sursa: http://www.gartner.com/it/page.jsp?id=1357514, aprilie 2010.

Figura 8.16. Structura pieţei de Business Intelligence
Dacă în 2010, Gartner estima că în 2014 piața de BI va ajunge la 13 miliarde de

dolari, iată că acest nivel a fost deja depă şit în 2012. Ei au apreciat o creştere
similară , de 7% şi pentru anul 2013, iar pe termen lung, o valoare de 17 miliarde de
dolari în 201637. În opinia analiştilor, există o orientare serioasă că tre ofertele de
cloud computing sau SaaS, ca şi cele open source. De asemenea, se aşteaptă cu interes
ră spunsul pieței la ofertele de BI mobil. Primele implementă ri s‐au realizat în 2007,
pe echipamente BlackBerry, iar acum s‐au extins şi la iPhone şi iPad, în condițiile
interesului tot mai mare al oamenilor de afaceri că tre echipamentele mobile Web
2.0, prin care se pot conecta permanent pentru a‐şi conduce firmele. Noul val
tehnologic este fă ră îndoială internetul mobil şi va avea un impact de zece ori mai
mare asupra firmelor decâ t internetul clasic. Argumentul? Există peste şase miliarde
de utilizatori de telefoane mobile38, față de un miliard de utilizatori de PC‐uri. Se
aşteaptă o avalanşă de aplicații pentru echipamentele mobile, iar BI este categoria la
care se aşteaptă o creştere formidabilă .
8.5. Direcţii de evoluţie a Business Intelligence
Business Intelligence a cunoscut dezvoltarea la cote neaşteptate pentru că a

depă şit faza de rapoarte tipă rite sau grafice prezentate pe ecran. Râ ndurile unui
raport de vâ nză ri, spre exemplu, pot conține informații detaliate şi exacte, dar nu
37 http://www.gartner.com/newsroom/id/2340216
38 http://mobithinking.com/mobile‐marketing‐tools/latest‐mobile‐stats/a#subscribers
reprezintă o soluție de Business Intelligence pâ nă câ nd nu sunt puse într‐un
format care poate fi uşor înțeles şi interpretat de o persoană de decizie în
vederea stabilirii unei soluții eficiente pentru o situație particulară întâ lnită în
activitatea
Business Intelligence curentă . Un aspect
– noua generaţie important
de sisteme de asistare pentru
a deciziilorevoluția sistemelor BI
30 l‐a
constituit menținerea performanțelor acestor sisteme în contextul creşterii
utiliză rii lor. Din ce în ce mai multe companii au început să folosească sistemele
de BI, ceea ce a fă cut ca avantajul competițional dobâ ndit să fie fragil şi efemer.
Soluțiile Business Intelligence se concentrau pe oferirea de înțelegere asupra
datelor şi nu dispuneau de instrumentele necesare pentru implementă rile de
schimbă ri operaționale. În ultimii ani, BI s‐a dezvoltat tocmai prin apariția unui
nou tip de BI: aplicațiile de management al performanței (BPM/CPM) şi
aplicațiile analitice, bazate pe metode statistice şi econometrice, deosebit de
atră gă toare pentru realizarea de previziuni.
Aceste noi direcții ale BI au permis crearea unui model de afacere care
permite companiilor să ‐şi alinieze scopurile cu activită țile zilnice de derulare a
afacerii. Soluțiile de BI s‐au dezvoltat prin orientarea spre tipuri de afaceri, un
interes mare revenind tablourilor de bord şi instrumentelor de „descoperire a
datelor”, cu o vizualizare uşoară , atractivă şi rapidă a rezultatelor.
Credem că se pot formula două mari direcţii de evoluţie pe piața BI,
aflată în continuare sub o zodie norocoasă , dat fiind că BI ră mâ ne pe primul loc
pe lista de priorită ți tehnologice ale organizațiilor contemporane:
1) consolidarea ofertelor de platforme BI ale primilor cinci furnizori din
top (tendință observată din 2009, câ nd platformele au început să înlocuiască
suitele de aplicații BI);
conturarea unui segment consistent de utilizatori BI ondemand, care nu pot depă şi bariera
costurilor şi complexită ții unei soluții BI onpremise. Cloud computing va influența radical
implementarea sistemelor informatice şi, împreună cu SaaS, se constituie într‐o alternativă
atractivă pentru firmele mici şi mijlocii, ținute pâ nă acum departe de barierele de costuri şi
complexitate

Business Intelligence - Noua Generaţie de Sisteme de Asistare A Deciziilor

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Business Intelligence - Noua Generaţie de Sisteme de Asistare A Deciziilor

Încărcat de

Drepturi de autor:

Formate disponibile

Business Intelligence – noua generaţie de sisteme de asistare a deciziilor 26

Business Intelligence – noua generaţie

8.1. Definirea conceptului de Business Intelligence

Ră dăcinile acestui concept se gă sesc în anii ’70 în sistemele de raportare ale

lui Dresner, conform că reia „BI va deveni parte integrantă a sistemului

Deşi este legat de aplicațiile de întreprindere, în opinia noastră BI nu este un

Sursa: Mă ză reanu, V., „«Inteligență » în Business Intelligence”, Analele Ştiinţifice ale

Beneficiile utiliză rii sistemelor BI pot fi sistematizate astfel:

Promovarea acestui nou tip de „inteligență economică ” nu i‐a lă sat indiferenți

8.2. Arhitectura şi componentele unui sistem BI

8.2.1. Componentele unei soluţii BI

Un sistem BI are patru componente importante:

Într‐un sistem BI se regă seşte o combinație de arhitecturi şi tehnologii

Instrumente ETL. Procesul de populare a DD se realizează prin activită țile

Tabloul de bord (dashboard). Oferă o viziune comprehensivă asupra

8.2.2. Locul depozitelor de date întrun sistem BI

8.2.2.1. Definire şi caracteristici

După W.H. Inmon, pă rintele conceptului de data warehouse, „un depozit de

15 D. Airinei, Depozite de date, Editura Polirom, Iaşi, 2002, pp. 21‐22.

 să „jongleze” cu nivelurile de acces sinteză /detaliu la date;

cazurilor, pe tehnologii relaționale. Totuşi, ele nu au fost proiectate pornind de la

Un sistem OLTP este orientat pe client şi este utilizat pentru procesarea

pentru stocarea şi gestionarea informațiilor cu diferite niveluri de granularitate.

Inmon şi Battas definesc un ODS ca „o construcție arhitecturală unde este

Literatura de specialitate prezintă mai multe situații în care un depozit de date

Procesul de creare a rapoartelor este foarte anevoios. Rapoartele de

8.2.2.2. Arhitecturi pentru depozite de date

Instrumente pentru accesare şi utilizare

Date puternic agregate Datamart

Figura 8.4. Arhitectura simplificată a unui depozit de date

Sursele de date pentru depozitele de date sunt: bazele de date operaționale

interogare gen SQL sau generatoare de rapoarte ce transpun informațiile în formate

Date sursã OLAP

Încãrcare date Sisteme de alertã

Figura 8.5. Componentele software ale depozitelor de date

Din punctul de vedere al ariei de cuprindere, se întâ lnesc trei modele de

Un depozit virtual (Virtual Warehouse) este constituit dintr‐un set de viziuni

8.2.3. Analiza multidimensională

Globalizarea, evoluțiile economice tot mai dificil de anticipat, acțiunile

Sistemele de procesare a tranzacțiilor folosesc de obicei standardul relațional,

Clienţi Conturi Ordine

Tip produs Produse

Figura 8.6. Exemplu de structură normalizată

Vânzările de produse pe clienţi

Pentru a înlesni munca de obținere a datelor, se foloseşte modelarea

Figura 8.8. Exemplu de arhitectură tip stea

Unul dintre principiile‐cheie ale modelă rii multidimensionale este folosirea

Grupa Subgrupa Categorie Produs

Figura 8.9. Tabele Produs normalizate

Tabelele normalizate sunt cauza dificultă ții cu care un utilizator navighează

Figura 8.10. Ierarhii dimensionale

Câ nd utilizatorii depozitului de date navighează prin el pentru a afla informații

Figura 8.11. Interogare prin poziţionare în cadrul ierarhiilor

Figura 8.12. Raport obţinut prin poziţionarea în cadrul ierarhiilor

Gradul de detaliere poate fi modificat prin operațiunile de drilldown (mai

Figura 8.13. Raport obţinut prin operaţiunea drilldown

Un aspect important îl reprezintă gradul de granularitate, care indică nivelul

fiecare înregistrare Magazin reprezintă un magazin, atunci „granula” tabelei de

Dacă o interogare necesită… Atunci trebuie manipulate

Dacă agregă rile ar fi calculate şi stocate astfel încâ t fiecare înregistrare

 este simplă. Oferă posibilitatea proiectanților de depozite de date să

8.2.4. Tehnologii OLAP

Operațiunea slice execută o selecție pe o dimensiune a unui cub dat, rezultâ nd