From EC Wiki

Putem defini Master Data Management (MDM) ca fiind ansamblul de tehnologii, instrumente si procese necesare pentru a crea si mentine in conditii de consistenta si acuratete seturile de date master ale unei organizatii. Cateva lucruri merita amintite de la bun inceput si anume:

• Frecvent, conceptul MDM este privit in mod incorect ca tinand exclusiv de tehnologie; in realitate, in majoritatea cazurilor sunt necesare schimbari fundamentale ale proceselor de business pentru a mentine datele master in conditii optime, astfel unele din cele mai importante aspecte legate de MDM sunt mai degraba politice decat tehnice;
• MDM include atat crearea cat si mentinerea in conditii de calitate a seturilor de date master. A investi timp, bani si efort doar pentru crearea unui set curat si consistent de date master este o cauza pierduta daca solutia adoptata nu include instrumentele si procesele care sa mentina setul de date master consistent si curat pe masura ce acesta se extinde si se transforma.

Contents 1 „Incepe prudent, gandeste in perspectiva” 2 Clasificarea datelor 3 Probleme asociate datelor master 3.1 Unde sunt datele??? 4 Identificarea datelor master 4.1 Comportamentul / Interactiunile 4.2 Ciclul de viata 4.3 Cardinalitatea 4.4 Durata de viata 4.5 Complexitatea 4.6 Valoarea 4.7 Reutilizarea 5 Activitatile specifice MDM 5.1 Crearea profilului 5.2 Administrarea datelor (Data Stewardship) 5.3 Normalizarea 5.4 Potrivirea (Matching) 5.5 Eliminarea duplicatelor 5.6 Agregarea surselor eterogene (Data Mashup) 6 Fazele unui proiect MDM 7 Beneficiile MDM 8 Concluzie

„Incepe prudent, gandeste in perspectiva”

La prima vedere, pentru maximizarea rezultatelor, conceptul MDM ar trebui aplicat tuturor seturilor de date master ale unei organizatii; totusi in multe situatii riscul si costul unui asemenea efort la scara intregii organizatii ar fi greu de justificat. Ar fi mai usor sa se inceapa cu cateva surse de date cheie, ulterior procesul s-ar putea extinde odata ce obstacolele au fost depasite si succesul a fost demonstrat. Cu toate acestea, ar trebui analizate de la inceput cat mai multe din sursele master de date care, in cele din urma, ar fi incluse in sistem. Astfel, proiectarea sistemului trebuie gandita in perspectiva pentru a permite incorporarea progresiva a noilor surse de date fara a necesita reproiectarea acestuia. Spre exemplu, daca setul initial de date master include doar 10,000 clienti cu care forta de vanzari interactioneaza direct, trebuie proiectat un sistem scalabil care sa permita adaugarea ulterioara a celor 1,000,000 de clienti web.

Clasificarea datelor

In principiu intr-o organizatie exista cinci tipuri de date:

• Nestructurate: email-uri, prezentari, articole, specificatii de produs, materiale de marketing;
• Tranzactionale: facturi, vanzari, achizitii, incidente si alte interactiuni monetare sau non-monetare;
• Metadate: informatii despre structura datelor ce pot fi stocate in registre specializate (repository) sau in alte formate: documente XML, definitii de rapoarte, descrieri de campuri in baze de date;
• Ierarhice: datele ierarhice (super domenii MDM) stocheaza relatiile intre entitati si descriu relatiile ce intervin intre seturile de date master;
• Master: datele ce caracterizeaza nucleul business-ului utilizate de diferitele aplicatii din organizatie, impreuna cu metadatele, atributele, definitiile, regulile, conexiunile si taxonomiile asociate.

Datele master sunt datele cheie cu care opereaza o organizatie, sunt datele consemnate in sistemele tranzactionale, masurate si raportate in sistemele de raportare si analizate de catre sistemele analitice. In general acestea sunt clasificate in:

• Resurse umane (clienti, furnizori, angajati);
• Bunuri (produse, componente, magazine, active);
• Concepte (contracte, licente, incidente);
• Locuri (oficii, divizii geografice)

Probleme asociate datelor master

