Informatizarea Unui Proiect

Introducere

Pentru a castiga un avantaj competitiv, o companie trebuie sa identifice cu rapiditate oportunitatile din piata si sa profite de acestea intr-o maniera rapida si eficienta. Tot mai multe companii realizeaza ca o cantitate mare de date nu inseamna neaparat o intelegere mai buna a pietei sau o imbunatatire a performantelor operationale. Business Intelligence a devenit un cuvant obisnuit in domeniul IT insa este inca un concept pe care nu toata lumea il intelege, de aceea , multe intrebari referitoare la acest domeniu incep sa apara.

Termenul de Business Intelligence (BI) a fost introdus la mijlocul anilor ’90 de catre Gartner Group. Conceptul a fost folosit inca de la inceputul anilor ’70 insa sistemele de raportare erau bidimensionale, fara a avea capacitati analitice. Cererea unor sisteme multidimensionale care sa poata sprijini procesele decizionale , cu abilitati predictive a dus la dezvoltarea sistemelor de tip business intelligence. Toate aceste sisteme devin din ce in ce mai complexe, capabile de analize multidimensionale a datelor si de analize predictive pentru a servi mai bine sistemelor de asistare a deciziilor.

“În timp ce există o largă plajă de definiții date inteligenței, poate că cea mai reprezentativă este cea oferită de U.S. Central Intelligence Agency (CIA) [Waltz, 2003]: „redus la cei mai simpli termeni, inteligența este cunoștința și modul în care (pre-) simțim lumea din jurul nostru – preludiul deciziilor și acțiunilor politicienilor[…]”. Aceste componente clasice ale inteligenței furnizează înțelegere și determină leaderii în a lua deciziile care furnizează securitate pentru afaceri sau pentru state.”

Capitolul 1 – Analiza mecanismului economic

1.1 Definirea problemei

În condițiile actuale de piață a apărut necesitatea ca marii producători să-și definească anumite standarde de prezentare , sortiment și comunicare și preț în cadrul punctelor de vânzare cu amănuntul astfel încât implementarea acestor standarde să creeze un avantaj competitiv în raport cu competiția lor directă. Definirea iar apoi implementarea standaredelor atrage după sine nevoia unei verificări permanente a gradului de implementare. Problema pe care doresc să o adresez este informatizarea procesului de verificare ținând cont de două scopuri precise : colectarea și procesarea datelor într-un mod eficient din punct de vedere al costurilor și raportarea într-un format acționabil în timp real în vederea corectării neconcordanțelor constatate în timpul verificării.

1.2 Analiza mecanismului economic care urmează a fi informatizat prin proiect

De regulă, standardele de execuție sunt menite să definească elemente legate de mixul de marketing :

Produs – definirea sortimentului de produse ce urmează a fi distribuite în diferitele tipuri de magazine. De exemplu, într-un magazin cu autoservire din mediul urban, sortimentul țintă este mai larg față de sortimentul dintr-un magazin cu servire la tejghea din mediul rural. Sortimentul este definit diferit în funcție de canalul de vânzare. În baruri/restaurante , sortimentul este orientat spre produse la gramaje mai mici, în scopul consumării la fața locului, pe când în magazinele de retail , se pune accentul pe produse cu gramaje mai mari.

Distribuție – după stabilirea listei de produse care se dorește a fi prezentă pe diferitele canale și sub canale, standardele de execuție trebuie să permită asigurarea unui stoc minim pe parcursul întregii perioade astfel încât să se evite situațiile de rupere de stoc.

Preț – Stabilirea sortimentului și asigurarea stocurilor necesare în punctele de vânzare nu este deajuns în cazul în care prețurile de vânzare cu amănuntul nu sunt armonizate cu prețurile practicate de către competitori și nu sunt în linie cu așteptările și bugetele consumatorilor țintă. Din acest motiv, standardele trebuie să conțină și elemente ce țin de prețurile produselor. De exemplu, o companie poate decide că produsul „a” trebuie să fie vândut în fiecare locație la un preț cu 5% mai mic decât produsul „b” al competitorului. Acesta este un exemplu de standard de preț.

Promovare – Dat fiind faptul că este vorba despre standarde de execuție în punctul de vânzare, standardele legate de elementul promovare se referă în primul rând la comunicarea din magazin, de exemplu, prin postere, pahare imprimate cu logo-ul companiei, display-uri imprimate șamd .

Toate aceste standarde se stabiliesc cu scopul de a crește numărul de vânzări și implicit profitul.

Figure 1 – Mixul de marketing

1.3 Definirea funcționalităților proiectului

După definirea standardelor elementelor prezentate anterior, sarcina implementării cade pe umerii agenților de vânzări și/sau merchandiserilor. În cazul companiilor care utilizează un sistem de distribuție indirect sarcina aceasta cade pe umerii reprezentanților de vânzări ai diferiților distribuitori. Cu toate acestea , respectarea standardelor fiind un obiectiv strategic , verificarea permanentă a gradului de implementare se face de regulă de o echipă dedicată de auditori interni sau externi companiei astfel încât să se aigure obiectivitate și acuratețe.

Pentru a putea face acest lucru se folosește :

O aplicație care functioneza pe suporți accesibili(telefon mobil), este flexibilă în definirea chestionarelor de verificare, permită legătura între locații, datele colectate și responsabilul cu implementarea standardelor, permite colectarea coordonatelor geografice pentru a asigura prezența auditorului, permite efectuarea pozelor ca suport pentru datele colectate și permite trimiterea datelor colectate în timp real pentru a fi verificate.

Baza de date – datele sunt stocate într-o bază de date Oracle

Sistemul de raportare – pentru raportarea datelor, se folosește sistemul Oracle Business Intelligence.

Figure 2 – Oracle Business Intelligence

Aplicația își propune analiza și cuantificarea unor indicatori de performanță a unei companii în vederea îmbunătățirii activității de vânzare.

