Analiza Informatizata A Profitabilitatii Clientilor DE Carduri
=== Analiza informatizata a clientilor de carduri ===
CUPRINS
Cap. I. Sisteme Informatice pentru Management („Management Information Systems”)
1.1. Organizatia si sistemele informationale
Mediul economic a cunoscut o dezvoltare semnificativa în ultimii 20 de ani marcata în special de efectul de globalizare a economiei si de o crestere ridicata a competitivitatii companiilor. Aceste fenomene au determinat o presiune ridicata asupra organizatiilor de a se transforma si adapta la noile cerinte, dar mai ales de a fi capabile de a se reorganiza si restructura in timp record în functie de necesitatile si evolutia pietelor.
Acest fenomen a coincis si s-a dezvoltat în sinergie cu dezvoltarea informaticii. Astfel, daca la început, sistemele informatice au produs schimbari la nivel tehnic si operational, cu timpul, sistemele informatice au fost utilizate din ce în ce mai mult în activitatile de management.
Astazi, sistemele informatice sunt utilizate la toate nivelele ierarhice si în toate sactivitatile esentiale ale unei organizatii, dezvoltarile cele mai semnificative fiind în asistarea deciziilor manageriale atât la nivel operational, tactic sau strategic (de exemplu identificarea de noi produse, clienti sau furnizori, elaborarea si evaluarea strategiilor de piata si campaniilor de marketing etc).
Noile strategii de management bazate pe implementarea sistemelor informatice au determinat transformari profunde în modul de organizare si operare al organizatiei, dintre care cele mai importante sunt:
Reducerea numarului de niveluri ierarhice ale organizatiei. Practic, piramida organizationala a fost aplatisata, iar nivelele de mijloc ale managementului au disparut. Deciziile aferente acestor nivele au fost fie automatizate (pe baza de sisteme, reguli, proceduri etc) fie delegate nivelului de executie sau nivelului superior de management
Crearea organizatiilor virtuale si eliminarea distantelor. Afacerile se pot organiza si conduce global astazi, în timp ce la nivel local se pastreaza doar nivelul operational. Sistemele informatice sunt conectate în retea (WAN, Intranet, Internet, VPN etc) si permit companiilor sa-si coordoneze la nivel global achizitiile, productia si distributia bunurilor si serviciilor precum si interfata cu partenerii de afaceri (clienti sau furnizori) prin utilizarea organizatiilor virtuale (vezi figura 1.1). Pot exista cazuri in care anumitele departamente sunt distribuite geografic, dar sunt din ce in ce mai frecvente cazurile în care întreaga organizatie este distribuita.
Figura 1.1 Structura unei organizatii virtuale
Crearea organizatiilor flexibile. Tehnologiile informatice moderne permit organizatiilor sa se restructureze la intervale scurte de timp, reorganizâdu-se în diverse moduri pentru cresterea competitivitatii lor.
Dezvoltarea comertului electronic. Sistemele informatice conectate în retea pot permite realizarea de tranzactii on-line (de exemplu: vânzari, achizitii sau plati) folosind mediile electronice ca mediu de interconectare a unei companii cu clientii, furnizorii sau distribuitorii sai.
Restructurarea fluxurilor de documente. Documentele au fost transferate de pe suportul de hîrtie pe cel electronic. Mediul electronic asigura viteza mare de procesare, transfer, regasire precum si capacitati de lucru colaborativ, integrare la costuri foarte reduse care au condus la cresterea productivitatii organizatiei.
Figura 1.2. prezinta arhitectura informatica a unei companii. Sunt prezentate functiile intreprinderii pe care le poate deservi un sistem informatic precum si organizarea acestuia din punct de vedere a nivelelor deservite. Dupa cum se oberva, odata cu cresterea nivelului ierarhic nivelul de sintetizare a informatiilor creste pentru a putea facilita procesul decisional al managementului.
Astfel, în cadrul unei organizatii se pot identifica urmatoarele tipuri distincte de sisteme informatice:
Sisteme informatice pentru procesarea tranzactiilor („Transaction Processing Systems”) sau TPS. Ele se gasesc la nivelul operational al organizatiei si se caracterizeaza prin faptul ca executa si înregistreaza zilnic tranzactiile specifice organizatiei. TPSurile asigura preluarea, stocarea si prelucrarea datelor corespunzatoare tranzactiilor zilnice asigurând actualizarea concurenta si corecta a bazelor de date.
Sisteme informatice pentru automatizarea activitatilor de birou („Office Automation Systems”) sau OAS. Scopul lor este de a asigura procesarea electronica a documentelor, comunicatia interna sau externa organizatiei, precum si instrumentele de colaborare intra sau interdepartamentale etc.
Figura1.2 Arhitectura informatica a unei organizatii
Sisteme informatice bazate pe cunostinte („Knowledge Base Systems”) sau KWS. Aceste sisteme deservesc nevoile informationale ale organizatiei la nivelul de cunoastinte din domeniul de baza sau conexe acestuia, sunt exploatate, in general, de specialistii firmei (de exemplu: ingineri, medici, juristi, cercetatori etc) ca sa extraga, creeze dar si sa integreze noi cunostinte în organizatie.
In prezent se constata o integrare din ce mai mare intre KWS si OAS cu principalul obiectiv de diseminare a informatiilor in organizatie.
Sisteme informatice pentru management („Management Information Systems”) sau MIS. MIS deservesc managementul organizatiei si vizeaza functiile de planificare, control, coordonare si adoptare a deciziilor prin furnizarea de rapoarte si informatii pentru management (ca elemente de baza în asistarea deciziilor sau chiar pentru programarea anumitor decizii). MIS-urile au la baza unul sau mai multe depozite de date („Datawarehouse”) sau DWH în care sunt stocate toate datele interne sau externe organizatiei necesare procesului managerial.
MIS-urile prezinta doua extinderi (DSS si EIS) care au aparut ca urmare a unor cerinte specifice de management. In general, ele deservesc nivelurile ierarhice superioare ale companiei, dar din ce in ce mai frecvent se constata ca organizatiile pot pune DSS-urile si la dispozitia unor nivele ierarhice de baza ale organizatiei in vederea structurarii deciziilor luate la aceste nivele.
Sisteme informatice pentru asistarea deciziilor („Decision Support Systems”) sau DSS. DSS sunt sisteme informatice care combina datele si informatiile disponibile pe baza unor modele de analiza complexe pentru asistarea managementul organizatiei in adoptarea deciziilor (programate, semistructurate sau nestructurate).
Sisteme informatice pentru management executiv („Executive Information System”) sau EIS. EIS asista nivelul strategic de management in luarea deciziilor nestructurate.
Tabelul 1.1 prezinta principalele caracteristici ale sistemelor informatice ale organizatiei.
Tabelul 1.1 Caracteristicile sistemelor informatice
Sursa: Militaru Gh, „Sisteme informatice pentru management; Editura BIC ALL, 2004”
În figura 1.3 sunt prezentate interdependentele dintre sistemele organizatiei precum si modul de transfer al informatiei între acestea.
Se constata rolul decisiv al MIS în arhitectura informatica a organizatiei si de asemenea faptul ca în prezent MIS nu receptioneaza doar date din sisteme operationale, dar si trimite date catre acestea ca de exemplu datele de plan revizuite, deciziile rezultatele din utilizarea DSS (de exemplu noi oferte si contracte etc) sau EIS (planificarea activitatilor pe urmatorii 1-5 ani etc).
Figura 1.3 Interdependentele dintre sistemele informatice ale unei organizatii
1.2. MIS-ul si extinderile acestuia
Rolul unui manager este de a întreprinde acele actiuni care sa conduca la imbunatatirea rezultatelor companiei. Asa cum a fost mentionat in subcapitolul anterior societatea de astazi este caracterizata de o dinamica foarte ridicata iar viteza de luarea a deciziilor si implementare a actiunilor managerului trebuie sa fie in concordanta cu viteza de schimbare a mediului în care opereaza compania respectiva.
În general, managerul transforma informatiile disponibile în actiuni utilizând diverse procese de adoptare a deciziilor. Eficienta actiunilor managerilor depinde de calitatea informatiilor folosite în luarea deciziilor. Astfel, în cazul în care informatiile sint incomplete sau sunt primite cu întirziere, procesul decizional va fi afectat si actiunile managerului pot conduce la rezultate contrare obiectivelor dorite.
MIS-urile au aparut ca o necesitate de a asigura managerilor informatia corecta si completa în momentul necesar luarii unei decizii. Acest lucru a solicitat o formalizare a proceselor ce genereaza informatiile pentru management si crearea unui sistem dedicat acestui proces.
Firmele au dezvoltat dea lungul timpului variate tipuri de MIS în functie de obiectivele si resursele disponibile fie pe baza de solutii proprii, fie solutii achizitionate sau implementate de producatorii specializati sau un mix intre acestea.
Astfel, exista MIS-uri care asigura doar functiile de baza: colectare si transformare a datelor de intrare urmata de structurarea, procesarea, consolidarea si raportarea catre utilizatorii finali.
Literatura de specialitate prezinta astazi si MIS-uri total integrate ce abordeaza intreaga problematica a procesului decizional: de la functiile de baza, la unelte de definire a problemei, la identificarea surselor de date sau informatiilor interne sau externe organizatiei, la înglobarea cunostintelor din domeniul de activitate sau domeniile conexe, identificarea si/sau eliminarea exceptiilor si pîna la unelte de asistare sau programare a deciziilor manageriale.
1.2.1. Sistemele informatice pentru asistarea deciziilor manageriale („Decision Support Systems”)
Sistemele informatice pentru asistarea deciziilor manageriale sau DSS-urile sunt o extensie a MIS-urilor. Ele sunt la baza MIS-uri care au incorporate module avansate pentru îmbunatatirea procesului decizional al managementului unei firme.
În mod frecvent, managerii se confrunta cu variate tipuri de probleme în functie de nivelul ierarhic sau domeniu de activitate. În functie de tipul problemei se identifica trei tipuri de decizii pe care le poate lua un manager:
decizii deterministe, în care se cunosc rezultatele (probabilitatea = 1)
decizii probabilistice, în care se pot estima rezultatele (cu o probabilitate subunitara)
decizii în conditii de incertitudine, pentru care nu se pot estima rezultatele.
Una din cerintele de baza ale managerilor este ca DSS-ul sa produca informatiile într-o forma care poate fi usor înteleasa de utilizatorii finali în momentul când aceste informatii sunt transformate în decizii sau în anumite cazuri chiar sa automatizeze luarea deciziilor prin programarea procesului decizional.
În functie de modul de solutionare a problemei, DSS-urile asigura asistenta managerului unei companii in urmatoarele situatii:
Decizii programate. DSS-ul automatizeaza luarea deciziilor pe baza de proceduri de decizie, reguli prestabilite sau politici ale firmei.
Deciziile neprogramate. Deciziile neprogramate implica solutionari ad-hoc si nu au la baza modele de solutionare. In acest caz, DSS-ul asigura instrumentele de obtinere a informatiilor initiale luarii deciziei.
Decizii semiprogramate. În acest caz, DSS-ul poate genera parte din rezolvarea problemei pe baza unor proceduri predefinite urmând ca restul sa fie rezolvata ca în cazul deciziilor neprogramate. DSS-ul pune la dispozitie managerilor, instrumente de realizare a diverselor scenarii si optimizare a functie obiectiv (în functie de un set de parametrii predefinti).
Dupa cum se observa din figura 1.4 ponderea deciziilor programate din totalul deciziilor luate scade odata cu:
cresterea nivelul managerial catre vârful ierarhiei
scade gradul de structurare a problemelor decizionale.
Sursa: Militaru Gh, „Sisteme informatice pentru management; Editura BIC ALL, 2004”
Figura 1.4 Ponderea deciziilor programate si neprogramate, în functie de nivelul managerului si structurarea problemei
În tabelul 1.2 este prezentata legatura dintre etapele procesului decizional, cerintele informationale si sistemele informatice implicate in finalizarea fiecarei etape.
Organizatia poate avea unul sau mai multe subsisteme pentru asistarea deciziei. Astfel, in functie de scopul cerut, pot coexista subsisteme pentru elaborarea planului de afaceri pentru perioade viitoare (1-5 ani), estimarea efectului cresterii sau scaderii pretului produsului X asupra cotei de piata sau elaborarea de oferte cu estimarea on-line a profitabilitatii etc.
Fiecare din aceste DSS-uri este proiectat cu rolul de a deservi fie o anumita functie a firmei fie sunt utilizate în procesul decizional la un anumit nivel ierarhic. DSS-ul furnizeaza utilizatorilor un set flexibil de instrumente si metode pentru analizarea datelor si informatiilor disponibile în depozitul de date al firmei, utilizeaza instrumente analitice si modele complexe pentru asistarea procesului decizional in rezolvarea problemelor programate, semistructurate sau nestructurate.
Tabelul 1.2 Etape, Cerinte si Sisteme implicate in procesul decizional
În prezent, organizatiile au dezvoltat doua tipuri de DSS-uri:
DSS-uri bazate pe modele. Aceste DSS-uri sunt sisteme independente de sistemul informatic pentru management al organizatiei. Ele combina câteva tipuri de modele pentru a simula diverse optimizari cu subseturi ale depozitului de date special organizate conform cerintelor modelelor. Sunt dezvoltate si implementate, in general, de utilizatorii finali, iar capacitatile lor de analiza au la baza o teorie sau un model bine documentat, dezvoltat si acceptat de catre comunitatea respectiva.
DSS-uri bazate pe date. Aceste DSS-uri analizeaza volume mari de date din depozitul de date al companiei. Ele sustin adoptarea deciziilor prin faptul ca ofera utilizatorilor posibilitatea de a extrage informatiile utile care nu au fost identificate anterior în volumele uriase de date. Asa cum este prezentat in capitolul 4.3, datele rezidente în sistemele de procesare a tranzactiilor (TPS) sunt colectate în depozitul de date pentru analize ulterioare. Aceste analize pot avea un scop clar definit sau pot cauta determinarea unor noi legaturi între date, relatii care în prezent nu sunt cunoscute organizatiei.
Doua tehnologii sunt utilizate în prezent pentru realizarea acestor DSS-uri: Procesarea analitica on-line („On-line Analytical Processing”) sau OLAP si Mineritul în Date (“Data Mining”).
OLAP (Procesarea analitica on-line) permite colectarea, stocarea, prelucrarea si raportarea de date pentru analize multidimensionale.
Datamining este un ansamblu de instrumente de natura statistica, ce permite transformarea datelor în cunostinte. Aceasta tehnologie descopera modele si relatii ascunse între informatiile aflate în depozitele de date, inclusiv reguli care se deduc din ele pentru a previziona comportamentul viitor. Aceste noi modelele si regulile pot fi evaluate de manageri si utilizate în procesul decizional cu estimarea consecintelor aferente variantelor decizionale.
În figura 4.5 este prezentata arhitectura generala a unui DSS. DSS-urile pot avea în componenta toate sau doar un subset al elementelor componente prezentate in functie de necesitatile si resursele organizatiei.
DSS-ul are la baza depozitul de date al organizatiei (DWH) care este alimentat cu date din mediul intern sau extern acesteia. Aceste date sunt in general date istorice extrase din TPS sau din alte surse externe, dar pot include si datele pentru planificarea activitatiilor (orizont de 1-5 ani), prognoze macroeconomice, infomatii despre concurenta (cota de piata, diversi parametrii de interes sau chiar preturile zilnice ale unor produse) si vor fi utilizate pentru interogari si analize.
DSS-ul mai poate contine si una sau mai multe aplicatii care utilizeaza datele din depozitului de date sau un subset off-line al acestora, diverse modele de analiza, instrumentele OLAP si de Data Mining precum si o interfata pentru utilizatorul final.
1.2.2. Sisteme informatice pentru conducerea executiva (“Executive Information Systems”)
Sisteme informatice pentru conducerea executiva (“Executive Information Systems”) sau EIS au rolul de a sustine activitatea decizionala a managerilor care opereaza la nivelul strategic al companiei. Aceste sisteme pun la dispozitia managementului executiv al organizatiei informatiile de care au nevoie pentru asistarea procesului decizional în cazul problemelor nestructurate si semistructurate.
EIS-ul genereaza un mediu informational prin combinarea datelor si informatiilor care pot sa provina atât din surse interne cât si din surse externe organizatiei. EIS-urile sustin activitatea managerilor executivi prin:
monitorizarea performantelor organizatiei pe baza unor indicatori principali de performanta („Key Performance Indicators”) sau KPI
urmaresc activitatile si performantele realizate de organizatiile concurente
identifica oportunitatile si amenintarile la adresa organizatiei precum si problemele decizionale la diverse niveluri de decizie
elaboreaza prognoze economice si prezinta managementului diverse solutii si alternative prin simulari si aplicarea de modele analitice aferente conducerii strategice
Odata ce au fost definiti principalii indicatori de performanta ai organizatiei si managementul strategic incepe monitorizarea acestora prin EIS, este necesara implementarea setului de KPI (sau un subset al acestora) si la celelalte niveluri ierarhice.
Acest lucru va determina modificarea cerintelor de MIS si DSS astfel încât managerii de la nivelurile ierarhice inferioare ale organizatiei sa poata monitoriza aceiasi indicatori de performanta in aria lor de responsabilitate.
EIS-urile utilizeaza date care provin din sisteme variate (interne sau externe organizatiei), sisteme care au fost proiectate initial pentru scopuri diferite. Astfel, cerintele pentru un EIS sunt de a ingloba rezulatele financiare dar si cele nonfinanciare ale companiei, ale competitorilor (prin serviciile on-line cu acces la bazele de date ale pietelor financiare), a diverselor informatii economice si a oricaror alte date publice de care compania are nevoie.
Realizarea EIS-urilor este asemanatoare cu cea a DSS-urilor, deoarece reprezinta o categorie speciala a sistemelor informatice, care se proiecteaza prin metode specifice, în functie de cerintele si modul în care sustin procesul de adoptare a deciziilor.
Deoarece nevoile managerilor executivi se modifica rapid, majoritatea sistemelor EIS sunt proiectate si realizate direct, sub forma de prototip, având drept scop major crearea în mod rapid de valoare adaugata pentru managerii care-l utilizeaza.
Exista mai multe abordari de rezolvare a problemei de integrare a datelor in EIS si care depind de necesitatile manageriale, de orizontul de timp pentru care este proiectat EIS-ul si nu în ultimul rând de resursele disponibile. Se pot identifica urmatoarele solutii de integrare a EIS cu depozitul de date:
EIS-ul isi extrage partial datele si informatiile din MIS-ul organizatiei si integreaza direct (în afara depozitului de date) restul de date si informatii necesare
EIS-ul isi extrage datele dintr-un depozit de date special structurat ce integreaza toate datele si informantiile necesare (interne sau externe organizatiei)
În proiectarea unui EIS trebuie înteles ca cea mai mare valoare pe care o ofera managementului (comparativ cu MIS si DSS) este flexibilitatea lor. EIS-ul ofera managerilor executivi instrumentele si datele necesare, fara a se referi la anumite probleme sau a impune anumite solutii. Managerii executivi sunt liberi sa modeleze problemele dupa nevoile lor, folosind sistemul ca o extensie a propriului proces de gândire. EIS-urile nu sunt sisteme de adoptare a deciziilor, ci pun la dispozitia managerilor executivi instrumentele necesare pentru adoptarea deciziilor si, mai ales, ofera reguli si modelele necesarea acestuia.
Beneficiile aduse de EIS-uri managementului strategic al unei organizatii sunt:
Abilitatea de a analiza, compara si pune în evidenta tendintele („trend analysis”) de evolutie ale proceselor din organizatie prin marimile care le caracterizeaza. Utilizarea cu usurinta a graficelor permite utilizatorilor sa vizualizeze un volum mare de date, într-un timp scurt, cu o mai mare claritate si întelegere ce imbunatateste viteza de luare a deciziilor managerilor
Descentralizarea sistemul decizional, prin delegarea responsabilitatilor catre nivelurile inferioare ale sistemului de conducere, mentinând controlul informational riguros asupra activitatilor descentralizate printr-o buna monitorizare a lor prin utilizarea unor tabele de bord departamentale („dashboards”)
Cap. ii. Depozitul de Date („DataWarehouse”)
Depozitul de date este nucleul unui mediu structurat si reprezinta baza tuturor proceselor MIS-ului. Conform William (Bill) Inmon, parintele depozitului de date, un depozit de date este o colectie de date orientate pe subiect, completa, integrata, fixa (non-volatile) si care variaza în timp.
2.1. Caracteristicile unui depozit de date
Integrarea datelor este cel mai important aspect al unui depozit de date. Informatiile inserate în depozitul de date provin din surse diferite, fara o legatura anume între ele. Pe masura ce depozitul de date este încarcat, datele noi sunt convertite, reformatate si consolidate. Rezultatul este ca datele odata stocate în depozitul de date asigura o singura imagine a companiei.
Figura 2.1 ilustreaza modul în care se realizeaza integrarea datelor din mediul operational orientat pe aplicatie în depozitul de date.
Figura 2.1 Integrarea datelor în depozitul de date
Datele din mediul operational sunt actualizate în mod frecvent în functie de necesitatile organizatiei. Datele din depozitul de date sunt încarcate (de obicei în masa) si accesate de utilizator fara a fi actualizate prin modificari ale inregistrarilor.
Când apar modificari ulterioare, o noua înregistrare este scrisa in depozitul de date si în felul acesta este pastrata o istorie a datelor care asigura non-volatilitatea datelor din depozitul de date.
In Figura 2.2 se prezinta comparativ modul în care un sistem operational si un depozit de date realizeaza modificarea datelor.
O alta caracteristica de baza a depozitului de date este faptul ca este variabil în timp. Variatia în timp implica faptul ca fiecare unitate de date din depozitul de date este precisa la un anumit moment de timp. Exista cazuri în care înregistrarea este data, iar în alte cazuri, o înregistrare are data tranzactiei. Aceste solutii de marcare a timpului in depozitul de date au rolul de a arata momentul în timp la care înregistrarea este exacta.
Orizontul de timp de stocare a datelor din interiorul unui depozit de date este semnificativ mai lung decât acela al sistemelor operationale. Un orizont de timp pâna la 90 de zile este normal pentru sistemele operationale în timp ce un orizont de timp de 5 -10 ani este normal pentru un depozit de date. Ca rezultat al acestei diferente între orizonturile de timp, un depozit de date contine mult mai multa istorie decât orice alt sistem operational.
Bazele de date operationale contin valori curente a caror exactitate este valabila în momentul accesarii. Datele din depozitul de date sunt diferite de datele valorilor curente. Datele din depozitul de date nu sunt altceva decât serii complete de instantanee, fiecare luat la un anumit moment în timp. Efectul creat de seriile de instantanee este acela ca depozitul de date are o succesiune istorica a datelor si evenimentelor, lucru deloc vizibil într-un mediu al valorilor curente, unde numai cea mai actuala valoare poate fi gasita.
2.2. Arhitectura unui depozit de date
In figura 2.3 este prezentata o arhitectura standard de depozit de date. Astfel, într-un depozit de date pot exista mai multe nivele de detaliere a datelor în functie de necesitatile MIS-ului, dar si de resursele disponibile.
Poate exista un nivel de detaliere foarte ridicat (pentru datele curente sau chiar cele vechi), un nivel de date cu un grad mediu de consolidare (nivelul data mart) si un nivel cu grad ridicat de consolidare a datelor (rapoarte MIS, date pentru DSS si EIS).
Datele din sistemele operationale sunt incarcate în depozitul de date. De obicei apare o transformare a datelor la trecerea de la nivelul operational la nivelul depozitului de date în sensul –ca acestea sunt structurate dar si consolidate (de exemplu: facturi individuale sunt consolidate in vânzari zilnice, saptamânale sau lunare).
Odata cu trecerea timpului, datele isi pierd din relevanta si de aceea sunt transferate / stocate pe medii mai ieftine, dar care trebuie sa permita aceleasi facilitati de raportare ca si datele curente din depozitul de date.
Figura 2.3 Arhitectura unui depozit de date si nivelurile de detaliere a datelor
2.3. Fenomenul zilei N
Depozitele de date nu sunt construite de la început în varianta finala. Ele sunt proiectate si populate putin câte putin si de aceea acest proces este bazat pe evolutie si nu pe revolutie (punctual). Costurile construirii unui depozit de date complet, resursele necesare si descarcarea datelor mai vechi într-un mediu ieftin demonstreaza faptul ca depozitul de date trebuie construit treptat.
Figura 2.4 arata procesul tipic de construire in timp a unui depozit de date conform Bill Inmon:
Ziua 1a exista niste sisteme mostenite care sunt necesare pentru procesarea operationala si încarcarea datelor în depozitul de date
În ziua a 2a primele zone de interes ale depozitului de date sunt populate. Din acest moment utilizatorii încep sa descopere depozitul de date si eficienta procesarii analitice.
În ziua a 3a o parte mai mare a depozitului de date este populata si odata cu popularea cu mai multe date se câstiga mai multi utilizatori. Din momentul în care utilizatorii descopera faptul ca exista o sursa integrata de date care este usor de accesat, si ca exista o baza istorica proiectata pentru cautarea de date în timp, utilizarea depozitului creste.
În ziua a 4a pe masura ce baza devine populata, unele dintre datele care erau extrase din mediul operational sunt plasate acum în depozitul de date. Depozitul de date este acum descoperit ca fiind pricipala sursa a procesarii analitice. Toate aplicatiile DSS apar acum.
În ziua a 5a bazele de date departamentale (Data Marts sau OLAP) încep sa se dezvolte. Departamentele descopera ca este mult mai ieftin si mai usor sa proceseze datele aduncându-le din depozitul de date în propriul mediu de procesare (departament).
În ziua a 6a graba de a obtine sisteme departamentale este pusa în practica. Este mai ieftin, mai usor si mai rapid sa obtii date departamentale decât sa transferi datele din depozit de date. În curând, utilizatorii vor tranforma detalierea depozitului de date într-o procesare departamentala.
În ziua N, aceasta arhitectura este pe deplin dezvoltata. Tot ceea ce a ramas din setul original al sistemelor de productie este procesarea operationala.
Depozitul este plin de date. Mai exista putini utilizatori directi ai depozitului de date. Vor exista o multime de depozite de date departamentale. Majoritatea procesarilor analitice DSS apar la nivel departamental pentru ca este mai simplu si mai ieftin sa obtii datele procesate din acesta.
Sursa: Inmon H.W., Buiding the data Warehouse, 3rd Edition, Editura Wiley, 2002
Figura 2.4 Fenomenul zilei N
2.4. Granularitatea datelor din depozitul de date
Unul dintre cele mai importante aspecte ale proiectarii unui depozit de date este cel al granularitatii. Într-adevar, problema granularitatii strabate întreaga arhitectura care înconjoara mediul depozitului de date. Granularitatea se refera la nivelul detalierii sau sumarizare a unitatilor de date în depozitul de date. Cu cât exista mai multe detalii, cu atât nivelul granularitatii este mai mic. Cu cât detaliile sunt mai putine, cu atât creste nivelul granularitatii.
De exemplu, o tranzactie simpla se va produce la un nivel scazut de granularitate. Un sumar al tuturor tranzactiilor efectuate într-o luna de zile se va afla la un nivel înalt de granularitate.
Granularitatea datelor va fi întotdeauna o problema majora de proiectare. În cadrul sistemelor operationale timpurii, granularitatea era considerata ca atare. Când datele detaliate erau actualizate, era un lucru cert faptul ca datele erau înmagazinate la cel mai scazut nivel de granularitate.
Granularitatea constituie o problema majora de proiectare în cadrul mediului depozitului de date, deoarece ea afecteaza în profunzime volumul datelor care rezida în depozit si tipul de întrebari la care se poate raspunde. Volumul datelor din depozit este compensat cu nivelul de detaliere al unei întrebari.
În aproape toate cazurile, datele ajung în depozitul de date la un nivel mult prea înalt de granularitate. Aceasta înseamna ca utilizatorul trebuie sa cheltuiasca o multime de resurse în scopul separarii datelor. Ocazional, totusi, datele intra în depozit la un nivel scazut de granularitate.
Multe organizatii sunt surprinse sa descopere faptul ca depozitul de date furnizeaza o baza inestimabila pentru numeroase tipuri diferite de procesare DSS. Organizatiile pot construi un depozit de date pentru un anumit scop, dar pot de asemenea descoperi faptul ca depozitul poate fi folosit pentru multe alte moduri de procesare DSS. Desi infrastructura pentru depozitul de date este scumpa si dificil de construit ea trebuie sa fie construita odata pentru intraga companie. Dupa ce depozitul de date a fost construit în mod corect el furnizeaza organizatiei o baza care este extrem de flexibila si care poate fi folosita de câte ori este nevoie.
Datele granulare care se gasesc în depozitul de date constituie cheia pentru folosirea de câte ori este nevoie a depozitului de date deoarece datele granulare pot fi folosite de mai multi oameni în moduri diferite.
Toate aceste tipuri de informatii sunt strâns legate, si cu toate acestea, extrem de diferite. Având un depozit de date, diferitele organizatii sunt capabile sa monitorizeze datele asa cum doresc. Monitorizarea datelor în moduri diferite constituie doar un avantaj al dezvoltarii unui fundament solid. Un beneficiu legat de aceasta este abilitatea de a armoniza datele daca este nevoie. Odata ce exista o singura baza pe care o foloseste toata compania, daca este nevoie sa se explice discrepanta aparuta în analizele efectuate de doua sau mai multe departamente, atunci, reconcilierea este relativ simpla.
Un alt beneficiu al datelor granulare este faptul ca ele contin o istorie a activitatilor si evenimentelor corporatiei respective. Nivelul granularitatii este detaliat suficient pentru ca datele sa fie remodelate în functie de diferitele nevoi ale corporatiei.
Dar probabil, ca cel mai mare beneficiu al bazei depozitului de date este acela ca viitoarele cereri care nu sunt înca cunoscute pot fi mai simplu asimilate.
2.5. Structurarea temporala a datelor în depozitul de date
Cea mai simpla si comuna structura de date care se gaseste în depozitul de date este structura cumulativa simpla. Figura 2.5 arata modul în care tranzactiile zilnice sunt transportate din mediul operational. Dupa aceasta, ele sunt totalizate în arhivele depozitului de date care pot fi facute pe client, pe registre contabile, sau pe orice alta zona de interes din depozitul de date.
Tranzactiile din figura 2.5 sunt totalizate pe zile. Cu alte cuvinte toata activitatea zilnica pentru un client sau pentru un cont este însumata în depozitul de date pe o situatie zilnica.
Figura 4.10 arata si variatia acumularii unei simple zile care se numeste stocarea datelor totalizate rulate.
Datele trec din mediul operational în mediul depozitului de date precum am aratat mai sus. În ceea ce priveste datele totalizate rulate, totusi, datele intra în depozit într-o structura foarte diferita. Pentru primele sapte zile ale saptamânii activitatea este totalizata în sapte partitii zilnice. În cea de a opta zi, cele sapte partitii zilnice sunt adunate si plasate în prima partitie saptamânala. Dupa aceea, totalurile zilnice sunt adaugate în aceasta prima partitie zilnica.
La sfârsitul lunii partitiile saptamânale sunt totalizate si plasate în prima partitie lunara. Apoi, partitiile saptamânale sunt resetate de la zero. La sfârsitul anului, partitiile lunare sunt totalizate si este încarcata prima partitie anuala, apoi partitiile lunare sunt resetate la fel.
O structura de date rezumative rulate are de a face cu mult mai putine unitati de date decât în cazul unei structuri cumulative simple a datelor. O comparatie a avantajelor si dezavantajelor celor doua structuri prezentate mai sus este aratata în figura 2.6.
Figura 2.5. Date cumulative simple
Sursa: Inmon H.W., Buiding the data Warehouse, 3rd Edition, Editura Wiley, 2002
Figura 2.6. O variatie a datelor cumulative o constituie rularea fisierului rezumativ.
O alta posibilitate pentru structurarea depozitului de date este modelul direct simplu precum, cel aratat în figura 2.7. Datele sunt preluate din mediul operational si transmise în mediul depozitului de date, nu exista o acumulare. În plus, modelul direct simplu nu este întocmit pe o baza zilnica. În loc de aceasta, el este întocmit pe o perioada mai lunga de timp, precum o saptamâna sau o luna. De aceea, modelul direct simplu reprezinta un instantaneu al datelor operationale.
Figura 2.7 Analiza comparativa a celor doua tipuri de sumarizare a datelor
2.6. Sistemul pentru Planificarea Resurselor Întreprinderilor (“Enterprise Resource Planner”) si Depozitul de Date
Unul dintre cele mai importante avansuri în tehnologia ultimilor zece ani a fost sistemul de planificare a resurselor întreprinderii („Enterprise Resource Planner”) sau ERP. Procesarile tranzactiilor si aplicatiilor construite pentru o companie. Aplicatiile si tranzactiile – construite si mentinute centralizate de vânzator – acopera urmatoarele functii cumulate:Resurse umane; Departamentul administrativ de inventariere; Departamentul administrativ financiar, Departamentul de furnizare logistica aplicatie distributie, serviciul clienti ERP-urile sunt produse de companii precum SAP AG, People Soft , JD Edwards, BAAN, Oracle, Sun Systems etc.
Din punct de vedere al depozitului de date si integrarea acestuia cu ERP-urile, pot exista urmatoarele solutii constructive:
Aplicatii ERP în afara depozitului de date
Mediul ERP contine procesarea aplicatiei unde apar tranzactiile si alimenteaza apoi depozitul de date precum orice alta aplicatie. Depozitul de date poate fi creat pe baza un SGBD: MS SQL SERVER, ORACLE, DB2, CACHE etc. O data ce datele parasesc mediul ERP acesta devine pur si simplu, alta sursa de date.
Exista câteva avantaje în extragerea datelor din mediul ERP si introducerea lor în depozitul de date construit ca un mediu diferit. Unul din cele mai importante avantaje ar fi acela ca depozitul de date este liber de orice constrângeri care ar putea fi plasate în el de catre ERP iar al doilea este din punct de vedere al vitezei de procesare cele doua sisteme pot fi total independente la nivel hardware sau software.Construirea depozitului de date în mediul ERP.
O astfel de propunere ar putea fi SAP BW, sau PEOPLE SOFT EPM. În acest caz vânzatorul ERP furnizeaza atât aplicatia cât si depozitul de date.
Exista doua avantaje distincte ale acestei abordari. Primul este acela ca vânzatorul ERP furnizeaza infrastructura. Acest lucru scuteste proiectantul de o cantitate enorma de munca si persoana care se ocupa de dezvoltare de la complexitatea proiectarii si dezvoltarii. Pe scurt, includerea depozitului de date în aplicatiile ERP simplifica enorm viata unui proiectant al depozitului de date.
Alimentarea depozitului de date se poate realiza prin sistemele ERP si Non- ERP. Odata ce datele Non-ERP sunt plasate sub controlul depozitului de date, datele pot obtine avantaje din toata infrastructura construita de vânzatorul ERP. Aceasta abordare este cea mai avantajoasa când mediul ERP este construit înainte ca orice depozit de date sa fie construit la rândul lui.
Punerea tuturor datelor în depozitul de date controlat de ERP nu înseamna ca toate procesarile DSS facute din depozitul de date trebuie facute în cadrul granitelor depozitului de date ERP. Vînzatorii ERP se straduiesc sa puna o cantitate mare a procesarii analitice în mediul ERP iar acesta este unul dintre punctele atractive ale depozitului de date ERP.
Figura 2.8 arata ca procesarea DSS care se bazeaza pe depozitul de date poate fi facuta atât în cadrul cât si în afara mediului ERP (adica si în medii ERP si în medii Non-ERP).
Figura 2.8 Data Marts, aplicatiile DSS si exploatarea depozitului pot fi facute înauntrul sau în fara mediului ERP (sau amândoua) când depozitul de date este construit în mediul ERP.
Mai exista totusi o alta posibilitate foarte comuna pentru depozitarea datelor în mediul ERP –o circumstanta unde exista depozite de date atât ERP cât si Non- ERP (vezi figura 2.9).
Sursa: Inmon H.W., Buiding the data Warehouse, 3rd Edition, Editura Wiley, 2002
Figura 2.9 Depozitele de date in medii mixte ERP – Non-ERP
Aceasta posibilitate apare atunci când exista o integrare mica sau deloc a afacerii între cele doua medii sau în cazul în care cerintele software si hardware nu justifica din punct de vedere al costurilor integrarea celor doua. Daca cele doua medii trebuie sa împarta datele precum informatii financiare, atunci ele pot fi transferate dintr-un depozit în altul.
2.7. Instrumente de acces si analiza multidimensionala a depozitelor de date
Depozitele de date au ca principal rol acumularea datelor si exploatarea lor.
Exploatarea depozitelor de date poate realiza prin:
extragerea unor rapoarte (la cerere sau pe baza unui planificari cu o anumita periodicitate);
extragerea unor date pentru a fi utilizate de aplicatiile de birotica (programe de calcul tabelar, procesoare de text, programe de prezentare etc.);
utilizarea unor instrumente de acces de catre aplicatii specializate de analiza, cum ar fi: o instrumente de procesare analitica on-line (“On-line Analytical Processing”) sau OLAP o instrumente de „minerit” în date (“Data mining”), aplicatii axate pe descoperirea unor modele, tendinte si corelatii semnificative prin exploatarea depozitului de date.
În vreme ce datele operationale din sistemele informatice se refera la activitatile zilnice, depozitul de date este istoric prin natura si este folosit pentru a obtine o perspectiva asupra tendintelor, corelatiilor si a factorilor de influenta. Multe intreprinderi colecteaza în acest moment si rafineaza masive cantitati de date în depozitele de date prin intermediul sistemelor informatice.
Figura 2.10 Modalitati de exploatare a depozitelor de date
Aceste firme au realizat ca pentru a reusi într-o lume ce se schimba în ritm rapid, utilizatorii au nevoie de informatie în momentul cererii ei. Si ei au nevoie si de informatii noi care nu sunt cunoscute în avans.
Firmele privesc astazi informatia ca pe una dintre cele mai valoroase resurse, iar instrumentele de analiza multidimensionala permit unei firme sa foloseasca la maxim aceasta resursa.
Asistarea deciziilor („Decision Support”) este un termen general care se refera la folosirea informatiei ca la o resursa corporativa strategica, ce abiliteaza firmele în utilizarea bazelor lor de date pentru a lua decizii mai bune.
Instrumentele de acces la depozitele de date si de analiza multidimensionala se bazeaza, în mod traditional, pe trei tipuri de unelte:
Interogari si rapoarte: caz în care un utilizator pune o întrebare
OLAP care extinde procesarea de interogari de-a lungul a mai multor dimensiuni, cum ar fi o arie geografica, o perioada calendaristica etc
Data Mining: extrage „automat” modelele de informatii si relatii pentru raspunsuri la întrebari complexe
În figura 2.11 se poate observa progresul facut în domeniu în ultimii 30 de ani pentru a oferi informatie rafinata mai multa si mai bine. În cazul statisticilor si rapoartelor erau disponibile utilizatorilor rapoarte ale datelor. În plus si aceste date sumare erau obtinute prin intermediul unui analist. Odata cu aparitia depozitelor de date, anumite interogari si rapoarte pot fi obtinute chiar de utilizatorul direct prin consultarea bazelor de date.
Sursa: Orzan Gh., Sisteme informatice de marketing, Editura Uranus, Bucuresti, 2001
Figura 2.11 Evolutia MIS-ului de la rapoarte la cunostinte
Începând cu OLAP, întrebarile multi-dimensionale pot fi adresate chiar de utilizatorii directi cu o cerere de genul “doresc total cantitate pe fiecare produs, pe fiecare canal de distributie, pe fiecare luna calendaristica”.
Utilizatorii pot descoperi cu ajutorul Data Mining corelatii semnificative, modele de informatii, factorii de influenta si tendintele ce rezulta din date. Notiunea de „acces la cunostinte,” semnifica faptul ca modelele relevante din date sunt gasite dinainte si stocate pentru necesitatile utilizatorilor. Acestia pot folosi modelele de interes furnizate periodic sau pot interoga ei însisi modelele de baza.
Deoarece marile baze de date adeseori ofera multe date utile, abordarile bazate pe Interogari si OLAP se confrunta, de obicei, cu greutati în a identifica generalizari utile din cauza prea multor date. Forta tehnicii Data Mining consta în abilitatea de a efectua din proprie initiativa cercetari printre date, descoperind în mod autonom modele cheie.
Cu toate ca cele trei abordari de mai sus sunt utile, ele împart o trasatura comuna care se refera la faptul ca utilizatorul trebuie sa realizeze mai multe analize pentru a dobândi cunostintele, procedeu cunoscut ca Modelul de Analiza a Datelor.
O noua abordare care pune la dispozitia utilizatorilor informatie rafinata este Modelul de Acces la Cunostinte. Prin modelul de acces la cunostinte analiza datelor este efectuata în prealabil, iar utilizatorul doar urmareste cunostintele „preminerite” la cerere.
Pentru a utiliza informatia dintr-o baza de date este evident necesar sa se realizeze analize la un moment dat. Altfel spus, analiza se efectueaza la momentul în care utilizatorul are nevoie de cunostinte sau este realizata anterior, astfel încât sunt gata de a fi accesate. În mod traditional, analizele de tip data mining erau efectuate dupa lansarea cererii de catre utilizator. Modelul accesului la cunostinte elimina riscul unor analize întârziate prin aceasta operatie de preminerire a informatiei.
Asadar exista doua modele distincte capabile sa ofere utilizatorilor cunostinte:
Modelul de Analiza a Datelor: în acest caz utilizatorii opereaza asupra datelor pentru a descoperi informatia. Acest model se bazeaza pe o abordare de tipul „analiza la cerere”.
Modelul de Acces la Cunostinte: în acest caz analizele sunt efectuate în mod automat în prealabil, modelele rafinate sunt pregenerate, iar utilizatorii obtin cunostintele în momentul în care au nevoie de ele, abordarea este de tipul „cunostinte la cerere”.
2.7.1 Procesare analitica on-line (OLAP)
Analiza analitica multidimensionala, referita de regula ca OLAP („On-line Analytical Processing”) este o activitate ce da raspunsuri corecte la întrebarile analistilor. Singura trasatura comuna a acestor întrebari este caracterul lor multidimensional. Exista totusi câteva tipuri uzuale de întrebari, care pot arunca o lumina asupra compexitatii instrumentelor care trebuie sa furnizeze raspunsuri:
Rapoarte multidimensionale
Comparatii
Clasificari si profile statistice.
Agregari libere.
Evaluari de genul ce-ar fi daca (“what-if”)
Printre calitatile pe care trebuie sa le îndeplineasca un instrument OLAP se numara:
sa poata sustine analize sophisticate (precum cele de sus)
sa poata fi utilizate eficient de diverse categorii de utilizatori
sa fie scalabile la volume oricât de mari de date
sa permita accesul concurent al unui mare numar de utilizatori
sa fie usor de întretinut si de configurat
sa fie bazate pe o arhitectura deschisa
Operatiile OLAP cuprind:
Specificarea criteriilor de selectie este primul pas în orice analiza. Utilizatorul trebuie sa poata exprima cu usurinta criterii simple, bazate pe valori ale atributelor si/sau pe valori ale metricelor. Aceste criterii simple trebuie sa poata fi apoi combinate prin operatori logici si trebuie sa poata fi salvate în biblioteci pentru eventuale reutilizari.
Rotatiile sunt operatii care permit utilizatorilor sa gaseasca perspectiva care-i intereseaza specificând dimensiunile si directiile de rotatie sau indicând un pivot.
Schimbarea nivelului de agregare permite gasirea nivelului de agregare optim pentru analiza. Se poate adânci analiza spre nivelurile de detaliu (“drill-down”) pentru anumite dimensiuni în timp ce pentru alte dimensiuni se creste nivelul de agregare (“drill-up”).
Specificarea modului de prezentare trebuie sa permita analistului sa gaseasca modalitatile optime de valorificare vizuala a datelor extrase. În afara de posibilitatile grafice tipice pentru prezentare, este important ca utilizatorul sa poata vizualiza date multidimensionale într-o maniera tabelara. În acest sens se pot utiliza tabele complexe, care sa poata grupa coloane si linii exprimând dimensiuni diferite (de pilda timpul si dispunerea în spatiu) si nivele de agregare diferite.
Cerintele de administrare si dezvoltare pentru OLAP, desi similare cu cele pentru instrumentele de interogare si raportare, sunt în general mult mai complexe.
Punerea în functiune a unui sistem OLAP si a aplicatiei software de acces la date necesita o întelegere clara a modelului de date al companiei si a functiilor analitice cerute de conducerea executiva si strategica.
Produsele comerciale pot fi de mare folos, dar rareori exista solutii “la cheie” pentru OLAP. Arhitectura trebuie proiectata astfel încât sa suporte sursele de date folosite si sa faca fata cerintelor. În schimb, o data ce sistemul OLAP este functional, suportul tehnic pentru utilizator este minimal.
2.7.2 Data mining
Data mining (mineritul în date) reprezinta, într-o acceptiune simpla, un mod automat de detectare într-o baza de date a unor tipare relevante. Data mining utilizeaza o serie de tehnici statistice si de inteligenta artificiala ce dau posibilitatea construirii de modele ce pot previziona comportamentul clientilor. Tehnologia îsi sporeste calitatile prin integrarea cu depozitele de date si cu noile modalitati de prezentare si raportare.
Data mining îsi datoreaza numele similaritatii dintre cautarea de informatii valoroase într-o baza de date mare si saparea unor galerii în munte pentru detectarea unor zacaminte valoroase.
Data mining este un proces de descoperire a cunostintelor (“Knowledge discovery”) sal KD, de extragere a informatiei necunoscuta anterior din baze de date foarte mari.
Procesul descoperirii de corelatii semnificative, modele si tendinte se asigura prin explorarea unor mari cantitati de date stocate în depozite de date, utilizând tehnologii de recunoastere a modelelor, precum si tehnici statistice si matematice.
Traditional, sunt avute în vedere doua tipuri de analize statistice:
Analize confirmatorii. În cazul analizelor confirmatorii, având o ipoteza formulata aceasta se accepta sau se respinge de catre analist.
Analize exploratorii. În analizele exploratorii, se urmareste gasirea de ipoteze, care apoi se accepta sau se resping de catre analist. În acest punct sistemul preia “initiativa” în procesul analizei datelor. Sistemul gândeste singur ipotezele, acestea nemaifiind formulate de utilizator. În prezent termenul de data mining se refera la procesul automat de analiza a datelor în care sistemul preia initiativa de a genera modele.
Din punct de vedere al procesului de descoperire a cunostintelor exista trei clase de activitati data mining: descoperire, modelare predictiva si analiza exceptiilor (figura 2.12).
Sursa: Orzan Gh., Sisteme informatice de marketing, Editura Uranus, Bucuresti, 2001
Figura 2.12 Clase de activitati Data mining
Descoperirea este procesul de cautare în baza de date pentru a gasi modele, fara a avea o idee predeterminata sau ipoteza asupra a ceea ce pot fi modele. Cu alte cuvinte programul preia initiativa în gasirea unor modelele interesante, fara a fi necesar ca utilizatorul sa se gândeasca la întrebarile relevante în prealabil. În marile baze de date exista atât de multe modele încât utilizatorul nu ar putea niciodata practic sa se gândeasca la toate întrebarile care ar trebui puse.
Marele avantaj consta în bogatia de modele care pot fi gasite si exprimate, precum și în calitatea informatiei livrate – elemente care determina puterea si utilitatea tehnicii de descoperire.
Modelarea predictiva presupune ca modelele descoperite din baza de date sa fie folosite pentru a face previziuni. Modelarea predictiva permite astfel utilizatorului sa prelucreze înregistrari ce au câmpuri valorice necunoscute, iar sistemul sa intuiasca valorile necunoscute pe baza unor modele anterioare din baza de date.
Analiza exceptiilor reprezinta procesul prin care se aplica modelele extrase pentru a gasi anomalii sau elemente de date neobisnuite. Pentru a descoperi anomaliile, mai întâi aflam ceea ce este normal, apoi detectam câteva articole care deviaza de la norma în cadrul unui interval dat. Se observa ca descoperirea ne poate ajuta sa gasim “cunostinte uzuale,” vreme în care analiza exceptiilor cauta cazurile neobisnuite si specifice.
Fiecare dintre aceste procese pot fi clasificate la rândul lor dupa regulile de conditionare logica (“If/Then”), Asocieri etc. Regula de conditionare “IF/THEN” presupune ca daca conditia este indeplinita, atunci se aplica regula 1, altfel regula 2 etc.
De exemplu: Un consumator cumpara un produs din magazinul X si în acelasi timp, cumpara si produsul Y. Se defineste “cosul de cumparaturi X+Y” si se constata ca este un “cos de cumparaturi valid”, de fapt regula gasita este valida pentru ca este regasit la foarte multi cumparatori. Urmatorul pas este sa se identifice alti consumatori potentiali care cumpara produsul X dar nu cumpara produsul Y (sau invers) si ei devin segmentul tinta pentru imbunatatirea vânzarilor produselor X si Y.
Din punct de vedere al tehnicilor utilizate de data mining au fost dezvolate urmatoarele:
Data Mining cu pastrarea datelor, caz în care datele pre-minerite sunt pastrate pentru reutilizare. in cadrul careia regasim
o Metoda celui mai apropiat vecin sau “vecinul imediat”. În acest caz setul de date este pastrat pentru comparatii cu noi înregistrari. Când o noua înregistrare este supusa analizei, este masurata “distanta” dintre acestea si înregistrarile similare din setul de date si sunt identificati vecinii cei mai apropiati
o Argumentare pe cazuri
Data Mining cu rafinarea datelor. În acest caz, se analizeaza datele, se extrag modelele, dupa care se sterg datele retinute, urmând ca modelele sa fie folosite. Aceasta abordare a dat nastere la trei optiuni:
o Sisteme Logice Conditionate (cu reguli sau cu arbori de decizie)
o Tabelare incrucisata
o Abordarile ecuationale
În mod frecvent, instrumentele de data mining sunt dezvoltate de companiile specializate in “Business Intelligence” si pun la dispozitia utilizatorilor una sau mai multe tehnici de data mining. Acestea pot fi integrate in functionalitatea de baza a depozitului de date sau pot fi parte a unor pachete software independente, decizia de utilizare si integrare apartinând utilizatorului.
cap. iii. Sistemul informatic al unei bănci
Un sistem informațional al unei bănci este cu atât mai eficient cu cât culegerea, prelucrarea și transmiterea informației are la bază mijloace moderne de calcul sau dacă este susținut de un system informatic adecvat.
Un sistem informatic bancar poate realiza o multitudine de funcțiuni:
• procesarea tranzacțiilor;
• întocmirea și ținerea evidenței contabile și a altor evidențe operative privind operațiunile curente ale clienților, creditele, depozitele, operațiunile documentare, operațiunile speculative;
• întocmirea rapoartelor pentru conducerea operativă a băncii (MIS);
• întocmirea rapoartelor solicitate de Banca Centrală și alte organe ale administrației centrale sau locale;
• furnizarea de informații necesare deciziilor strategice.
Toate acestea conduc în final la:
• raționalizarea muncii de rutină;
• rapiditate și calitate în deservirea clientului;
• reducerea posibilității de eroare de prelucrare;
• operativitate în luarea deciziilor de zi cu zi;
• fundamentarea corectă a deciziilor strategice.
Analiza economico-financiară într-o bancă nu poate fi făcută corespunzător fără un sistem informatic puternic, performant, care să poată furniza informații în timp real și de calitate și utilitate deosebite.
Se consideră că un sistem informatic eficient trebuie să prezinte următoarele caracteristici:
♦ integrat, acoperind toată gama de operațiuni bancare;
♦ multibranch, tranzacțiile pot fi executate din orice sucursală, indiferent de locul unde clientul își are deschis contul;
♦ multicurrency, tranzacțiile pot fi efectuate în orice valută, indiferent de valuta în care sunt exprimate conturile clientului;
♦ tranzacțional, în baza informațiilor privind tranzacția respectivă, sistemul generează automat toate operațiunile contabile precum și mesajele SWIFT aferente sau, după caz, în baza mesajelor SWIFT generează tranzacția și respectiv înregistrările contabile;
♦ în timp real, orice tranzacție care a fost introdusă în sistem și a fost autorizată corespunzător este reflectată imediat în toate evidențele băncii.
Deși, la o primă vedere un sistem informatic bancar pare simplu de realizat, realitatea este cu totul alta.
Pentru o bancă comercială problema sistemului informatic nu este temporară, numai la înființare sau când decide să treacă la automatizarea lucrărilor. Practic, această problemă persistă de-a lungul întregii vieți a unei bănci deoarece calitatea serviciilor oferite, precum și deciziile operative și strategice depind de calitatea sistemului informatic.
O definire globală a unui sistem informatic cuprinde resursele software, hardware, de telecomunicații și umane pentru automatizarea lucrărilor băncii. Cum evoluția sistemelor hardware și de telecomunicații este în continuă dezvoltare și perfecționare, rezultă firesc că resursele software trebuie adaptate continuu pentru utilizarea eficientă a potențialului tehnic.
Întrucât problema dezvoltării și perfecționării continue preocupă, în general, băncile care au deja o experiență în gestionarea sistemelor informatice, se vor prezenta pașii pe care o bancă comercială trebuie să-I parcurgă pentru a începe să utilizeze tehnica de calcul.
A. Selectarea soluției software, a modului în care va fi realizat un sistem informatic, determinarea performanțelor acestuia, perioada de realizare-implementare reprezintă decizii strategice ale unei bănci și trebuie să aibă în vedere următoarele:
1. mărimea capitalului social, structura și evoluția probabilă a acestuia;
2. obiectul de activitate al băncii (tipurile de servicii ce urmează a fi oferite clienților, dacă se efectuează operațiuni și la intern și la extern și care este ponderea fiecărei categorii în volumul de activitate);
3. rețeaua existentă și perspectivele de dezvoltare pe următorii 3-5 ani, inclusiv evoluția numărului de personal operativ și de conducere.
În funcție de situația fondurilor alocate pentru realizarea și implementarea sistemului informatic, corelat cu termenul dorit pentru punerea în funcțiune (CUT OVER DATE), apar următoarele situații:
a) fonduri reduse – termen foarte scurt (imediat, 2-3 luni);
b) fonduri reduse – termen scurt (6 luni);
c) fonduri reduse – termen mediu (6 luni – 1 an);
d) fonduri reduse – termen lung (1 – 2 ani);
e) fonduri suficiente – termen foarte scurt;
f) fonduri suficiente – termen scurt;
g) fonduri suficiente – termen mediu;
h) fonduri suficiente – termen lung.
În cazul variantelor a) – d) când fondurile posibile de alocat rămân la un nivel constant, relativ redus, experiența arată că niciodată nu se poate ajunge la un sistem informatic performant și competitiv, dar că pot fi automatizate unele tronsoane ale activitații bancare, în special în ceea ce privește munca de rutină. Acest lucru se poate obține în special prin utilizarea forței de muncă de proiectare, programare, implementare, organizată în cadrul unui compartiment distinct din bancă.
Acest compartiment, coordonat de o persoană competentă – cunoscătoare a cerințelor unui sistem informatic bancar – poate, în colaborare cu compartimentele din bancă, să realizeze un sistem informatic modular suficient de deschis, astfel încât să poată fi interfațat cu eventualele module ieftine pe care banca să le achiziționeze de la alte bănci sau firme de software bancar specializate.
În ceea ce privește șansa de reușită a unui astfel de sistem, aceasta este cu atât mai mare cu cât forța de analiză, programare, implementare este mai mare și timpul este mai larg. În cele ce urmează se va face o analiză care va conduce la fundamentarea acestei afirmații.
Cazul a). “fonduri reduse – termen foarte scurt” apare, de obicei, la băncile în formare la care dorința de a începe operațiunile cât mai repede este foarte mare. Pericolul de nereușită este foarte mare și poate compromite activitatea băncii deoarece:
• calitatea serviciilor oferite clienților este redusă și, chiar dacă pe parcurs aceasta se îmbunătățește, cu greu pot fi atrași din nou clienții care și-au format deja o părere nefavorabilă;
• cantitatea și calitatea informațiilor obținute cu ajutorul calculatorului este redusă și creează probleme atât la nivelul conducerii (nesiguranța privind viabilitatea și consistența acestora), dar și la nivel operativ întrucât se creează un curent nefavorabil pentru automatizare pe motiv că “mai mult încurcă”;
• se poate ajunge la situația, deloc dorită, ca autoritatea bancară (Banca Centrală) și autoritățile financiare sau fiscale să aplice sancțiuni drastice băncii pentru că nu respectă termenele și acuratețea raportărilor. Aceste sancțiuni pot fi de natură materială (amenzi) sau chiar administrative, banca putând pierde dreptul de a efectua anumite tipuri de operațiuni sau conducând până la retragerea licenței.
Soluțiile recomandate pentru încadrarea în restricțiile de timp și fonduri sunt:
• amânarea începerii operațiunilor sau limitarea lor pe cât posibil la începerea activității;
• adaptarea (cumpărarea) unor nuclee informatice strict necesare, produse și utilizate în alte bănci românești sau străine similare ca dimensiune și domeniu de activitate. Aceste nuclee trebuie să cuprindă în mod obligatoriu soluția contabilă cea mai apropiată de cerințele de evidență internă (balanțe de verificare și extrase zilnice, calculul dobânzii) și de raportare la Banca Centrală.
Cazul b). “fonduri reduse – termen scurt” este specific atât băncilor în formare cât și băncilor deja în funcțiune, care nu au dat suficientă importanță sistemului informatic, iar activitatea zilnică le obligă practic să acționeze în ultimă instanță.
Pentru băncile noi această situație este mai puțin periculoasă, dar cere o concentrare deosebită a eforturilor echipei de realizare și, în special, stabilirea cu precizie a priorităților în realizarea programului informatic.
De o mare importanță este colaborarea celorlalte compartimente cu echipa de proiectanți–programatori pentru definirea și stabilirea priorităților, care nu se vor schimba în cele 6 luni. Este de preferat ca nucleul contabil să fie realizat de programatorii proprii, iar unele module (casa de schimb, compensare, salarii, operațiuni de casă), în măsura în care nu sunt suficiente forțe interne, să fie achiziționate de la alte bănci românești. Avantajul este că în jurul nucleului construit se pot dezvolta treptat module care să acopere cât mai multe tipuri de operațiuni.
Totodată, informațiile necesare raportărilor la Banca Națională a României și care, pot fi extrase dintr-o evidență contabilă structurată pe un plan de conturi adecvat, există încă de la început în baza de date și treptat întocmirea rapoartelor poate fi automatizată tot mai mult.
Cazul c). “fonduri reduse – termen mediu” este practic situația cea mai de dorit pentru băncile care își propun să se automatizeze, fie ele noi sau vechi, dar care nu pot cheltui bani prea mulți.
În acest caz, realizarea sistemului informatic sub toate aspectele (hardware, telecomunicații și software) se poate face în condiții bune și, mai ales, se poate asigura flexibilitatea necesară pentru dezvoltarea sa, inclusiv în cazul în care fondurile devin eventual insuficiente.
Practic echipa de proiectanți–programatori va urmari aceleași obiective ca in cazul b), dar timpul le va permite să se concentreze mai mult asupra definirii clare a cerințelor sistemului, a realizarii diverselor module.
Totodată, se va putea aloca un timp relativ optim de circa două luni în care să se realizeze testarea și implementarea sistemului, paralel cu instruirea personalului.
Cazul d). “fonduri reduse – termen lung” este situația care apare când băncile nu dau suficientă atenție sistemului informatic și ca atare, pe lângă faptul că nu au fonduri, nici nu concentrează suficientă forță de muncă calificată în informatica bancară, astfel că întreaga activitate de informatică este lăsată fără o coordonare fermă și, în final, după circa 2 ani se constată că de fapt nu s-a progresat aproape deloc.
În cazul variantelor e) – h) când banca dispune de fondurile necesare pentru un sistem informatic performant și competitiv, realizarea acestuia este posibilă, dar nu este o regulă că succesul este de la sine înțeles. Riscul ca fondurile să fie cheltuite nerațional și fără a atinge obiectivele propuse este mare.
În general, când o bancă dispune de fonduri suficiente alocate sistemului informatic sunt posibile două variante:
i) să devină un producător de software bancar;
j) să cumpere soluții la cheie de la alți producători de software.
Varianta i) este specifică băncilor mari, cu tradiție, care și-au transformat propriile departamente de informatică în adevărate case de software sau și-au înființat propriile societăți de software și, în consecință, își valorifică propriile produse. Varianta j) este din ce în ce mai des întâlnită la băncile în înființare și la băncile care au ajuns la concluzia că performanța bancară este direct proporțională cu performanța sistemului informatic.
Cazul e). “fonduri suficiente – termen foarte scurt”. Poate fi un fiasco total dacă se forțează nota. Achiziționarea unui sistem bancar la cheie pentru o bancă nu poate fi făcută în termen de 1-3 luni cu toate asigurările pe care, de cele mai multe ori, le dau casele de software bancar care vor cu orice preț să vândă.
Practic, selectarea soluțiilor hardware și software la cheie pentru o bancă durează cel puțin 1-2 luni și trebuie să se facă fundamentat și corelat cu ceea ce se dorește de la acest sistem.
După achiziționarea sistemului și semnarea contractului sunt obligatorii câteva faze deosebit de importante peste care atât vânzătorii cât și viitorii utilizatori, grăbiți, sunt tentați să treacă cu mare ușurință:
• selectarea și achiziționarea platformei tehnice adecvate;
• customizarea sistemului (parametrizarea sau modificarea
programelor în concordanță cu specificul băncii și al mediului
românesc);
• testarea și implementarea sistemului;
• instruirea personalului bancar și tehnic.
Cazurile f) și g) “fonduri suficiente și termene de peste 6 luni și până la un an” par a fi cazurile optime pentru selectarea și darea în funcțiune a unui sistem informatic. Acordarea atenției necesare fazelor descrise mai sus asigură succesul deplin.
În aceste situații se găsesc, de obicei, băncile noi care au acordat atenția necesară sistemului informatic încă din momentul luării inițiativei creării băncii și realizarea sistemului se face în paralel cu organizarea activității – obținere de aprobări, spații, amenajări, angajare personal.
Cazul h). “fonduri suficiente – termen lung” este specific băncilor care funcționează de o perioadă de timp și care utilizează un sistem informatic cu performanțe nesatisfăcătoare.
În aceste cazuri, implementarea sistemelor noi, la cheie, se face anevoios deoarece migrarea de la un sistem la altul este dificilă îndeosebi datorită necesității schimbării din mers a metodologiilor de lucru, dar și operațiunilor de convertire a bazelor de date deja existente pe suport de hârtie sau magnetic, în baze de date cu altă structură, conținut și organizare.
B. Selectarea soluției hardware – telecomunicații trebuie să țină cont de:
• compatibilitatea cu soluția software aleasă;
• mărimea rețelei de unități ale băncii și perspectiva de dezvoltare;
• compatibilitățile cu rețelele de telecomunicații;
• existența suportului de service local pentru perioada de garanție și post garanție;
• posibilitatea măririi (“upgradării”) capacității de calcul și de memorie internă și externă;
• compatibilitatea cu eventuale echipamente de calcul deja existente în bancă.
3.1. Calitatea sistemului informațional
Analiza activității economice este definită în literatura de specialitate ca fiind o metodă de cercetare bazată pe descompunerea sau defalcarea unui fenomen economic în părțile sale componente, în elementele sale simple.
Pentru cunoașterea și implicit, asigurarea condițiilor de acționare a decidenților este necesar un sistem de informații care să reflecte complex stările de funcționare a sistemului.
Prin urmare, la baza analizei economice stă informația iar rezultatul analizei se materializează în decizii. Schematic aceasta se poate figura astfel:
Rezultă deci că atât calitatea analizei cât și cea a deciziei sunt dependente de calitatea informației. Pornind de la clasificări ale informației economice în general, se va încerca clasificarea informației bancare și definirea cerințelor privind calitatea informației și a sistemului informațional bancar.
• Din punct de vedere al sursei, distingem:
informația internă, generată în cadrul băncii și care se referă la:
– Buget (Bilanț, Contul de profit și pierdere proiectate);
– Bilanț contabil cu anexele întocmite conform reglementărilor legale naționale și internaționale în materie de contabilitate;
– Rapoarte statistice privind evoluția principalilor indicatori bancari;
– Rapoarte operative privind activitatea curentă a băncii (Balanța de verificare, Situația activelor și pasivelor, Expunerea băncii, Situația fondurilor proprii);
– Politici, manuale, proceduri;
– Tarife de comisioane și niveluri de dobânzi active și pasive.
informația externă, care se referă în principal la:
– evoluția cursurilor de schimb și a ratelor dobânzilor pe piețe;
– evoluția principalilor indicatori macro-economici (inflație, șomaj, produs intern brut, datorie externă, balanță de plăți, fiscalitate);
– activitatea concurenței locale;
– evoluția segmentelor de piață pe care banca le finanțează și de la care atrage fonduri;
– evoluția activității bancare și financiare la nivel național și internațional, în special a băncilor cu relații de corespondent;
– evenimente politice majore;
– reglementări legale în domeniul economic și bancar.
• Din punct de vedere funcțional, informația se poate grupa în:
informație țintă, care se referă la obiectivele financiare și de dezvoltare ale băncii, noile produse și servicii ce vor fi implementate;
informație efectivă, care cuprinde toate informațiile interne și externe care se referă la starea de fapt a băncii;
informație normativă, care cuprinde toate reglementările interne, la nivel național și internațional care vizează activitatea bancară;
informație estimativă, dată de Buget, evoluția previzionată a principalilor indicatori macroeconomici precum și a elementelor specifice activității bancare (cursuri de schimb, ratele dobânzilor).
Pentru a satisface cerințele analizei economico-financiare și, în consecință, pentru asigurarea unei calități corespunzătoare a procesului decizional, informația bancară trebuie să întrunească anumite calități:
♦ să fie utilă procesului de analiză și decizie;
♦ să fie exactă, în sensul că trebuie să fie rezultatul unor procese de prelucrare logice și corecte sau să provină direct din evidențele băncii care, la rândul lor, trebuie să aibă un grad de exactitate ridicat;
♦ să fie comparabilă cu informații de același tip, în sensul că a fost obținută în baza unor algoritmi de calcul unitari, atât în ceea ce privește prelucrarea informațiilor interne, cât și a celor provenite din afara băncii.
◊ Nu poate fi făcută o analiză corectă a evoluției în timp a rezultatelor financiare ale unei bănci, dacă în perioada analizată au intervenit modificări esențiale de ordin metodologic sau ale indicatorilor macroeconomici. În aceste cazuri, se aplică algoritmi de aducere la zi a cifrelor aferente perioadelor trecute.
◊ Nu pot fi comparate rezultate financiare întocmite conform standardelor de contabilitate românești (RAS) cu cele întocmite conform standardelor internaționale de contabilitate (IAS).
♦ să fie prezentată în timp util, condiție esențială pentru informațiile care stau la baza unor decizii operative.
Pentru satisfacerea acestei condiții, băncile sunt preocupate de implementarea unor sisteme informatice și de telecomunicații moderne care să permită conectarea ON LINE a tuturor unităților operative și care să asigure totodată condițiile procesării ÎN TIMP REAL a tuturor tranzacțiilor.
♦ să aibă un cost acceptabil. În studiile de fezabilitate privind implementarea unor sisteme informatice și de telecomunicații moderne, băncile trebuie să țină seama nu numai de obiectivele stabilite, ci și de costurile care nu sunt deloc neglijabile. Este necesar să fie găsit pragul de rentabilitate a investițiilor aferente sistemului informațional în condițiile unor fonduri de investiții limitate de mărimea capitalului social și de obiectivele financiare ale băncii.
3.2. Managementul securității informației
Activitatea băncilor depinde tot mai mult de sistemele informatice. A devenit imposibilă separarea tehnologiei informației de domeniul financiar al economiei. Necesitatea utilizării computerului atât ca instrument personal, dar mai ales ca entitate interconectată în rețele cu arhitecturi complexe este în creștere exponențială.
Interpretarea acestui aspect, în conjuncție cu recunoașterea valorii informației vehiculate, a dus la formularea unor standarde pentru dezvoltarea și implementarea de bune practici de securizare a informației.
Aceste standarde au fost dezvoltate în Marea Britanie inițial, pentru ca din decembrie 2000 să devină, datorită valabilității lor, standarde internaționale (ISO/IEC DIS 17799).
Securizarea informației protejează informația de o gamă largă de amenințări cu scopul de a asigura derularea unei afaceri, de a minimiza pierderile și de a crește recuperarea investițiilor. Indiferent de modul cum este stocată sau transmisă (tipărită, înmagazinată electronic, transmisă prin radio, prin căi electronice, în film sau prin conversație), informația trebuie protejată adecvat.
Securizarea informației înseamnă, în accepțiunile ISO 17799, păstrarea confidențialitații, prin accesul la informație numai al persoanei autorizate, asigurarea integrității informației, și implicit, asigurarea disponibilității informației.
Securitatea informației se aplică printr-un set de politici, practici, proceduri, structuri organizaționale și funcțiuni software.
Interconectarea dintre rețelele publice și cele private a făcut ca sistemele informatice să fie mai vulnerabile la amenințări precum fraude prin computere, spionaj electronic, acte de vandalism, incedii.
Asigurarea securizării informației este mai ieftină și mai eficientă, dacă se ia în calcul din faza de proiectare a sistemului informatic, cu identificarea și evaluarea riscurilor.
Dependența de sistemele de informații a făcut ca instituțiile bancare să devină tot mai vulnerabile la riscurile de pierdere, distrugere sau alterare, precum și față de utilizarea sau divulgarea neautorizată a informațiilor sensibile, în mod accidental sau voluntar.
Tehnicile de evaluare a riscurilor se aplică asupra întregii organizații sau numai asupra unor componente specifice de sistem, iar riscurile de securitate trebuie reevaluate periodic la toate nivelele, pe baza raportării incidentelor de securitate.
Controalele din punct de vedere legislativ pentru securitatea informației includ: dreptul la proprietate intelectuală, protecția datelor organizației și a informațiilor personale. Mecanismele de control sunt orientative, fiecare instituție bancară alegând cele mai bune practici de protecție a securității informației.
cap. iv. analiza profitabilității clienților de carduri
4.1. Arhitectura sistemelor informatice necesare procesării tranzacțiilor cu carduri
În acest capitol se va prezenta schematic procesul finalizarii unei plati electronice precum si sistemele informatice implicate în acesta.
Tranzactiile comerciale cu plata sunt caracterizate de o complexitate ridicata datorita implicarii mai multor entitati economice: Clienti, Comercianti, Institutii Financiare, Banci, Sistemele sau Casele de Clearing etc, finalizarea lor se desfasoara pe o perioada mai îndelungata de timp cu posibilitatea utilizarii mai multor monede implicând sisteme si mecanisme de control si securitate complexe cu timp redus de reactie (de ordinul secundelor) si costuri de operare reduse.
În Figura 4.1. este descris la nivel conceptual procesul unei tranzactii comerciale cu plata prin card.
Figura 4.1 Procesul unei tranzactii comerciale cu plata prin card
În cadrul acestui proces se pot distinge mai multe etape ce se produc la diverse momente de timp:
Astfel, la momentul de timp T0:
Etapa 1: Clientul identifica produsele ce doreste sa le achizitioneze, Comerciantul îi confirma cantitatea si valoarea acestora.
Etapa 2: Comerciantul initiaza procesul de acreditare a solvabilitatii clientului, transferând identificatorii acestuia Casei / Sistemului de Clearing
Etapa 3: Sistemul / Casa de Clearing autentifica si acrediteaza solvabilitatea Clientului cu Emitentul cardului utilizat de catre Client. În mod uzual, aceasta etapa este iterativa în sensul ca exista un lant de Case / Sisteme de Clearing implicate în autentificare în functie de tara de origine a Emitentului, tara de origine a Comerciantului, tipul de card utilizat, suma de plata etc. În aceasta etapa creditul Emitentul reduce creditul Clientului cu suma aferenta.
Etapa 4: Sistemul / Casa de Clearing autentifica si acrediteaza Comerciantului disponibilitatea sumei solicitate în contul Clientului.
Etapa 5: Comerciantul elibereaza / distribuie bunurile solicitate de Client
La momentul de timp T1:
Etapa 6: Sistemul / Casa de Clearing determina balanta platilor / încasarilor pe care trebuie sa le faca Emitentul si are loc stingerea datoriilor dintre Emitent si Sistemul / Casa de Clearing. Frecventa acestor operatiuni variaza în functie de tipul de card si relatiile contractuale (pot fi zilnic, saptamânal , lunar – minimum)
La momentul de timp T2:
Etapa 7: Sistemul / Casa de Clearing plateste Comerciantului cu o anumita frecventa sumele aferente bunurilor platite cu carduri de catre diversi Clienti (inclusiv tranzactia pentru Clientul mentionat mai sus). Frecventa platilor depinde de Banca Comerciantului, de întelegerile între parti, tipul de card precum si sumele de plata.
Etapa 8: Comerciantul reconciliaza sumele primite cu cele din registrele de vânzari / încasari pentru perioada respectiva.
La momentul de timp T3:
Etapa 9: Emitentul factureaza Clientul cu contravaloarea produselor / serviciilor achizitionate de catre Client cu cardul într-o anumita perioada de timp (zi, saptamâna, luna) .
La momentul de timp T4:
Etapa 10: Clientul certifica tranzactiile efectuate si efectueaza plata facturii catre Emitent.
Se considera ca o tranzactie este finalizata când toate etapele sunt completate fara repudierea acesteia de nici una din parti implicate in process.
Momentele de timp T1 – T4 pot fi în orice succesiune, neexistând o dependenta standard (de exemplu Emitentul poate emite un ordin de Direct Debit (Etapa 10) înainte de initierea oricarei dintre Etapele 6-9).
Din punct de vedere informatic sunt necesare urmatoarele sisteme pentru procesarea eficienta a tranzactiilor prin carduri.
A. Sistemele Emitentului:
Sistemul de Carduri asigura managementul pentru emiterea de carduri, pinuri sau alte chei unice utilizate în procesul de autentificare, asigura acreditarea on-line a Clientilor la punctul de vânzare, înregistreaza toate tranzactiile efectuate de clientii sai, emite facturile catre clienti, întretine balanta si starea conturilor clientilor etc . Sistemul asigura stocarea acestor informatii pe o perioada de cel putin 5 ani.
Sistemul CRM (Customer Relationship Management) asigura managementul interfetei dintre Emitent si Clienti. Acest sistem permite colectarea datelor de contact pentru fiecare actual sau potential client utilizator de card, cererile de emitere / reemitere de carduri si/sau pinuri, înregistrarea problemelor clientilor precum si a solutiilor oferite, etc).
Sistemul asigura stocarea acestor informatii pe o perioada de pâna la 5 ani.
Sistemul ERP (Enterprise Resource Planner) asigura managementul facturilor si încasarilor de la Clienti, calcul balanta de plati catre Casa de Clearing etc. Sistemul asigura stocarea acestor informatii pe o perioada de 5-10 ani in functie de cerintele organizatiei precum si cele fiscale.
B. Sistemele Comerciantului:
Sistemul POS este implementat la fiecare punct de vânzare al Comerciantului si are rolul de a asigura înregistrarea tuturor tranzactiilor, autentificarea si acreditarea Clientilor si stocarea acestor informatii pe o perioada de timp ce variaza între o zi (minimum) sau luna (maximum).
Sistemul POS-HQ asigura consolidarea zilnica la sediul Comerciantului a tranzactiilor cu carduri de la fiecare din sistemele POS din punctele de vânzare. Sistemul POS-HQ asigura stocarea tranzactiilor cu carduri pe o perioada de 1-3 ani.
Sistemul ERP asigura managementul resurselor comerciantului, vânzari, stocuri, cumparari, reconcilierea cu institutiile financiar-bancare a sumelor încasate ca urmare a tranzactiilor cu carduri etc.
4.2. Arhitectura de baza a unui sistem infomatic pentru managementul si analiza profitabilitatii clientilor de carduri
În acest capitol se propune o arhitectura de sistem informatic pentru managementul si analiza clientilor de carduri care îndeplineste cerintele corespunzatoare modelului de calcul si de afacere D într-o piata cu mai multi Emitenti (1->m) si mai multi Comercianti (1->n).
În figura 4.2. este prezentata arhitectura unui sistem informatic utilizat de unul sau mai multi emitenti pentru managementul si analiza profitabilitatii clientilor de carduri (CPM = Customer Profitability Management). Astfel, se pot identifica mai multe subsisteme:
Subsistemele Emitentului si Comerciantului asigura datele de intrare în CPM (1)
Subsistemul de calcul a profitabilitatii si depozitul de date al Emitentului reprezinta subsistemele de procesare ale CPM (2)
Subsistemul de raportare si analiza asigura datele si infomatiile de iesire din CPM (3) pentru management Subsistemul Emitentului (1) este proiectat în general sa raspunda cerintelor informatice ale acestuia si se compune în general din sistemul procesarii tranzactiilor de carduri , ERP (Enterprise Resource Planner) si CRM (Customer Relationship Management).
Exista situatii frecvente în care subsistemul Emitentului nu contine toate informatiile necesare CPM despre Emitent sau despre mediul economic, social, ecologic în care evolueaza acesta.
Colectarea acestor informatii poate avea scopuri diferite ce pot varia de la diverse analize specializate cu ajutorul unor segmentari noi ale produselor, clientilor (altele decât cele necesare operarii de zi cu zi), la rezultatele campaniilor de marketing, la determinarea planului de dezvoltare pe urmatorii 3-5 ani, cotei de piata, a tendintelor în piata, la impactul econmic al lansarii de noi produse, de analiza a mediului de lucru si competitorilor prin date financiare si de performanta sau alte date despre calitatea mediului, progonze meteorologice etc.
În cele mai multe cazuri toate aceste date si informatii suplimentare sunt stocate într-un mediu non-ERP ce poate varia de la simple fisiere (text, csv, xls, tabele web) si pîna la aplicatii specializate etc si urmeaza a fi utilizate de catre CPM în sistemele de asistare si programare a deciziilor Emitentului.
În mod analog subsistemele Comerciantului (1) pot fi si ele completate cu subsisteme non-ERP pentru informatiile suplimentare.
80
Figura 4.2 Arhitectura de baza a unui sistem infomatic pentru managementul si analiza profitabilitatii clientilor de carduri
Subsistemul de calcul a profitabilitatii si depozitul de date al Emitentului (2) are rolul de a extrage, converti, încarca, calcula , stoca si organiza în modul cel mai eficient toate datele necesare producerii de informatii pentru managementul Emitentului si pentru asistarea deciziilor acestuia.
Lucrarea de fata identifica 3 subsisteme ce trebuie implementate ca elemente de baza ale acestui subsistem:
Subsistemul ETL (Extragere, Încarcare, Conversie si Calcul)
Depozitul de date (Datewarehouse)
Motorul OLAP
Subsistemul ETL („Extract Transform Load”) asigura urmatoarele functii:
1. Extrage datele de intrare din subsistemele sursa ale Emitentului si/sau Comerciantului: ERP, CRM, Sistem Carduri etc .Aceasta extragere a datelor poate fi realizata prin accesarea unor tabele din bazele de date aferente aplicatiilor sursa, prin lansarea unor programe speciale de conversie si extragere din fisiere sursa, prin utilizarea unor macrouri de extragere din aplicatiile ERP sau prin call-uri externe ale sistemelor sursa.
2. Converteste datele din formatul sursa în structura si formatul cerut de modelul si sistemul de raportare. Functiile de conversie pot fi simple (de exemplu transforma valoarea 1 în Masculin si 0 în Feminin) sau pot ajunge la subrutine complexe (de exemplu calculeaza valoarea unui câmp pe baza valorilor din mai multe câmpuri ale aceleiasi înregistrari, realizarea de mapari pe baza de tabele ce vor fi accesate on-line, sortari sau agregari ale datelor de intrare. Acest proces datele se finalizeaza când datele se regasesc într-un format si model uniform în tabelele cu datele initiale ale depozitului de date.
3. Încarca datele de intrare într-o zona tampon pentru procesari ulterioare (denumita repository).
4. Verifica integritatea datelor de intrare din zona tampon prin validarea referintelor sau functionala a datelor de intrare (de exemplu: Codul clientului din tranzactie este definit în tabela Client; pretul unitar nu poate fi mai mare de 10 RON etc). Creeaza jurnale de erori cu eventualele inconsistente si determina nivelul de eroare întîlnit în functie de anumiti parametrii (de exemplu: procentaj din numarul de înregistrari, din valoare totala a vânzarilor etc). Sistemul poate decide continuarea sau oprirea procesarii în functie de rezultatele obtinute si limitele definite în fluxul procesului (de exemplu în cazul în care numarul erorilor este sub 1% din numarul de tranzactii atunci se poate continua procesarea, în caz contrar se opreste procesul si se avertizeaza administratorul de aplicatie).
5. Calculeaza diversele elemente componente ale modelului de profitabilitate (prezentat în capitolul 5.3). În aceasta faza (în functie de complexitatea modelului de calcul), sistemul genereaza o noua tabela cu rezultatele calculului profitabilitatii. Sistemul va utiliza pentru fiecare element functia specific definita ce va returna valorile corespunzatoare fiecarui nivel din modelul de profitabilitate.
În functie de complexitatea modelului de calcul al profitabilitatii, problematica subsistemului ETL se poate realiza fie cu produse software standard sau cu software dezvoltat specific modelului.
În prezent se regasesc solutii software standard pentru subsistemul ETL ce pot exista fie integrate în sistemele de gestiune a bazelor de date sau parte a unor solutii de Business Intelligence:
MS SQL Server Data Transformation Services
Oracle Warehouse Builder
Business Objects Data Integrator
Cognos DecisionStream
Depozitul de date („Datewarehouse”) asigura organizarea datelor procesate de subsistemul ETL în cadrul unui sistem de baze de date si reprezinta baza tuturor proceselor de asistare a deciziilor manageriale.
Depozitul de date trebuie sa organizeze datele in structura care sa corespunda modelului de profitabilitate definit de Emitent, cerintelor de raportare si trebuie sa asigure datele necesare managementului, calculul si analiza profitabilitatii clientilor de carduri pentru a putea asigura cerintele de raportare cu costuri minime de exploatare.
Depozitul de date se poate realiza utilizând unul din urmatoarele sisteme de gestiune a bazelor date:
MS SQL Server
Oracle
Sybase
IBM DB/2
Cache
Motorul OLAP asigura organizarea superioara a datelor elementare ale depozitului de date pentru optimizarea accesului la informatii. Cu ajutorul motorului OLAP se pot genera diverse cuburi multidimensionale necesare analizelor pentru management.
Motoarele OLAP inteligente sunt programabile sau pot autodetermina momentul la care este necesara regenerarea cuburilor multidimensionale. În prezent exista diverse motoare OLAP fie integrate în sistemele de gestiune a bazelor de date sau ca servicii independente:
MS SQL Server 2005 Analysis Services
Oracle 10g BI Discoverer
Business Objects OLAP Intelligence
Cognos PowerPlay
În practica se pot regasi doua scenarii diferite de utilizare a motoarelor OLAP cu regenerare lenta si rapida a cuburilor. Din punctul de vedere al sistemului pentru managementul si analiza a profitabilitatii utilizatorilor de carduri se pot considera doua scenarii de lucru:
Scenariul 1. Sistemul de carduri este off-line sau lucreaza în mod intermitent. Tranzactia se efectueaza la punctul de vânzare si la un anumit interval de timp (zi, saptamâna, luna) este transferata în Sistemul de Carduri parte a unui set de tranzactii din perioada respectiva. În acest caz, întreg sistemul CPM este off-line.
Sistemul ELT va extrage din Sistemul de Carduri doar setul de tranzactii aferent perioadei respective si îl va încarca în depozitul de date. Motorul OLAP va regenera cuburile multidimensionale specifice tranzactiilor doar la transferul complet al întregului set de tranzactii.
Dupa închiderea de luna si încarcarea costurilor aferente si finalizarea calculului profitabilitatii, motorul OLAP va regenera si cuburile aferente profitabilitatii.
Aceasta solutie de operare este cea mai des întîlnita în prezent. Ea are avantajul de a permite operarea sistemului CPM cu costuri relativ mici. Dezavantajul este ca nu permite depistarea timpurie a fraudelor sau a tentativelor de frauda.
Scenariul 2. Sistemul de carduri functioneaza on-line.
Tranzactia se efectueaza la punctul de vânzare si la finalizarea ei este transferata direct în Sistemul de Carduri.
Sistemul ETL va transfera „aproape on-line„ din Sistemul de Carduri în depozitul de date, urmând ca motorul OLAP sa regenereze o parte din cuburile pentru analiza tranzactiilor la intervale reduse de timp (ordinul minutelor).
Si în acest caz motorul OLAP poate regenera cuburile aferente profitabilitatii doar dupa închiderea de luna si încarcarea costurilor aferente si finalizarea calculului profitabilitatii.
În acest caz sistemul CPM este partial on-line în sensul ca o parte din cuburile de analiza a tranzactiilor sunt regenerate aproape on-line. Are avantajul prevenirii fraudelor însa costurile de operare sunt foarte ridicate datorita cerintelor de transfer si procesare a tranzactiilor on-line.
Sistemul de raportare si analiza
Lucrarea de fata propune un Sistem de raportare si analiza (3) din cadrul CPM ce are la baza urmatoarele concepte:
Managementul prin exceptii este utilizat ca principala metoda în determinarea clientilor importanti, a celor problematici precum si a actiunilor ce trebuie intreprinse pe fiecare nivel decizional (de la management si pâna la agentii de vânzari);
Depozitul de date constituie singura sursa de date pentru orice raportare a companiei;
Sistemul asigura analize „top-down” pe nivele ierarhice ale companiei;
Sistemul asigura un acces on-line si off-line al utilizatorilor la diverse unelte de raportare si analiza pentru a asigura exploatarea cât mai eficienta si sigura a acestuia;
Sistemul de raportare asigura un set de unelte de raportare care permit atât accesul direct la informatii (pentru utilizatorii finali) cât si facilitati de analiza complexa si data mining (pentru analisti).
Figura 4.3 prezinta într-un mod grafic modul de organizare a informatiei pe diverse nivele ierarhice. Astfel, profitabilitatea unui Agent de Vânzari se obtine din însumarea profitabilitatii Clientilor deserviti de acesta, profitabilitatea Departamentului se obtine din însumarea profitabilitatii Agentilor de Vânzari activi în cadrul unui departament iar profitabilitatea Companiei se obtine din însumarea profitabilitatii tuturor Departamentelor de Vânzari ale acesteia.
Costurile / Veniturile departamentelor auxiliare sunt regasite în profitabilitatea fiecarui Client prin alocarea acestora pe baza unor chei prestabilitate.
Subsistemul „KPI Drill-Down” permite analiza pe nivele ierarhice a principalilor indicatori de perfomanta si asigura regasirea acelorasi parametrii de la nivelul Companiei si pâna la nivelul Clientului (de exemplu: Cantitati vândute, rata profitului, cresterea procentuala a unor parametrii fata de luna trecuta etc).
Subsistemul „KPI Drill-Down” asigura atât comparatii ai acestor parametrii la diverse momente de timp (de exemplu: Luna Curenta, Anul Curent, Anul Precedent etc), variatiile între acestea sau fata de plan cât si tendinta lor de-a lungul unei perioade de timp (de exemplu: trimestru, an , etc).
Figura 4.3 Organizarea informatiei si a intregului sistem pe nivele ierarhice
Subsistemul SETAQ foloseste tehnologia de impingere („push”) a documentelor catre utilizatorii finali si asigura urmatoarele facilitati de raportare:
Standard – rapoarte ce au ca obiectiv asigurarea unei vizualizari de ansamblu asupra unei parti din afacere si care includ un set presetat de elemente de analiza;
Exceptii („Exceptions”) – rapoarte pentru analizarea unor anumiti parametri de performanta (de exemplu primii 5 agenti de vânzari în functie de cantitate, clientii cu profitabilitate negativa etc);
Tendinte („Trends”) – rapoarte pentru determinarea tendintelor (de exemplu cresteri sau scaderi ale cumpararilor efectuate de un client, agent de vânzari, departament etc);
Alarme („Alarm”) – rapoarte de alarmare în cazul atingerii unor parametri prestabiliti (de exemplu: profitabilitatea unui segment de clienti a scazut sub un anumit prag unitar);
Analiza Calitativa („Quality Analysis”) – rapoarte de analiza calitativa a rezultatelor (de exemplu: segmentul clientilor cu 1- 5 carduri a înregistrat o crestere a vânzarilor cu 10%);
Subsistemul de Asistare a Deciziilor (DSS) pune la dispozitia utilizatorilor programe specializate de asistare a deciziei ce se pot conecta direct la depozitiul de date sau la un instantaneu al acestuia (data mart).
Subsistemul BI („Business Intelligence”) permite realizarea de analize complexe ad-hoc sau la anumite momente de timp prestabilite si asigura facilitatile sde data mining.
Business Objects Extreme Insight
Cognos PowerPlay
Oracle Data Mining & BI Beans
4.3. Structura de baza a depozitului de date
Lucrarea de fata propune o structura de baza a depozitului de date asociat re sa satisfaca cerintele minimale de calcul si analiza a profitabilitatii clientilor de carduri. Aceasta structura a depozitului de date poate fi dezvoltata pe parcursul exploatarii in functie de nevoile Emitentului.
Astfel, figurile 4.4 si 4.5 contin doua exemple de scheme utilizate de subsistemele „KPI Drill-Down” si subsistemul „SETAQ (aferente tranzactiilor de carduri si profitabilitatii acestora) ca element de baza al depozitului de date.
Figura 4.4 Schema tabelelor cu tranzactii prin carduri
Schema din Figura 4.4. contine urmatoarele tabele si permite analizarea tranzactiilor individuale zilnice si a vânzarilor pe fiecare Card în parte:
CARD – contine datele de identificare ale Cardurilor utilizate de Clienti
CUSTOMER – contine datele de referinta ale Clientilor
DEPARTMENT – contine datele de referinta ale fiecarui Departament din cadrul Emitentului
GEOGRAPHY – contine clasificarea geografica a identificatorilor unici ai entitatilor economice implicate în afacere (Emitenti, Clienti, Comercianti etc)
ISSUER –contine datele de referinta ale Emitentilor KEY_ACCOUNT – contine datele de referinta ale Clientilor Importanti ai Emitentilor
MERCHANT- contine datele de referinta ale Comerciantilor
NACE – contine clasificarea standard C.A.E.N.
NETWORK – contine datele de referinta ale Retelelor de Distributie
POS – contine datele de referinta ale Punctelor de Vânzare
PRODUCT – contine datele de referinta ale fiecarui Produs vândut de Comerciant
SALES_REPRESENTATIVE – contine datele de referinta ale Agentilor de Vânzari ai Emitentilor
TRANSACTION – contine tranzactiile individuale efectuate de clientii de carduri
UNSPSC – contine clasificarea standard a produselor UNSPSC
Figura 4.5 Schema tabelelor pentru profitabilitate
CREDIT_MANAGEMENT – contine datele aferente creditului fiecarui acordat Client, precum si evolutia acestuia în timp
P_L – contine înregistrarile aferente calcularii profitabilitatii pentru perioada de raportare curenta (de exemplu luna Mai 2005)
P_L_ARCHIVE – contine arhiva cu înregistrarile calculelor de profitabilitate efectuate lunar (de exemplu lunile Ian 2000 – Mai 2005)
P_L_KPI – contine un instantaneu al P_L_ARCHIVE care permite analiza acelorasi indicatori principali de performanta la diversele nivele ale organizatiei . Motorul OLAP genereaza acest instantaneu dupa ce se termina inserarea înregistrarilor din luna curenta în tabela P_L_ARCHIVE
P_L_TREND – contine un instantaneu al P_L_ARCHIVE care asigura analiza tendintelor unor indicatori de performanta pe un anumit interval de timp (în acest caz trimestru). Motorul OLAP genereaza acest instantaneu dupa ce se termina inserarea înregistrarilor din luna curenta în tabela P_L_ARCHIVE.
4.4. Instrumente si metode pentru managementul si analiza a profitabilitatii clientilor de carduri
În acest subcapitol vor fi prezentate exemple de instrumente si tehnici de management pe care le are la dispozitie o companie dupa implementarea sistemului pentru management si analiza a profitabilitatii clientilor de carduri
Exemplu 1 Analiza comparata a calitatii managementului clientilor
Scenariu:
Compania XYZ vinde produse din gama ABC clientii sai (în numar foarte mare) ce utilizeaza plata prin carduri la punctele de vânzare.
Managementul clientilor este asigurat de doua echipe de agenti de vânzari care deservesc clientii în functie de marimea lor:
Echipa A deserveste clientii mari (vânzari peste 1.000.000 unitati)
Echipa B deserveste clientii mici (vânzari sub 1.000.000 unitati)
Aceste doua echipe de vânzari sunt organizate pe 4 nivele ierarhice în ceea ce priveste autorizarea discounturilor oferite clientilor. Nivelul 1 corespunde nivelului de baza (Agent de Vânzari Junior) si poate acorda clientilor discounturi reduse în timp ce Nivelul 4 corespunde nivelului maxim de autoritate în cadrul echipei de vânzari si poate acorda cele mai mari discounturi.
Directorul de vânzari al companiei (managerul celor doua echipe) stabileste limita maxima a discountului (aferent Nivel 4) la diverse nivele de cumparaturi ale clientilor în vederea asigurarii unui anumit profit unitar.
Cerinte:
Directorul de vânzari doreste sa controleze respectarea politicilor de discount si sa elimine situatiile care duc la reducerea profitului.
Solutie:
Sistemul va produce graficul din Figura 4.6. ce reprezinta o analiza a discountului unitar în functie de marimea clientilor pe o anumita perioada de timp si releva faptul ca Echipa A respecta politica de acordare a discounturilor în timp ce Echipa B încalca frecvent modul de acordare a discounturilor.
Analiza suplimentara a rapoartelor Standard si Exceptie (SETAQ) la nivelul fiecarui agent de vânzari si client poate releva cauze variate ce au condus la acest efect:
Nerespectarea frauduloasa a politicii de discount
Campania agresiva de discouturi în segmentul Echipei A a determinat modificarea comportamentului pietei în detrimentul echipei B. Clientii mici afla discounturile acordate clientilor mari si solicita acelasi nivel fortând Echipa B sa acorde disconturi mai mari decât cele stabilie.
Calitatea scazuta a datelor din sistem. Identificarea organizatiei clientilor nu functioneaza corect – Clientii mici ce au primit discounturi mari apartin de fapt aceluiasi holding la nivelul caruia a fost agreat acel discount.
Figura 4.6 Analiza Management Clienti in functie de Discount Unitar
Exemplul 2. Curbele S – Analiza profitabilitatii la costuri directe si indirecte Scenariu:
Compania XYZ doreste sa-si îmbunatateasca pe termen scurt profitul total pentru a putea acorda mai multe dividende actionarilor.
A fost elaborata o strategie, care sa asigure atingerea acestui obiectiv pe termen scurt, ce se bazeaza pe doua principale actiuni:
îmbunatatirea cifrei de afaceri cu clientii ce genereaza cel mai mare profit utilizând o campanie de marketing direct
identificarea si eliminarea clientilor cu pierderi (închiderea contractelor sau prin renegocierea acestora)
Cerinte:
Directorii de marketing si vânzari au nevoie sa identifice clientii foarte profitabili si cei neprofitabili pentru implementarea celor doua actiuni.
Solutie:
Sistemul SETAQ genereaza pentru fiecare Emitent / Agent de Vânzari curbele S ce reprezinta analiza profitabilitatii clientilor atât la costuri directe si indirecte. În figura 6.8. sunt prezentate doua astfel de curbe.
În urma analizarii celor doua curbe S se releva urmatoarele:
20% dintre clienti genereaza 80% din profit – Acest segment va constitui baza campaniei de marketing în vederea cresterii cifrei de afaceri si implicit a profitului
70% dintre clienti sunt într-o zona de profit marginal – Acest segment va fi exclus oricaror actiuni pe termen scurt datorita numarului ridicat de clienti
10% dintre clienti genereaza pierderi si implicit reduc profitul general al companiei – Acest segment va fi subiectul campaniei de închidere a contractelor sau renegociere.
Figura 4.7 Curba S de profitabilitate
Exemplul 3. Analiza Cifra Afaceri – Profitabilitate – Discount
Scenariu:
Compania XYZ doreste sa-si îmbunatateasca pe termen lung profitul total pentru a putea acorda mai multe dividende actionarilor. Compania a elaborat o strategie care sa asigure atingerea acestui obiectiv pe termen lung. Strategia se bazeaza pe urmatoarele directii de actiune:
Segmentarea clientilor în functie de numarul de carduri ca principal criteriu de actiune
Atragerea de noi clienti în segmentele slab reprezentate printr-o oferta corespunzatoare fiecarui segment în parte
Îmbunatatirea profitabilitatii unitare a clientilor în segmentele în care aceasta este scazuta
Cerinte:
Directorul de marketing are nevoie sa identifice pentru fiecare din segmentele stabilite (de exemplu numar carduri 1-5, 6-10 etc) cifra de afaceri, profitul unitar precum si discountul unitar acordat .
Solutie:
Sistemul SETAQ genereaza noua segmentare a clientilor si calculeaza pentru fiecare segment cifra de afaceri, profitul si discountul unitar – vezi figura 6.9
Sistemul genereaza raportul Analiza Cifra Afaceri – Profit – Discount pe segmentele de carduri definite de directorul de marketing ce identifica:
Segmentul 1-5 carduri (clienti mici) cu o participare ridicata în cifra de afaceri si rata cea mai ridicata a profitului
Segmentul 6-10 carduri (clienti mici) cu o participare redusa în portofoliul total desi acesta genereaza în medie un profit unitar ridicat
Segmentul 26-50 carduri (clienti medii) ajunge la o profitabilitate unitara egala cu discountul acordat clientului
Segmentul 1000+ carduri (clienti mari) cu o participare substantiala în total cifra de afaceri dar cu o profitabilitate scazuta si un discount unitar foarte mare.
Concluzia este aceea ca pe termen lung campania de marketing se va adresa clientilor din segmentul mic si mediu (1-10) pentru cresterea ponderii în total cifra afacere, precum si scaderea discounturilor acordate clientilor în segmentul mediu – mare prin renegocierea contractelor si /sau ofertarea unor produse / servicii diferite în vederea cresterii profitului unitar.
Figura 4.8 Analiza Cifra de Afaceri – Profit – Vanzari
Exemplul 4. Analiza Principalilor Indicatori de Profitabilitate
Scenariu:
Compania XYZ doreste sa identifice departamentele ce au dus la rezultate financiare exceptionale în primul trimestru si sa stimuleze acest fenomen pentru restul anului.
Cerinte:
Directorii de vânzari ai diverselor departamente trebuie sa prezinte rezultatele fiecarui departament conform principalilor indicatori de performanta si sa identifice principalii agenti de vânzari pentru acordarea unor bonusuri speciale
Solutie:
Directorii de departament (de exemplu: B2B , B2C etc) utilizeaza rapoartele „KPI Drill-Down” la nivelul Departament – Agent Vânzari.- vezi figura 4.9.
Figura 4.9 Analiza Profitabilitate Departament
Exemplul 5 . Sistem de asistare a deciziei agentilor de vânzari si realizarea ofertelor pentru clienti
Scenariu:
Compania XYZ detine o retea europeana de distributie si vânzare a produselor sale cu facilitati de plata prin carduri. Compania XYZ doreste sa creasca cota de piata într-un mod profitabil.
Cerinte:
În cadrul strategiei de marketing a fost identificata necesitatea implementarii unui sistem de asistare a agentilor de vânzari în realizarea ofertelor catre clientii de carduri ce vor efectua cumparari în diversele tari europene.
Sistemul de asistare a deciziilor trebuie sa permita:
Lucrul off-line al agentilor de vânzari
Estimarea profitabilitatii la renegocierea unui contract sau la arondarea unui nou client
Alarmarea utilizatorului în cazul în care conditiile de profitabilitate prestabilite nu au fost îndeplinite
Lucrul colaborativ între Agentul de Vânzari si managerii acestuia în vederea solicitarii aprobarii diverselor discounturi si a ofertei finale, revizuirea ofertei la diverse momente de timp în functie de modificarile ce intervin pe piata sau între parteneri
Emiterea ofertei finale catre Client în limba acestuia si integrarea acesteia în sistemele Emitentului
Actualizarea zilnica a unora din parametrii cu variatii semnificative în determinarea profitabilitatii si semnarea contractului.
Solutie:
Agentii de Vânzari ai Emitentului vor instala si utiliza sistemul „e-Offer” dezvoltat ca sistem de asistare a deciziilor în cadrul CPM.
Sistemul “e-Offer” este o solutie care permite lucrul off-line al Agentilor de Vânzari si este compus din doua parti principale (vezi figura 6.11):
A. Front End (Interfata)
Contine componentele folosite de utilizator:
Linkul catre “e-Offer” situat în directorul Desktop al utilizatorului. Acesta are rolul de facilita pornirea rapida a programului.
Interfata utilizator e-Offer_V5.05.xls situata în subdirectorul e-Offer din directorul Desktop al utilizatorului. Acesta contine partea logica si în principal reprezinta interfata utilizator.
B. Back-end (Data Marts)
Componentele back-end sunt doua fisiere necesare programului pentru o functionare corecta si sunt utilizate la stocarea datelor de referinta si a tranzactiilor clientilor de carduri.
Componentele back-end sunt:
Daily_Input_yyyymmdd.xls, este un fisier MS Excel trimis zilnic prin / catre toti utilizatorii. Acest fisier contine datele ce au variatii zilnice sau frecvente (Preturile de lista, Ratele de schimb între diverse monezi etc)
RO_[Cod Departament]_E-OFFER_yyyymmdd.mdb este un fisier MS Access generat lunar de sistemul CPM si contine toate datele de referinta ale clientilor, rezultatele de profitabilitate consolidate, costurile produselor în punctele de vânzare etc
Figura 4.10. Structura Sistemului e-Offer
Dupa lansarea “e-Offer” utilizatorul (agentul de vânzari) va avea la dispozitie urmatoarele facilitati:
Ecranul Întâmpinare ("Welcome”)
În figura 4.11 este prezentat ecranul de întâmpinare a utilizatorului.
Sistemul va permite sa selectati limba în care se realizeaza oferta având în vedere ca documentul de iesire din sistem va fi înmânat clientului si serviciului de asistenta a clientilor pentru introducerea datelor contractuale în sistemele Emitentului.
Apasând butonul „Update Price Information !” programul este actualizat cu ultima versiune a datelor ce se modifica zilnic si care sunt continute în fisierul Daily_Input_yyyymmdd.xls salvat pe computerul utilizatorului Se poate la trece la urmatorul ecran (“Main”) pentru a realiza selectiile unei oferte noi apasând butonul „Make New or Review Offer !”
Codul culorilor folosite în program permite utilizatorului sa înteleaga daca o actiune îi este ceruta (câmp de intrare date) sau este un câmp cu informatii furnizate de sistem. Astfel Câmpul Albastru Deschis = Câmp de Intrare Date iar Galben Deschis = Câmp Informatii Furnizate de Sistem (nu se pot schimba).
Figura 4.11 Ecranul Întâmpinare („Welcome”)
Ecranul Principal (“Main”)
Acest ecran permite utilizatorului realizarea unei oferte noi, verificarea uneia existente sau colaborarea cu alti utilizatori prin încarcarea ofertelor realizate de acestia.
Ecranul permite utilizatorului selectarea din liste predefinite a tarii clientului, departamentului în care activeaza, precum si luna pentru care sunt disponibile cubul cu informatii (Istoric 12 luni). Sistemul conecteaza automat interfata utilizator la cubul de date solicitat.
Pentru a continua oferta, este necesar a selecta nume de agent de vânzari, codul sau numele clientului (daca exista), sau introducerea unui nume nou.
Odata selectat clientul, utilizatorul selecteaza produsele ofertate clientului precum si tara în care acesta le va receptiona.
Figura 4.12 Ecranul Principal („Main”)
Dupa completarea câmpurilor de selectie utilizatorul are la dispozitie urmatoarele optiuni:
Crearea unei oferte noi apasând pe butonul „Click here to Calculate a NEW offer !”
Verificarea unei oferte existente apasând butonul „Click here to Review CURRENT offer !”
Încarcarea unei oferte mai vechi salvate sau a unei oferte trimise de alt utilizator al sistemului se realizeaza apasând butonul „Click here to IMPORT an old offer !”
Reîntoarcerea la ecranul de Întâmpinare („Welcome”) apasând butonul „Back to Welcome !” pentru modificarea limbii sau revizuirea datelor zilnice cu un nou fisier primit.
Zona de informatii din partea de jos a ecranului Principal („Main”) permite vizualizarea locatiei programului (celula C32) în timp ce celulele J31 & J32 dau informatii privind versiunea interfetei si a cubului de date pentru a asigura compatibilitate acestora si a nu genera conflicte functionale în crearea ofertei.
Ecranul Calcul („Calculation”)
Acest ecran permite utilizatorului sa introduca datele principale ale ofertei precum si cere sa vizualizeze rezultatele estimate ale profitabilitatii si impactul ofertei asupra companiei Emitente.
Se poate observa ca lista tarilor si produselor selectate în ecranul Principal („Main”) este disponibila. În plus, sistemul va lista si toate combinatiile curente folosite de un client existent în cazul în care acestea au fost emise.
Utilizatorul selecteaza numarul de zile pâna la plata facturii din câmpul „Termen de Plata (numar zile)”. Numarul de zile va fi reprezentat în celula B5 si va fi folosit în scopul calculului profitabilitatii.
Utilizatorul introduce pentru fiecare din combinatiile Tara – Produs – Grupa POS solicitate de client cantitatile si discounturile initiale ale ofertei. Acestea se pot revizui la orice moment al ofertei.
Figura 4.13 Ecranul Calcul („Calculation”) – zona vizibila
„e-Offer” monitorizeaza trei tipuri de parametri si avertizeaza utilizatorul în celula B3 daca oricare dintre acesti parametri depaseste limitele stabilite:
Zilele de plata
Rezultatul ofertei are profitabilitatea negativa
Discounturile acordate sunt mai mari decât discounturile maxime
În cazul în care Discount Unitar Oferit (EUR) este mai mare decât Discount Maxim (EUR) un mesaj de avertizare va fi afisat în celula B3 “Atentie! Discount Maxim depasit!”
În cazul în care optiunea aleasa nu face parte din zona conditiilor de plata standard un mesaj de avertizare va fi afisat în cell B3 “Atentie! Termen de plata depasit!”
În cazul în care profitabilitatea este negativa un mesaj de avertizare va fi afisat în celula B3 “Atentie! Oferta nu este profitabila !”
Sistemul pune la dispozitie posibilitatea colaborarii între utilizatori în vederea finalizarii ofertei prin transmiterea ofertei catre aprobare managerului ierarhic.
Apasând butonul „Seek Authorisation” oferta completa este salvata si trimisa cu e-mailul managerului cu explicatiile aferente cererii de aprobare.
Utilizatorul se poate întoarce la ecranul Principal („Main”) pentru a schimba parametrii apasând butonul „Back to Main”. În cazul în care este necesara refacerea ofertei de la început apasând butonul „Clear Data” toate datele introduse manual de utilizator vor fi sterse.
Sistemul detine si o zona ascunsa care este disponibila utilizatorului în momentul în care doreste sa analizeze rezultatele estimate ale ofertei. Accesul la zona ascunsa se face apasând butonul „View/Hide Details” si permite vizualizarea ofertei la diverse nivele de profitabilitate în unitati sau valori totale.
Figura 4.14 Ecranul Calcul („Calculation”) – zona ascunsa
Ecranul Oferta (“Offer”)
În momentul în care cantitatile, discounturile, conditiile de plata au fost revizuite si agreate de comun de cei doi parteneri, utilizatorul apasa butonul „Make Offer” din ecranul de Calcul („Calculation”) si oferta este generata în ecranul Oferta („Offer).
În cadrul ecranului Oferta („Offer”), utilizatorul are la dispozitie mai multe facilitati:
Salvare oferta pentru o revizuire ulterioara sau pentru arhivare apasând butonul „Save Offer & Calculation”
Trimitere oferta cu emailul pentru activitati de colaborare apasînd butonul „E-Mail”
Tiparire oferta apasând butonul „Print”
Revizuire oferta apasând „Back to Calculation”
Figura 4.15. Ecranul Oferta („Offer”)
CONCLUZII
Un sistem informațional al unei bănci este cu atât mai eficient cu cât culegerea, prelucrarea și transmiterea informației are la bază mijloace moderne de calcul sau dacă este susținut de un system informatic adecvat.
Un sistem informatic bancar poate realiza o multitudine de funcțiuni:
• procesarea tranzacțiilor;
• întocmirea și ținerea evidenței contabile și a altor evidențe operative privind operațiunile curente ale clienților, creditele, depozitele, operațiunile documentare, operațiunile speculative;
• întocmirea rapoartelor pentru conducerea operativă a băncii (MIS);
• întocmirea rapoartelor solicitate de Banca Centrală și alte organe ale administrației centrale sau locale;
• furnizarea de informații necesare deciziilor strategice.
Pentru o bancă comercială problema sistemului informatic nu este temporară, numai la înființare sau când decide să treacă la automatizarea lucrărilor. Practic, această problemă persistă de-a lungul întregii vieți a unei bănci deoarece calitatea serviciilor oferite, precum și deciziile operative și strategice depind de calitatea sistemului informatic.
O definire globală a unui sistem informatic cuprinde resursele software, hardware, de telecomunicații și umane pentru automatizarea lucrărilor băncii. Cum evoluția sistemelor hardware și de telecomunicații este în continuă dezvoltare și perfecționare, rezultă firesc că resursele software trebuie adaptate continuu pentru utilizarea eficientă a potențialului tehnic.
Întrucât problema dezvoltării și perfecționării continue preocupă, în general, băncile care au deja o experiență în gestionarea sistemelor informatice, au fost prezentați pașii pe care o bancă comercială trebuie să-I parcurgă pentru a începe să utilizeze tehnica de calcul.
La finalul lucrării am prezentat schematic procesul finalizarii unei plati electronice precum si sistemele informatice implicate în acesta.
BIBLIOGRAFIE
Andone I., Mockler R., Dologite D., Țugui Al., Dezvoltarea sistemelor inteligente în economie, Editura Economică, București, 2001
Cojocariu, A., Stanciu, Cristina Ofelia, Informatică de gestiune, Editura Eurostampa, Timișoara, 2008
Davidescu, N., Tratat de proiectare a sistemelor informatice prin metoda Merise, Editura Ziua, București, 2006
Fotache, Doina, Groupware – Metode, tehnici și tehnologii pentru grupuri de lucru, Editura Polirom, Iași, 2002
Ganguly, A. R., Gupta A., Data Mining Technologies and decision Support Systems for Business and Scientific Applications, Encyclopedia of Data Warehousing and Mining, Blackwell Publishing, 2005
Hamilton, H., Gurak, E., Findlater, L., Olive, W., Knowledge Discovery in Databases, University of Regina, Canada, 2002, http://www2.cs.uregina.ca/~hamilton/courses/831/notes/ml/dtrees/c4.5/tutorial.html
Joshi, K. P., Analysis of Data Mining Algorithms, http://userpages.umbc.edu/~kjoshi1/data-mine/proj_rpt.htm, 1997
Nițchi, Șt., Rodica Avram-Nițchi, Data mining, o nouă eră în informatică, Revista Byte, România, Februarie 1997, http://www.byte.ro/byte97-02/18tend.html
Nițchi, Șt., Racovițan, D., colectiv, Inițiere în informatica economică și de afaceri, Editura Risoprint, Cluj-Napoca, 2003
Witten, I., Frank, E., Data Mining – Practical Machine Learning Tools and Techniques, Second Edition, Norgan Kaufmann Publishing, 2005
http://www.machinelearning.net
http://www.crisp-dm.org
http://en.wikipedia.ork/wiki
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Analiza Informatizata A Profitabilitatii Clientilor DE Carduri (ID: 134753)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.