O organizatie ce are puncte de vedere diferite asupra aceluiasi set de date master va sfarsi prin a pierde timp cu actvitati care se vor repercuta negativ asupra dezvoltarii acesteia. Cand informatiile despre clienti sunt stocate in aplicatii disparate ce nu ofera o vedere unica asupra clientului, organizatia va rata oportunitati; administrarea datelor, asigurarea calitatii acestora, implementarea si monitorzarea politicilor de acces la date vor deveni din ce in ce mai dificile. In final, este amenintata insasi credibilitatea organizatiei care devine din ce in ce mai vulnerabila in fata amenintarilor si constrangerilor mediului extern sau intern.

Unde sunt datele???

Reputatia unei organizatii ar avea de suferit daca inregistrarile aferente clientilor se deterioreaza sau se pierd. Clientii ar putea sa nu primeasca serviciile sau produsele solicitate, productivitatea ar scadea deoarece angajatii ar petrece prea mult timp cautand informatiile de care au nevoie, sau ar putea chiar obtine informatii incorecte. Campaniile de marketing ar putea viza segmente de piata nepotrivite, iar rezultatele nu ar fi cele scontate.

Identificarea datelor master

Chiar daca identificarea entitatilor master este un proces relativ simplu de abordat, nu toate datele care s-ar incadra in definitia „datelor master” trebuie considerate ca atare. Adevaratele date master trebuie sa indeplineasca - cumulativ - cateva criterii foarte importante:

Comportamentul / Interactiunile

Datele master pot fi descrise prin modul in care interactioneaza cu alte date. Spre exemplu, in sistemele tranzactionale datele master sunt aproape intotdeauna combinate cu date tranzactionale. Un client cumpara un produs, un furnizor vinde o componenta, un partener livreaza anumite materiale intr-o locatie, un angajat este subordonat ierarhic unui manager care, la randul lui, raporteaza altui manager (la randul lui angajat). Aceasta relatie intre datele master si datele tranzactionale poate fi privita ca si o relatie subiect / predicat. In timp ce datele tranzactionale sugereaza predicatul (vanzare, livrare, subordonare) subiectul sugereaza datele master. Este chiar relatia „Facts / Dimensions” care sta la baza oricarui Datawarehouse.

Ciclul de viata

Datele master pot fi descrise si prin modul in care sunt create (Created), citite (Read), actualizate (Updated) sau sterse (Deleted). Acest ciclu de viata cunoscut sub acronimul CRUD este dependent de natura datelor si specificul organizatiei. Spre exemplu, modul in care este creat un client depinde de segmentul de industrie, de regulile de business sau de alte sisteme. O companie poate avea canale multiple prin care sunt inregistrati clientii (prin internet, prin intermediul agentilor de vanzari) in timp ce in alta sunt inregistrati doar prin contactare telefonica sau prin intermediul unui call-center.

Cardinalitatea

Cu cat numarul de elemente dintr-un set este mai mic, scade si probabilitatea ca unul din acestea sa fie considerat „master”. Spre exemplu, intr-o companie cu doar trei clienti este foarte probabil ca acestia sa nu fie considerati drept „date master”, cel putin nu in sensul in care ar necesita solutii specializate MDM, pur si simplu pentru ca gestionarea acestora cu o platforma MDM nu ar aduce niciun beneficiu suplimentar. Pe de alta parte, o companie cu zece mii de clienti va plasa Clientul in zona de date master ca urmare a problemelor si beneficiilor care decurg din administrarea unui set de entitati de o asemenea marime. Desi pentru ambele companii clientii sunt in aceeasi masura importanti, totusi doar una dintre ele are nevoie de o solutie MDM. Desi cardinalitatea nu influenteaza clasificarea unei anumite entitati, importanta unei solutii MDM pentru administrarea acelei entitati descreste odata cu scaderea cardinalitatii entitatii respective.

Durata de viata

Datele master au tendinta de a fi mai putin volatile decat datele tranzactionale. Cu cat devin mai volatile, datele sunt considerate mai tranzactionale. Spre exemplu, o companie poate incadra un contract in categoria datelor master in timp ce alta il considera mai degraba ca o tranzactie. In functie de durata de viata, contractul se poate situa in oricare scenariu.

Complexitatea

Entitatile simple, fie ele foarte valoroase, pun rareori probleme de administrare si de aceea sunt rareori incadrate in zona datelor master. Cu cat este mai simpla o entitate cu atat mai mica este probabilitatea de a fi clasificata drept „master”. De regula, aceste entitati sunt pur si simplu colectate si contabilizate. Probabil ca Fort Knox nu pastreaza date despre fiecare lingou de aur ci mai degraba contabilizeaza numarul si valoarea acestora. Desi valoarea fiecarui lingou este semnificativa, cardinalitatea ridicata si durata de viata este mare, totusi complexitatea acestora este scazuta.