Indicatorii cheie de performanță (Key Performance Indicators, KPI) sunt elemente de bază ale procesului de măsurare și monitorizare a performanței, oferind vizibilitate în raport cu performanță indivizilor, echipelor, departamentelor și organizațiilor.

Această aplicație oferă posibilitatea dezvoltării unor raportări pentru orice KPI dorit, de exemplu, indicatorul de prezență la raft reflectă procentul în care produsele urmărite se găsesc în locațiile auditate,astfel clientul poate monitoriza și lua măsuri în timp real în caz că prezența produsului nu este ridicată sau cea dorită. Datele sunt livrate în timp real, clienții având acces la ele la orice oră.

Rapoartele dezvoltate permit personalizări în funcție de cerințele clientului (culori, filtre, font sau formule de calcul personalizate).

O altă funcționalitate importantă a proiectului este posibilitatea clienților de a-și exporta datele în diverse formate (excel, pdf, powerpoint) . Aceștia le pot salva și le pot folosi mai departe în diverse prezentări sau calcule. Totodată, ei pot adăuga sau exclude coloane/filtre din raport, astfel având o perspectivă asupra datelor din mai multe direcții.

Aceste rapoarte se pot transforma în grafice dinamice, oferind o imagine de ansamblu asupra situației.

Capitolul 2 – Tehnologii folosite in dezvoltarea aplicatiei

2.1 Ce este Inteligenta Afacerii

“Inteligența Afacerii (IA) se referă la capacitatea de a tranforma date existente în informație utilă care să furnizeze perspective bogate și, mai ales, noi asupra lumii afacerilor din prezent și să ofere o idee spre ce se îndreaptă acesta în viitor. Inteligența Afacerii înseamnă utilizarea tuturor datelor de care dispune o firmă, pentru a îmbunătăți procesul decizional. Acest lucru presupune accesul la date, analiza lor și descoperirea de noi oportunități de utilizare a lor.”

Sistemele informatice pentru inteligența afacerii oferă aplicații care ajută utilizatorii să răspundă la întrebările ce apar în rezolvarea problemelor de afaceri. Necesitatea inteligenței afacerii apare în urma dorinței de creștere a veniturilor și reducerea costurilor , gestionarea și modelarea mediului de afaceri curent și reducerea costurilor informatice.

Nevoia unui sistem informatic pentru Inteligența Afacerii este dată de următoarele aspecte :

Reducerea timpului de obținere a informațiilor

Sistemele pentru Inteligența afacerii pun accentul pe livrarea și accesul în timp real al informațiilor.

Gestionarea și modelarea mediului de afaceri curent

Sistemele informatice pentru Inteligența Afacerii oferă mai mult decât mecanisme de interogare și raportare, ele oferă instrumente de analiză a informațiilor complexe, de stocare a volumelor uriașe de date, de data mining.

Reducerea costurilor informatice

Investiția în sistemele informatice reprezintă un procent semnificativ din cheltuielile firmelor. De aceea, este necesar nu numai să se reducă aceste cheltuieli dar și să se obțină beneficii maxime din informațiile stocate și prelucrate de sistemele informatice, care folosesc , în acest sens, noi tehnologii.

IA necesită o capacitate de a procesa un număr foarte mare de date și de a executa calcule complexe. Bazele de date proiectate pentru IA trebuie să fie optimizate pentru crearea de rapoarte deoarece ar putea fi stocate cantități mari de date istorice .

Tabel 1 – Diferenta intre sistemul pentru Inteligenta Afacerii si un sistem de procesare tranzactii

Soluțiile din domeniul inteligenței afacerilor oferă posibilitatea de înțelegere a consumatorului , de analiză a vânzărilor, de a indentifică orice oportunitate de câștig sau reducere a costurilor și de a îmbunătăți cu totul procesul decizional.

Inteligența Afacerii este un domeniu de ultimă oră care vizează organizarea,funcționarea și conducerea unei întreprinderi. Cunoașterea acestui domeniu are ca bază experiență acumulată în dezvoltarea unei întreprinderi în mediul de piață și în mediul digital. Toate aceste cunoștințe au fost îmbogățite în ultimii ani cu ajutorul resursei informațională.

În ultimii ani, tehnologia și-a spus cuvântul și au apărut numeroase instrumente software performate pentru Inteligența Afacerii. Stadiul este unul avansat, mai ales pe plan extern însă nivelul de cunoaștere în domeniu nu este nici pe departe atins.

Depozitele de date și instrumentele de analiză multidimensională (OLAP – Online Analitycal Processing) au permis crearea unor sisteme foarte complexe care furnizează acces la baze de date orientate pe decizie și combină funcționalitatea accesului direct la date ale generatoarelor de rapoarte cu posibilitățile analitice ale sistemelor multidimensionale.”(Spre noua economie digitală prin inteligența afacerii, Manole Velicanu).

Din păcate , această tehnologie nu este lipsită de probleme. Cele mai frecvente care apar in accesarea informațiilor sunt :

obținerea datelor durează prea mult și este în general tardivă;

analiza influențează negativ performanță tranzacțiilor;

informațiile necesare apar într-un format necorespunzător;

informațiile sunt rareori consistente și supuse unor modificări constante;

interogarile ad-hoc sunt dificile.

Sistemele informatice pentru Inteligența Afacerii au și avantaje :

includ în arhitectura lor cele mai avansate tehnologii informatice și sunt deschise spre integrarea tehnologiilor care pot să apară;

pun accentul pe furnizarea și accesul informațiilor către mai multe categorii de utilizatori și oferă suport atât pentru cei specializați în informatică cât și pentru alte categorii de utilizatori;

permit accesul la toate tipurile de date descrise și manipulate de diferitele calculatoare, inclusiv tipuri noi de date și depozite de date.

Obiectivele unui sistem pentru Inteligența Afacerii sunt:

să permită soluții având costuri scăzute eficiente pentru firmă;

să permită accesul rapid și ușor la informațiile firmei pentru un număr mare de utilizatori (autorizați) de toate categoriile;

să ofere suport pentru noi tehnologii (sisteme OLAP, depozite de date etc.);

să ofere un mediu de lucru scalabil și deschis.

2.2 Arhitectura sistemului pentru Inteligenta Afacerii

Soluțiile informatice pentru IA necesită acces la toate tipurile de informații referitoate la organizație și clienții săi. Această poate include date din sistemele tranzacționale , date din aplicațiile companiei, date istorice , precum și din alte surse. Anumite sarcini analitice (precum rularea unor rapoarte zilnice și accesul la informații ad-hoc) necesită acces direct la sursele de date. Alte tipuri de sarcini necesită lucru fragmentat asupra depozitelor de date. Un depozit de date organizează informațiile într-un mod util, consistent și inteligibil, facilitând analizele standard, adhoc și avansate. O soluție cu IA completă permite utilizatorilor să interogheze datele la sursă, dar oferă și instrumente puternice pentru proiectarea, generarea și utilizarea depozitelor de date (data warehouse) și concentrarilor de date (data marts). Platforma data warehouse trebuie să poată manipula o diversitate de informații și să ofere instrumente pentru analize complexe inclusiv reprezentarea datelor multidimensional și ierarhic.

Arhitectura sistemelor pentru Inteligența Afacerii cuprinde următoarele componente :

depozitele de date;

concentrările de date;

cererile de regăsire care pot fi diverse și complexe însă totodata ușor de format;

instrumente de analiză multidimensională;

aplicații analitice;

aplicații pentru monitorizarea performaței unei afaceri;

aplicații pentru analize strategice.

Pentru toate acestea există produse software specifice, oferite ca atare sau, de cele mai multe ori, ca instrumente complementare (extensii) la un sistem de gestiune a bazelor de date.

2.3 Data Warehouse

O definiție a depozitelor de date formulată de către Consiliul OLAP este următoarea :

“Un depozit de date reprezintă o stocare centralizată a datelor detaliate provenite din toate sursele relevante din cadrul unei organizații ce permite interogarea dinamică și analiza detaliată a tuturor informațiilor.”

Spre deosebire de sistemele operaționale, structurile de date într-un depozit de date sunt optimizate pentru o regăsire și o analiză rapidă. Datele sunt istorice și sunt actualizate la intervale regulate de timp, în funcție de cerințele de raportare.

Scopul unui depozit de date este de a furniza un stoc central unde datele din mai multe sisteme pot fi consolidate intr-o singura , integrata si consolidata sursa de date.Depozitul de date este conceput pentru a optimiza crearea de rapoarte pentru un numar mare de inregistrari.

Datorită obiectivelor impuse de utilizarea depozitelor de date în analiză, se desprind câteva caracteristici mai importante pe care acestea le dețin:

depozitul de date trebuie să asigure accesul la datele companiei. Accesul trebuie să fie imediat, la cerere și să fie performant.

datele trebuie să fie consistente. Consistența presupune faptul că atunci când două persoane solicită același set de informații să primească aceleași date, chiar dacă ele au fost cerute la momente de timp diferite. Dacă datele nu au fost complet încărcate atunci utilizatorul va fi avertizat cu privire la acest lucru și este sfătuit să aștepte până ce vor fi complet încărcate;

datele într-un depozit de date pot fi separate și combinate pentru a oferi un acces cât mai rapid și un timp de răspuns cât mai mic sistemului;

depozitele de date nu reprezintă doar datele, ci și un set de utilitare pentru a interoga, analiza, prezenta informațiile;

datele din depozite sunt utilizate direct în analize, fără alte prelucrări suplimentare.

calitatea datelor din depozitele de date este un factor determinant pentru procesul de reculegere a datelor. Se întâlnește frecvent situația în care datele sunt de bună calitate, dar nu sunt colectate în întregime sau au un caracter opțional.

Arhitectura de baza a unui depozit de date presupune ca utilizatorii să poata accesa direct datele chiar dacă acestea au fost încarcate din mai multe surse. Însă , in funcție de necesitățile companiei, arhitectura depozitului de date poate varia .

În cadrul unui data warehouse, din punct de vedere funcțional, există trei niveluri distincte de realizare.

Modulul operațional

Acest mod reprezintă toate datele instituției care sunt , de obicei, păstrate în diverse forme (fișiere,baze de date din alte SGBD-uri).Indiferent de unde provin datele, ele trebuie sa fie aduse într-o formă consistentă pentru a fi folosite. Transformarea datelor presupune un proces de extragere, condiționare, curățare, fuziune, validare și încărcare Acest proces de transformare a datelor reprezintă baza pe care se construiește un depozit de date consistent, de înaltă calitate.

Modulul central al depozitului de date

Acest modul este compus din SGBD și serverul pe care rulează acesta și de modul în care este implementat depozitul (sistem distribuit sau sursa de date unică).

Modului strategic, de afaceri

Acest modul este nivelul în care toate datele sunt prezentate analistului pentru interpretare. Prin folosirea diferitelor unelte de acces la informație și a tehnologiilor data mining disponibile, utilizatorii pot obține informații care îi vor ajuta în procesele de stabilire a strategiei firmei. Instrumentele de cereri grafice, prezentările, rapoarte scrise, browser-ele Web, instrumente de vizualizare a datelor, toate aparțin acestui nivel.

Figure 5 – Modulele functionale ale depozitului de date

Depozitele de date pot fi categorisite și din punctul de vedere al ariei de cuprindere.

Depozitul central al organizatiei

Acesta colecteaza toate datele ce privesc intreaga organizație, provenind din diferite surse și integrându-le într-un singur depozit de date. Depozitul central furnizeaza un volum foarte mare de date ce poate ajunge la sute de terrabytes sau chiar mai mult.

Data marts

Data marts-urile sunt subseturi de date specifice unui grup de utilizatori (departamente). Datele sunt limitate la subiecte specifice din cadrul departamentului. Din această cauză, volumul de date este mult mai redus ceea ce înseamnă întreținere mai ușoară și mai ieftină decât la depozitul central iar ciclul de implementare poate dura câteva săptămâni, nu ani ca la depozitul central.