Valoarea

De regula, cu cat valoarea unui element este mai mare cu atat mai probabil acesta va fi incadrat in zona datelor master; totusi valoarea si complexitatea trebuie evaluate impreuna.

Reutilizarea

Un aspect deosebit de important legat de MDM consta in reutilizarea datelor. Intr-o lume ideala, un sistem CRM ar gestiona absolut toate informatiile aferente unui client si nu ar exista niciun motiv pentru a partaja aceste informatii cu alte aplicatii. Exact de aici pornesc problemele in lumea reala, cand aplicatii diferite necesita accesul la aceleasi informatii, lucru care nu este intotdeauna posibil din diverse motive (politici de control al accesului, infrastructura, gradul de disponibilitate al serviciilor); acesta este contextul in care apar replici ale datelor master stocate in diferite locatii si formate (spreadsheet-uri , baze de date neintegrate ce deservesc aplicatii izolate). Pentru a fi eficienta o solutie MDM trebuie focalizata, pe cat posibil, pe gestionarea entitatilor reutilizate pe scara larga in cadrul organizatiei.

Activitatile specifice MDM

Crearea profilului

Incepe prin analizarea informatiei utilizand instrumente statistice pentru evaluarea calitatii datelor. Problemele trebuie identificate pana la nivel de sistem sursa si campuri, apoi corectate fie prin modificarea comportamentului aplicatiilor fie prin implementarea de noi algoritmi de translatie (normalizare).

Administrarea datelor (Data Stewardship)

Una din functionalitatile cheie ale unei solutii MDM este de a oferi operatorilor de date posibilitatea de a modela, vizualiza si intretine setul de date master. Initial este proiectat modelul indexului principal care decide asupra entitatilor ce trebuie stocate in model si asupra entitatilor externe referentiate de catre care indexul principal. Acest model devine „unica versiune a adevarului” catre care toate datele master sunt mapate, oferind informatii consistente prin sectiuni ale indexului principal catre aplicatiile participante. Aspectul de „unicitate” a indexului face ca managementul duplicatelor sa fie una din preocuparile cheie ale administrarii datelor . Operatorul de date trebuie sa poata compara eventualele inregistrari duplicate raportate de sistem si sa le unifice pe cele care apartin aceleiasi entitati sau sa le separe pe cele care au fost unificate in mod automat de catre sistem.

Normalizarea

Se refera la curatarea datelor si rezolvarea conflictelor intre atributele informatiei pentru a se conforma standardelor de guvernanta a calitatii datelor. Aceste standarde acopera o gama larga de aspecte: geo-codare, capitalizare, codarea numerelor de telefon, unitati de masura, codificare EAN, etc. Procedurile de normalizare identifica aceste situatii si fie le corecteaza, fie resping tranzactia si declanseaza proceduri de escaladare.

Potrivirea (Matching)

Se refera la stabilirea legaturilor intre inregistrari care nu sunt conectate prin identificatori comuni, desi in realitate reprezinta aceeasi entitate fizica. In general potrivirea se realizeaza prin metode statistice; un algoritm probabilistic calculeaza doua tipuri de probabilitati conditionale pentru fiecare atribut ce intervine in criteriul de potrivire, apoi sunt stabilite pragurile de identificare a potentialelor duplicate. In cele din urma, comparand cele doua seturi de date rezulta trei grupuri: potrivirile certe, nepotrivirile certe si, undeva la mijloc intre primele doua, potentialele duplicate; acestea din urma trebuie investigate si rezolvate manual de catre operatorii de date.

Eliminarea duplicatelor

Se refera la fragmentarea ce apare atunci cand doua inregistrari sunt accidental create pentru aceeasi entitate reala. Odata ce algoritmul de potrivire a identificat duplicatele si a efectuat unificarea in indexul principal, sistemul MDM informeaza aplicatiile participante ca entitatile trebuie unificate si in bazele lor de date. Comunicarea se realizeaza fie prin tranzactii electronice, pentru aplicatiile care inteleg astfel de tranzactii, fie prin executia anumitor procese (workflow) in celelalte cazuri.

Agregarea surselor eterogene (Data Mashup)