Depozitul virtual

Virtual warehouse(depozitul virtual) este un set de viziuni asupra bazelor de date relaționale.Un astfel de depozit este ușor de construit însă extragerile și prelucrările datelor revin serverului de baze de date , ceea ce duce la un timp de prelucrare ridicat însă se elimină necesitatea unui depozit real.

2.4 Modelul dimensional al depozitului de date

Modelul dimensional este un concept des întâlnit în construirea unui depozit de date. Într-un astfel de model, datele sunt stocate în două tipuri de tabele numite „Fact Table” (tabela de fapte) și „Dimensional Table”(tabela de dimensiuni).

Tabela de fapte conține măsurători,metrici sau fapte ale proceselor de business. De exemplu, pentru un proces de vânzare, o astfel de măsurătoare poate fi vânzarea totală lunară. Aceasta este stocată în tabela de fapte. Înafară de măsurători, în tabela de fapte sunt stocate și cheile străine pentru tabela de dimensiuni.

Tabela de dimensiuni este bazată pe subiecte. Bazându-ne pe exemplul dat mai sus, caracteristicile stocate într-o tabela de dimensiuni pentru procesul de vânzare pot fi : produsele vândute, locațiile în care s-au vândut, pe ce dată s-au vândut, etc. Atributele dimensionale sunt diversele coloane din tabela de dimensiuni.

Figure 6 – Modelul dimensional

În modelul dimensional putem crea diferite scheme care se mulează pe nevoile noastre. Avem nevoie de diverse scheme pentru a putea realiza variatele task-uri pe care le putem avea. Există trei scheme diferite : schema stea, fulg și constelație.

Schema stea este cel mai simplu tip de schemă unde tabela de fapte este situată în centru schemei , înconjurată de multiplele tabele de dimensiuni. În schema de tip stea, toate tabelele de dimensiuni sunt legate doar de tabela de fapte și nu între ele.

Figure 7 – Schema stea

Acest tip de schemă este una dintre cele mai populare datorită simplității și flexibilității ei. Fiecare informație poate fi obținută doar traversând un singur join, deci acest tip de schemă este ideală pentru selectarea datelor (procesare de interogări foarte rapidă).

Schema de tip fulg este asemănătoare cu cea stea, diferența fiind faptul că unele dintre tabelele de dimensiuni au legături atât cu tabela de fapte cât și între ele. Această schema, față de stea, are un nivel de normalizare mai mare.

Figure 8 – Schema fulg

Schema de tip constelație este mai complicată și complexă decât celelalte două tipuri( stea și fulg) deoarece implică multiple tabele de fapte . Această caracteristică permite tabelelor de dimensiuni să fie împărțite între tabelele de fapte.

Figure 9 – Schema constelatie

2.5 Data Mining

Inteligența Afacerii are ca scop obținerea informațiilor din datele disponibile, date localizate , de preferat, într-un depozit de date centralizat. Procesul de transformare a datelor în informații și a informațiilor în decizii este ciclic. În afara unui context, datele nu reprezintă nimic. Ele devin informații numai în cadrul unui context de business.

Figure 10 – Mediul pentru Inteligenta Afacerii

Aplicațiile de data mining îmbogățesc mediul inteligenței afacerilor prin posibilitățile pe cae acesta le oferă de descoperire a cunoștințelor. Aplicațiile OLAP oferă deja un mediu în care se poate face analize rapide pe datele de business. Rezulatele analizei OLAP generează întrebări care își găsesc răspunsul în următoarele analize OLAP, de aceea , acest tip de analiză a datelor este unul orientat spre verificare.

Analizele de tip data mining vor identifica noi cunoștințe, pe cont propriu, fără să fie necesară intervenția factorului uman. Analizele data mining sunt orientate spre descoperirea unor noi cunoștințe.

Instrumentele de data mining analizează datele pentru a evidenția acele relații excepționale între date. De asemenea, aceste instrumente rezolvă probleme de inconsistență a datelor, probleme ce pot fi erori umane în procesul de introducere al datelor în sistemele informatice și informaționale.

Data Mining-ul este un proces ce presupune utilizarea unor tehnici de învățare automată pentru extragerea cunoștințelor din date.

Etapele unui proces de explorare a datelor (data mining) sunt în general următoarele:

Definirea problemei – pentru o utilizare cât mai eficientă a tehnicilor de explorare trebuie mai întâi specificate foarte clar obiectivele studiului. De exemplu, în cazul unei campanii de direct mailing, obiective precum “creșterea numărului de răspunsuri”, “creșterea ratei răspunsurilor” sau “diminuarea costului per răspuns” sunt obiective diferite, care vor necesita metode de analiză diferite. Definirea clară a obiectivelor ne va ajuta ulterior și la măsurarea eficienței procesului;

Selectarea tehnicii care va fi utilizată – pornind de la problema specifică de rezolvat;

Selecția și pregătirea datelor. Aceasta este etapa care consumă cel mai mult timp (între 50 și 85 la sută din timpul total alocat proiectului). După cum spuneam anterior, calitatea rezultatului final depinde foarte mult de acuratețea datelor de intrare;

Construirea modelului – ținând seama de tehnicile de analiză alese și de natura datelor pe care le avem la dispoziție;

Prezentarea rezultatelor finale, sub forma unor rapoarte conținând text, tabele și grafice;

Monitorizarea modelului, în vederea măsurării eficienței și utilității sale

Figure 11 – Procesul de data mining

2.6 Oracle Business Intelligence

Oracle a achiziționat de-a lungul timpului diferite companii în domeniul BI (Siebel, Endeca, Hyperion). Aceștia doresc să domine spațiul BI care include competiție din partea SAP BO, IBM Cognos și alții.

Suita Oracle Business Intelligence a fost concepută pentru a fi ușor de integrat atât cu sursele de date existente cât și cu infrastructura IT utilizată. Rezultatul final îl reprezintă rapoarte și analize de înaltă complexitate, obținute din date aflate în mai multe surse, oferind utilizatorului ușurință maximă în utilizarea, configurarea și împachetarea acestora.

Componentele suitei Oracle Business Intelligence Enterprise Edition :

Figure 12 – Componentele suitei Oracle Business Intelligence

Oracle Interactive Dashboards ( Tablouri de bord interactive)

Oferă colecții de analize complete și interactive, disponibile într-o varietate de modalități de afisare.În mediul Oracle Business Intelligence Dashboards, utilizatorul final lucrează cu rapoarte vii, prompturi, grafice, tabele, tabele pivot, pe o arhitectură Web. Utilizatorul are capacitatea deplină de navigație, modificare, sortare, filtrare, exportare în fișiere Microsoft Office.

Figure 13 – Oracle Interactive Dashboards

Oracle Answers (Analize Ad-Hoc)

Este o componentă 100% orientată spre nevoia fiecărui utilizator în parte. Aceștia interacționează cu datele, putând crea propriile rapoarte, folosind definiții, ierarhii și calculi.

Oracle Answers oferă utilizatorilor interogări Ad-Hoc și capabilități de analiză. Utilizatorii pot procesa date din mai multe surse într-un mediu web. Mai mult, ei lucrează numai cu modelul logic al informației, fiind privați de structurile de date complexe din spatele aplicației.

Figure 14 – Oracle Answers

Oracle Business Intelligence Reporting and Publishing (Rapoarte predefinite tipărite)

Permite crearea de rapoarte și documente predefinite care utilizează date și informații ce se actualizează periodic .

Figure 15 – Oracle BI Publisher

Oracle Delivers (Notificari si Alerte)

Oferă posibilitatea trimiterii automate de alerte atunci cand au loc anumite evenimente (nivel critic stoc, vanzări versus estimări, șamd.) Alertele pot fi trimise prin e-mail, SMS, alertă în Tabloul de bord etc.

Figure 16 – Oracle Delivers

Oracle Disconnected Analytics (Pachete de analize deconectate)

Toate facilitățile oferite de Tablourile de bord interactive și Analizele Ad-hoc sunt disponibile și offline.

Oferă sincronizarea inteligentă a datelor relevante pentru fiecare utilizator, odată ce utilizatorul se reconectează la rețeaua companiei.

Oracle Office Plug-In (Conectarea cu aplicatiile de tip Microsoft Office)

Asigură un mod eficient de interacțiune cu sistemul Business Intelligence prin intermediul Microsoft Excel.

Figure 17 – Oracle incorporat in Microsoft Office Excel

Oracle® Business Intelligence Server

Un motor de calcul puternic care este capabil să optimizeze cererile spre mai multe surse de date, integrând surse de date disparate și prezentând rezultatele într-un model de business simplificat și unitar.

Figure 18 – Oracle Business Intelligence

2.7 Arhitectura OBIEE

Dacă ar fi să reducem arhitectura OBI la strictul necesar, putem spune că aceasta se compune dintr-o interfață pentru utilizator a BI Presentation Services- și o interfață pentru sursa de date a Serverul BI.

Figure 19 – Arhitectura OBI Simplificata

Serviciul de prezentare BI primește o selecție de componente de prezentare făcute de un utilizator, construiește o interogare SQL foarte simplă și apoi o trimite către serverul BI. În cazul următorului exemplu, fișierul jurnal afișează comandă SQL trimisă către serverul BI :

Figure 20 – Inteogare SQL lansata catre serverul BI

Din perspectiva serviciului de prezentare OBIEE, toate valorile componentelor de prezentare corespund valorilor coloanelor dintr-o singură tabela a -€numită „Intersnack_BG_BMM” în acest exemplu .

Serverul BI transformă această simplă interogare în subinterogari SQL optimizate și trimite fiecare dintre aceste subinterogari la sursele de date corespunzătoare. În cazul exemplului de mai sus, avem o singură sursă de date iar fișierul jurnal listează comada SQL trimisă către serverul Oracle astfel:

Figure 21 – Transformarea interogarii SQL

După cum se vede, interogările corespund, diferența făcând-o doar formatarea.

Serverul BI așteaptă rezultatele să fie returnate , le integrează și realizează toate calculele pe care nu le-ar putea efectua sursele de date. După ce acestea sunt făcute, serverul BI trimite rezultatele către serviciul de prezentare BI în formatul simplificat pe care acesta îl așteaptă. Serviciul apoi „înfrumusețează” datele transformându-le într-o tabelă , pivot table sau grafic înainte de a le trimite înapoi către browserul web al utilizatorului.

Împărțind diagrama în patru componente, obținem :

Interfața cu utilizatorul : acest nivel este accesibil utilizatorilor și conține componente precum dashboard-urile interactive, instrumente de alertare și altele.

Oracle BI Interactive Dashboards sunt paginile Web interactive care ghidează utilizatorii spre decizii eficiente cu ajutorul rapoartelor personalizate .

Instrumentele de alertare oferă posibilitatea de programare a rapoartelor să trimită inștiințări pe dispozitivele mobile , e-mail sau dashboard-uri pentru a fi la curent în orice moment cu schimbarile în timp real petrecute în rapoarte , ajutând astfel utilizatorul în luarea deciziilor bazate pe informațiile de ultimă oră.

Pe scurt putem spune ca aceasta componenta vine în ajutorul clienților și satisface nevoile de afaceri.

Catalogul și serverul de prezentare : serverul de prezentare este un server web pe care OBIEE își rulează aplicațiile. Acesta menține comunicarea între client și serverul BI. Catalogul de prezentare stochează aplicațiile de tip rapoarte, prompturi și dashboard și conține și informații cu privire la permisiunile pentru acestea.

BI Server și Administration Tool : Serverul BI este centrul întregii arhitecturi. El integraza eficient datele din surse relaționale, surse nestructurate, surse Oracle dar și non-Oracle. Serverul BI preia cererea unui raport de la serverul de prezentare , o procesează și formează interogări logice și fizice pe care apoi le trimite la sursele de date . Serverul BI utilizează componenta BI Repository pentru transformarea cererii de la utilizator în interogări logice și fizice. BI Repository utilizează metadatele prin care serverul primește informații privind legăturile dintre tabele și la filtrele folosite.