Sursele eterogene de date din interiorul sau exteriorul organizatiei sunt integrate intr-un spatiu virtual unic oferit ca si serviciu prin semanticile standard (WSDL, REST, SOAP, etc). Acest spatiu virtual, bazat pe interfete publice (API), Servicii Web, motoare de cautare si altele, aduce impreuna informatii diferite, in diverse formate, le creste valoarea prin executarea unor activitati preconfigurate si le expune in cele din urma ca si punct unic de acces oferind un punct de vedere integrat asupra datelor master.

Fazele unui proiect MDM

Un plan de proiect MDM trebuie sa tina cont de cerinte, prioritati, interval de timp si amploarea problemei. Planul de proiect ar trebui sa contina cel putin urmatoarele faze:

• Identificarea surselor de date master. Acest prim pas poate oferi multe surprize, multe organizatii ar putea descoperi ca au baze de date de care departamentul IT nici nu avea idee;
• Identificarea producatorilor si consumatorilor de date master. Sunt identificate aplicatiile care produc si care utilizeaza date master;
• Colectarea si analizarea metadatelor aferente datelor master. Pentru toate sursele identificate in primul pas se analizeaza atributele entitatilor: nume, tip de date, valori permise, valori implicite, dependente, care este sistemul responsabil pentru definitia si intretinerea datelor. Daca exista un catalog (repository) deja incarcat cu toate acestea atunci acest pas nu este o sarcina dificila. Daca insa trebuie sa incepeti cu tabelele din bazele de date sau codul sursa al aplicatiilor, atunci efortul poate fi semnificativ;
• Identificarea operatorilor de date. Acestia trebuie sa cunoasca sursele curente de date si sa aiba abilitatea de a transforma datele din formatul sursa in formatul datelor master. Operatorii de date trebuie cautati printre proprietarii surselor de date, arhitectii de sisteme MDM sau utilizatori reprezentativi din business care folosesc datele master;
• Implementarea unui program si a unui comitet de guvernanta a datelor. Acest comitet trebuie sa aiba cunostintele si autoritatea de decizie asupra continutului, intretinerii, duratei de viata, modului de autorizare a modificarilor si auditului. Sute de decizii de acest gen trebuie luate pe parcursul unui asemenea proiect si, daca nu exista un astfel de comitet bine definit, proiectul poate esua deoarece politica adeseori impiedica luarea de decizii ferme;
• Dezvoltarea modelului datelor master. Trebuie decis cum vor arata inregistrarile datelor master: ce atribute sunt incluse, ce marime si tip de date, care sunt valorile permise, etc. Acest pas ar trebui sa includa si maparea intre modelul datelor master si sursele de date curente. Acesta este cel mai important si dificil pas in proiect. Daca incercati sa ii faceti fericiti pe toti incluzand in modelul de date toate atributele existente in sursele de date veti sfarsi prin a proiecta un model de date prea complex si alambicat pentru a fi utilizabil. Ca in orice comitet, vor exista dezacorduri sau intelegeri care vor conduce la decizii nu intotdeauna optime. Pentru a minimiza acest efect comitetul trebuie sa se focalizeze pe lucrurile cu adevarat prioritare si sa se consulte din timp cu factorul de decizie final;
• Alegerea platformei. Va trebui achizitionata sau construita platforma pentru managementul listelor de date master prin curatarea, transformarea si fuzionarea datelor sursa. Dintre categoriile principale de platforme amintim CDI (Customer Data Integration) si PIM (Product Information Management). Platforma aleasa trebuie sa ofere suport pentru identificarea si rezolvarea problemelor de calitate, de versionare sau ierarhizare a datelor. Versionarea este o functionalitate critica intrucat intelegerea istoricului unei inregistrari este vitala in mentinerea calitatii si acuratetei in timp;
• Design si infrastructura. Odata ce dispuneti de un set de date curat si consistent este necesar sa il expuneti aplicatiilor si sa implementati procesele care il vor gestiona si intretine. Acest pas este cel mai complex din perspectiva tehnologica; vor exista aplicatii a caror disponibilitate va depinde de infrastrucura astfel ca robustetea si scalabilitatea sunt considerente importante ce trebuie incluse in design;
• Generarea si testarea datelor master. In acest pas veti utiliza platforma achizitionata sau construita pentru a fuziona datele sursa in listele de date master. Este, de regula, un proces iterativ ce presupune ajustari ale configurarilor si regulilor, inspectarea manuala a datelor pentru a va asigura ca rezultatele indeplinesc specificatiile si conditiile de calitate impuse de proiect. Niciun instrument nu va identifica potrivirile corecte in proportie de 100% astfel ca va trebui pusa in balanta generarea de potriviri false cu ratarea potrivirilor corecte, pentru a stabili configurarile optime ale instrumentelor. Un set de configurari permisive conduce la un grad ridicat de potriviri si, inevitabil, la cresterea procentului de potriviri false (erori). Acestea pot conduce la scaderea gradului de satisfactie a clientilor, daca facturile sunt incorecte sau este livrat alt produs decat cel comandat. Pe de alta parte, un set de configurari prea restrictiv conduce la ratarea multor potriviri, ceea ce conduce la scaderea beneficiilor asteptate de la solutia MDM;
• Modificarea sistemelor producatoare si consumatoare de date master. In functie de designul solutiei MDM ar putea fi necesara modificarea sistemelor care produc, intretin sau consuma date master pentru a interactiona cu noile surse de date master. Daca datele master sunt utilizate doar intr-un sistem separat de sistemele sursa – de exemplu un datawarehouse – atunci sistemele sursa ar putea sa ramana nemodificate. Insa daca sistemele sursa vor accesa date master atunci probabil vor fi necesare modificari ale acestora. Fie sistemele sursa vor trebui sa acceseze noile date master, fie datele master vor trebui sincronizate cu sistemele sursa astfel sistemele sursa sa aiba o copie de lucru curata a datelor master. In situatia in care modificarea unui sistem sursa, pentru a putea consuma noile date master, nu este posibila, solutia consta in integrarea datelor master cu respectivul sistem prin procese externe de genul BPM (Business Processes Managament) sau prin integrare directa la nivelul bazelor de date prin mecanisme SQL (triggers). Sistemele sursa care genereaza inregistrari noi trebuie modificate pentru a cauta intai eventualele inregistrari existente in indexul principal al datelor master si abia apoi se ia decizia asupra crearii sau modificarii acestora; se asigura astfel o buna calitate datelor generate pe fluxul ascendent, de la sistemele sursa catre sistemul MDM. MDM trebuie implementat nu doar ca un sistem de inregistrari, ci ca un serviciu care promoveaza o gestionare mai eficienta a datelor intre aplicatiile unei organizatii. Toate cele trei directii principale in managementul datelor – originea, gestionarea si consumul – trebuie avute in vedere pentru o strategie MDM robusta la nivelul intregii organizatii;