BI Repository este format din trei nivele(fizic, BMM și nivelul de prezentare) și este creat folosind aplicația BI Administration Tool :

Nivelul fizic definește toate conexiunile bazei de date sau sursei de date ( numele de utilizator și parolele sunt introduse și stocate aici ) , tabelele și coloanele fizice , relații dintre tabele, cheile primare și străine .

Nivelul BMM(Business Model and Mapping) , făcând referință la nivelul fizic, este locul unde se construiesc structurile logice și unde sunt definite regulile de agregare.

Nivelul de prezentare face referință la nivelul BMM și este cel care prezintă tabelele și coloanele către utilizatorul final. Aici se pot schimba numele coloanelor sau se pot șterge coloane nedorite.

Figure 22 – Oracle BI Administrator Tool

Sursa de date : conține bazele de date cu care serverul OBIEE interactionează. Acesta functionează și pe diverse tipuri de surse de date (XML, Oracle, SQL Server etc).

Atunci când se crează un repository, tabelele folosite sunt importate în nivelul fizic , unde se fac legăturile între tabele. După aceea, se trece în BMM unde se definesc regulile de agregare. Următorul pas este nivelul de prezentare unde se fac ultimele modificări pentru a putea fi folosite tabelele.

Capitolul 3 – Analiza si proiectarea sistemului informatic

3.1 Analiza intratilor in concordanta cu iesirile

Procesul de prelucrare și livrare a datelor este unul relativ simplu dar care poate dura puțin mai mult timp. În funcție de cerințele clienților, livrarea datelor se face lunar, bimestrial sau bianual.

Procesul de preluare, prelucrare și livrare a datelor constă din următorii pași :

Colectarea datelor – Auditorii merg în magazinele cerute de clienți și colectează datele cu ajutorul aplicației. După terminarea unui chestionar, acesta îl trimite prin FTP către server, acolo unde datele sunt inserate în baza de date cu ajutorul unei alte aplicații care rulează scripturi de insert și merge.

Validarea – Pe parcursul lunii(lunilor), diverse verificări sunt făcute asupra datelor pentru a ne asigura că eliminăm eventualele erori apărute în urma auditului. Aceste erori pot fi de natură umană sau electronică(întreruperi de internet, întreruperi de semnal în timpul trimiterii chestionarelor în sistem). Toate aceste verificări se rezolvă tot cu ajutorul auditorilor. În urma rulării scripturilor destinate Quality Check-urilor, se exportă erorile și se trimit auditorilor pentru a fi corectate. Aceștia le corectează și le trimit înapoi spre a fi actualizate corecturile și în sistem.

Crearea rapoartelor – La cererea clientului, putem customiza rapoartele sau folosi formule de calcul personalizate. Cu cât raportul este mai complex, cu atât perioada de predare este mai mare.

Livrarea datelor – Datele se livrează la o dată prestabilită în contract. Odată ce rapoartele sunt actualizate cu noile date, ele se verifică de către Key Accounts și se fac eventuale corecturi.După aceea, clienții vor fi informați că datele sunt încărcate în rapoarte.

Inițial, datele intră în sistem sub formă de chestionare, unde sunt prelucrate, ca la final să se transforme în indicatori și să ajute la creșterea performanței unei companii.

3.2 Stabilirea necesarului de resurse software si hardware

Pentru aplicația dezvoltată , în primul rând, este nevoie de Oracle Business Intelligence 11g instalat pe un server . Că să poată rula platforma Oracle Business Intelligence, serverul ar trebui să aibă spațiu disponibil de cel puțin 20 GB, o memorie RAM de 4 GB sau mai mult, un procesor ce minim 1.5 GHz dual core și bineînțeles internet.

Toate aceste cerințe sunt minime când vine vorba de instalarea platformei. Dacă se dorește o performața mai bună, viteză mai mare și timp de răspuns mai mic, cerințele hardware cresc de aproape două ori.

Din punct de vedere software, este nevoie de un sistem de operare performant (Windows XP SP2 sau mai sus), MS SQL Server 2005 Enterprise Edition instalat pe server, pentru a face legătura între Oracle Business Intelligence și baza de date Oracle, Microsoft .Net Frame Work 3.5 SP2 sau mai sus pentru a asigura interoperabilitatea limbajelor de programare, RCU(Repository Creation Utility 11.1.1.3) pentru a încărca schema bazei de date în Oracle Business Intelligence, cea mai nouă versiune de SQL Developer și , bineînțeles, ultima versiune de Oracle Business Intelligence.

Nu se recomandă să se instaleze ultima versiune de Oracle Business Intelligence pe server dacă există deja o versiune mai veche.

3.3 Analiza si proiectarea codurilor (inclusiv aspecte ale validarii datelor)

Când vine vorba de proiectarea codurilor, trebuie să avem în vedere câteva aspecte importante :

Influența tipului și structurii codului asupra performațelor sistemului informatic;

Implicațiile utilizării codurilor în operațiile de culegere a datelor și interpretarea rezultatelor finale de către utilizatori.

Influența tipului și a structurii codului poate genera probleme de ordin tehnic în realizarea nomenclatorului de coduri și are în vedere facilitarea operațiilor de prelucrare.

Când vine vorba de implicațiile utilizării codurilor, trebuie să i se acorde o atenție mai mare pentru a ușura activitatea de culegere și verificare a datelor și interpretarea rezultatelor .

În activitatea de proiectare a sistemului de codurilor, se cere să se respecte o serie de cerințe :

Să se analizeze elementele ce urmează a fi codificate;

Să se precizeze sși uniformizeze tehnologia , denumirile;

Să se stabilească caracteristicile și relațiile dintre elementele ce urmează a fi codificate;

La alegerea codurilor, să se estimeze lungimea, capacitatea și formatul codurilor;

Crearea nomenclatorului de coduri;

Intreținerea nomenclatorului.

Baza de date aferentă aplicației dezvoltate a fost creată având în minte și aceste aspecte, astfel, aproape fiecare atribut din baza de date are asociat un cod.

De exemplu, pentru tabela Suppliers, atributele sunt Supplier_id(Number(4)) si Supplier (Varchar(255)), tabela Categories cu atributele Category_id(Number(4)) și Category(Varchar(255)) și exemplele continuă.

3.4 Proiectarea bazei de date

Proiectarea unei baze de date constă din proiectarea schemei conceptuale (logice) și fizice a acesteia, astfel Încât să răspundă cerințelor utilizatorilor pentru un anumit set de aplicații.

În general, se consideră că proiectarea unei baze de date se poate diviza În următoarele faze:

• Colectarea si analiza cerintelor.

• Proiectarea conceptuala a bazei de date.

• Alegerea unui SGBD.

• Proiectarea logica a bazei de date.

• Proiectarea fizica a bazei de date.

Cele cinci faze de proiectare enumerate mai sus nu se desfășoară strict într-o singură secvență. În multe cazuri este necesară modificarea proiectului dintr-o fază inițială Într-una din fazele ulterioare, pentru a se obține rezultatele dorite. Înainte de a proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se așteaptă utilizatorii potențiali să obțină de la baza de date respectivă și ce informații primare sunt disponibile pentru aceasta. De asemenea, este necesar să se cunoască ce aplicații se vor efectua (în acest caz aplicații de raportare).

La proiectarea bazei de date s-au stabilit ce informații sunt importante în vederea creării unor rapoarte detaliate și din cât mai multe perspective. Există două direcții de raportare : la nivel de locație(și a atributelor locațiilor) și la nivel de SKU (și a atributelor SKU-urilor) . Pentru ca aceasta să fie posibilă, clientul este rugat să furnizeze aceste informații. Toate acestea sunt introduse în sistem și pot fi folosite în rapoarte.

Baza de date a fost gândită astfel încât să poată fi folosită cât mai ușor și să ofere cât mai multe posibilități de modelare a rapoartelor.

În procesul proiectării bazei de date s-a pornit de la relații nenormalizate și printr-o serie de pași s-au descompus structurile de date pentru a obține schema finală a bazei de date. Totodată, s-au avut în vedere câteva obiective :

baza de date să înmagazineze datele necesare obținerii de informații descrise În faza de analiză a cerințelor precum și orice interogare ce poate fi pusă la un moment dat de către utilizator;

tabelele să fie construite corect și eficient; fiecare tabel din baza de date reprezentând o singură entitate și fiind compusă din câmpuri distincte, păstrând o redundantă minimă a datelor, fiecare înregistrare dintr-un tabel putând fi identificată cu ajutorul unei valori unice;

integritatea datelor se impune la nivel de tabel, câmp, relație; aceste nivele de integritate ajută la garantarea faptului că structurile de date impreună cu valorile acestora sunt valide și precise în orice moment;

baza de date să suporte regulile specifice domeniului pe care îl modelează; datele trebuie să ofere informație validă și precisă, având tot timpul înteles;

structura bazei de date să fie ușor de modificat sau extins odată cu modificarea cerințelor impuse.

Au fost greu de realizat toate aceste obiective, dar s-a dorit un proiect corect al bazei de date care să aibă În vedere obținerea cât mai rapidă a rezultatelor. Aplicarea tehnicilor de proiectare a condus la obținerea următoarelor beneficii:

structura bazei de date este ușor de modificat și gestionat deoarece modificările efectuate asupra unui camp sau tabel nu afectează alte campuri sau tabele ale bazei de date;

datele sunt ușor de modificat deoarece modificarea valorii unui camp dintr-un tabel nu afectează valorile altor campuri din același sau alte tabele ale bazei de date;

informațiile sunt ușor de extras deoarece se pot crea cu ușurintă interogări deoarece tabelele sunt corect alcătuite iar relațiile sunt stabilite în mod corespunzator;

aplicațiile create de utilizator sunt ușor de proiectat și gestionat.

Primul pas in proiectarea bazei de date a fost cel de definire al cerințelor datelor specifice domeniului.

În acest scop s-au definit:

tipurile de informații;

categoriile de informații necesare sistemului;

regulile specifice domeniului;

constrângerile aplicate;

tipurile de rapoarte generate;

scopulu principal al tuturor informațiilor;

securitatea necesară;

informațiile ce urmează a fi extinse.

Al doilea pas este gruparea solicitărilor în tabele distinct. Definirea tabelelor asociate bazei de date este un pas esențial în proiectarea acesteia din cauza faptului că definirea cerințelor nu conține și informații legate de structura tabelelor. De aceea se studiată informația solicitată la ieșire și se împarte în teme fundamentale care se doresc a fi urmărite (furnizori, categorii de produse, puncte de vânzare, orașe etc).

Următorul pas este reprezentat de determinarea câmpurilor necesare.Pentru a realiza această determinare, se stabilește ce informații se doresc știute(memorate în baza de date) pentru entitățile definite la pasul anterior(nume furnizor, numele categoriilor, denumira punctelor de vânzare, numele orașelor etc).

Cel de-al patrulea pas este stabilirea cheilor primare și secundare care vor lega tabelele între ele. În cadrul acestui pas intervine proiectarea codurilor. Pentru fiecare entitate, cheia primară este de preferat să fie un cod semnificativ pentru informația stocată însă este bine și dacă notarea începe de la 1 și pe măsură ce se adaugă informații, codul să fie incrementat.

Apoi, în cel de-al cincilea pas, se stabilesc legăturile dintre tabele (unu – la – unu, unu – la -“ mulți, mulți – la – mulți ). După împărtirea informațiilor în tabele separate, este nevoie să se specifice care este modalitatea de a o recompune în diverse moduri, deoarece, informația de ieșire poate conține elemente ale mai multor entităti, deci din mai multe tabele.