• Implementarea proceselor de intretinere. Business-ul evolueaza, cerintele si conditiile se modifica permanent astfel ca implementarea MDM trebuie sa cuprinda instrumentele, procesele si oamenii care sa asigure permanent mentinerea calitatii datelor. Datele master trebuie sa aiba asociate operatori de date responsabili cu asigurarea calitatii. Instrumentele utilizate de acestia trebuie in permanenta actualizate si recalibrate pentru a permite recunoasterea noilor tipuri de probleme si rezolvarea acestora. Procesele prin care sistemul MDM se modifica si se extinde prin incorporarea a noi surse de date sau deservirea de noi aplicatii la nivelul intregii organizatii, trebuie de asemenea luate in considerare in strategia de intretinere a sistemului.

Beneficiile MDM

Printre beneficiile aduse de o implementare MDM reusita amintim:

• Imbunatatirea calitatii datelor;
• O mai buna cunoastere a clientilor;
• Cresterea calitatii serviciilor;
• Raportare consistenta;
• Imbunatatirea managementul riscurilor;
• Cresterea eficientei operationale si reducerea costurilor;
• Conformitate in raport cu reglementarile (Sarbanes-Oxley, Basel II);
• Simplificarea dezvoltarii aplicatiilor.

Concluzie

Dupa cum se vede, MDM este un proces complex si de durata. Cheia succesului consta in implementarea incrementala astfel ca business-ul sa inregistreze o serie de beneficii pe termen scurt in timp ce proiectul complet este un proces de lunga durata. Se poate cadea usor in capcana abordarii tehnologice, in care MDM este privit din perspectiva strict tehnica si tinand exclusiv de apanajul departamentelor IT; adevarul este insa ca, fara sprijinul si participarea utilizatorilor din business, fara programe de guvernanta a datelor asumate la cel mai inalt nivel in organizatie, sansele de reusita ale unui astfel de proiect sunt foarte mici.