Ultimul pas în proiectarea bazei de date este implementarea. Cu ajutorul limbajului de definire a datelor existent în SGBD-ului, s-a creat structura bazei de date și fișierele bazei de date.

Din toate acestea a rezultat următoarea schemă logică a bazei de date, conținând 38 de tabele .

Capitolul 4 – Implementarea sistemului informatic

4.1 Analiza si proiectarea formatelor de intrare-iesire

Există la oră actuală multe limbare de programane, sisteme de gestiune a bazelor de date sau pachete de programe care dispun și de module specializate în crearea și editarea de rapoarte, ceea ce conduce la o reducere considerabilă când vine vorba de eforturile programatorului. De obicei, aceste platforme pentru crearea și editarea de rapoarte solicită precizarea titlului, a antetului de coloană, conținutul rândurilor de date, gradele de total și maniera în care vor fi afișate(la incepulul sau la sfârșitul grupului de date, al paginii sau raportului). De asemenea au și personalizări privind dimensiunile liniilor/coloanelor, a paginilor, spatierea afișarea datelor privind momentul listării și altele.

Astfel de module specializate se regăsesc cu precădere în pachetele de programe care se ocupă de gestiunea bazelor de date, cum ar fi : Oracle, Access, FoxPro, etc.

În faza de proiectare logică se reprezintă doar o ciornă a formularelor/formatelor sau rapoartelor, ele fiind privite doar ca structura și machete.

Pentru crearea unui raport, trebuie urmați o serie de pași pentru a asigura date corecte și complete și un raport de calitate :

Primul pas este asigurarea că toate datele există în baza de date și că nu lipsește nimic. Se compară numărul de chestionare din bază cu numărul de chestionare care trebuie făcut. Dacă cele două numere sunt egale, se trece la următorul pas. În caz contrar, fie se șterg chestionare (în cazul în care există prea multe) , fie se cer auditorilor chestionarele lipsă și se introduc în sistem.

Al doilea pas este validarea datelor. Odată ce toate datele sunt în sistem, acestea trebuie verificate. Sunt rulate câteva scripturi care verifică datele pentru posibile neconcordanțe. În cazul în care aceste verificări scot la iveală posibile greșeli de audit, ele sunt trimise înapoi la auditori spre a fi corectate.

Cel de-al treilea pas este schițarea raportului. Odată ce datele sunt corecte și încărcate în sistem, după diversele verificări și corecturi, se trece la schițarea raportului : se definește formula de calcul, fie că este vorba de o medie simplă sau ponderată, sumă sau formule personalizate, se stabilește designul raportului (font, culori, coloane etc) după cerințele clientului, se aleg prompturile raportului și numele.

A patrulea pas este crearea raportului. În Oracle BI, se crează o analiză nouă și se adaugă rândurile și coloanele stabilite la pasul anterior, filtrele și formula de calcul. După ce raportul este terminat , se verifică folosind un exemplu și comparându-i rezultatul din raport cu rezultatul obținut făcând calculele manual.

Al cincilea pas este livrarea rapoartelor. După ce rapoartele au fost verificate și datele sunt corecte, clienții sunt anunțați că rapoartele sunt create și le pot vedea. Este posibil ca uneori clienții să ceară o coloană în plus , un total sau un filtru chiar după livrarea rapoartelor. Aceste modificări sunt făcute imediat, fără timp de așteptare mare.

4.2 Analiza si proiectarea algoritmilor

În această fază se definesc cerințele scriptului, independent de modul În care acestea vor fi Îndeplinite. Aici se definește problema pe care clientul dorește să o rezolve indiferent că este vorba de o raportare a problemelor sau de o rezolvare a lor.

Rezultatul acestei faze este documentul cerințelor, care trebuie să precizeze clar ce trebuie construit. Documentul Încearcă să redea cerințele din perspectivă clientului, definind scopurile și interacțiunile la un nivel descriptiv Înalt, independent de detaliile de implementare, cum ar fi, de exemplu: formularea problemei, așteptările clientului sau criteriile pe care trebuie să le Îndeplinească produsul.

În general, documentul cerințelor descrie vocabularul de cuvinte cheie care va fi utilizat pentru definirea protocolului specific aplicației. Descrierile acestea nu implică proiectarea arhitecturii aplicației, ci enumerarea părților componente și a modului În care acestea se comportă. Mai târziu, În faza de proiectare, acestea vor fi transformate În primitive informatice.

Mai concret, documentul trebuie să conțină descrieri pentru următoarele categorii:

– Obiecte: Documentul trebuie să definească mai întâi ontologia sistemului, care este bazată în mare parte pe construcții substantivale pentru identificarea pieselor, părților componente, constantelor, numelor și a relațiilor dintre acestea;

– Actiuni: Documentul trebuie să definească de asemenea acțiunile pe care trebuie să le îndeplinească sistemul;

– Scenarii tipice: Când sistemul este terminat și aplicația este disponibilă, clientul trebuie să poată utiliza, într-o manieră cât mai facilă și clar specificată, toate scenariile tipice ale aplicației. Scenariile tipice trebuie să reprezinte majoritatea scenariilor de utilizare ale aplicației;

– Scenarii atipice: Un scenariu atipic trebuie să fie Îndeplinit de sistem numai În cazuri speciale. Clientul poate să spere, de exemplu, că o eroare neprevăzuta este un eveniment atipic. Totuși, sistemul trebuie să gestioneze un număr cât mai mare de categorii de erori.

– Cerințe incomplete: O enumerare completă a cerințelor pentru toate situațiile care pot apărea în condiții de lucru reale nu este posibilă. Mulțimea inițială de cerințe definește posibilitățile sistemului. Noile cerințe pot infirma soluțiile vechi. Pe măsură ce un sistem crește În dimensiuni și complexitate, stabilirea cerințelor devine din ce În ce mai dificilă.

Această analiză se realizează pentru: codul rapoartelor sau codul pentru scripturile de verificare a datelor. Pe bază cerințelor din faza de analiză, acum se stabilește arhitectura scriptului se se începe scrierea codului.