ANÁLISE DA PESQUISA: O perfil das empresas brasileiras em ... · Governança de dados ... Gestão de Data Warehousing e BI Gestão de Documentos e conteúdo Gestão de Metadados

1

ANÁLISE DA PESQUISA: O perfil das empresas brasileiras em gestão e governança de dados

2


ANÁLISE DA PESQUISA:

O perfil das empresas brasileiras em

gestão e governança de dados

Carlos Barbieri

Com colaboração de Fernanda Farinelli

Belo Horizonte

Janeiro de 2013

Versão 02

3


FICHA TÉCNICA

Autor

Carlos Barbieri

Colaboração

Fernanda Farinelli (PRODEMGE)

Equipe técnica

Isabella Fonseca (FUMSOFT)

Claudio Filardi (FUMSOFT)

Evilene Santos (FUMSOFT)

Editoração

Pedro Ivo Brandão (FUMSOFT)

Renata Ferreira (FUMSOFT)

Projeto gráfico

Gracielle Santos (FUMSOFT)

FUMSOFT

Presidência

Thiago Turchetti Maia

Vice-presidência

Leonardo Fares Menhem

As informações contidas neste trabalho podem ser reproduzidas desde que citada a fonte.

Outras informações podem ser obtidas pelo e-mail [email protected]

Fumsoft

Av. Afonso Pena, 4.000, 3º andar - bairro Cruzeiro

CEP: 30.130-009 - Belo Horizonte/MG

Tel.: (31) 3281-1148

www.fumsoft.org.br

Barbieri, Carlos.

Análise da pesquisa: o perfil das empresas brasileiras em gestão e

governança de dados. Fumsoft - Belo Horizonte, 2013.

4


SUMÁRIO

1. INTRODUÇÃO ..................................................................................................................... 5

2. GESTÃO DE DADOS ............................................................................................................ 6

3. ANÁLISE DOS RESULTADOS ............................................................................................... 8

3.1. Características das empresas respondentes .................................................................. 8

3.1.1. Perfil das empresas ...................................................................................................... 8

3.1.2. Número de empregados .............................................................................................. 9

3.1.3. Natureza das empresas ................................................................................................ 9

3.1.4. Localização Geográfica ............................................................................................... 10

3.1.5. Análise preliminar da amostra ................................................................................... 11

3.2. Governança de dados ................................................................................................... 12

3.2.1. Planejamento de Gestão de Dados ........................................................................... 12

3.2.2. Controle da Gestão de Dados .................................................................................... 18

3.3. Gestão da arquitetura de dados ................................................................................... 21

3.4. Desenvolvimento de dados .......................................................................................... 25

3.5. Gestão de operações de dados .................................................................................... 29

3.6. Gestão de segurança de dados ..................................................................................... 33

3.7. Gestão de dados mestre e de referência ..................................................................... 36

3.8. Gestão de Data Warehousing e Business Intelligence ................................................ 38

3.9. Gestão de documentos e conteúdo ............................................................................. 40

3.10. Gestão de metadados ................................................................................................... 43

3.11. Gestão da qualidade de dados ..................................................................................... 45

3.12. Ferramentas de apoio a Gestão de Dados ................................................................... 47

4. REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................... 50

5


1. INTRODUÇÃO

Neste estudo, é realizada uma análise da pesquisa realizada pela Dama-BR e Fumsoft, com o

objetivo de mapear o posicionamento das empresas com relação à Gestão e Governança de

Dados. A pesquisa foi realizada durante os meses de outubro e novembro de 2012, período

em que foi disponibilizado um questionário on-line. Este foi preenchido por empresas

convidadas pelas instituições realizadoras, sem nenhuma limitação prévia de tamanho, ramo

de atividade, faturamento ou número de colaboradores. A ideia foi buscar a primeira

impressão da Governança de Dados no Brasil, visto que tais dados nunca haviam sido

levantados no país em uma pesquisa quantitativa como esta. Foram obtidas 76 respostas

completas e seus resultados, na forma de tabelas e gráficos, estão disponibilizados nos sites

da Dama-BR e Fumsoft.

Como o conceito de Gestão e Governança de dados é ainda relativamente novo e os dados

da pesquisa não são estatisticamente maduros, ressalta-se que as considerações aqui

apresentadas são uma percepção pessoal do autor, sem qualquer intenção de desenvolver

teses e estabelecer parâmetros definitivos sobre a forma com que as empresas praticam a

Gestão e Governança de Dados no Brasil. A ideia é estabelecer alguns pontos iniciais de

discussão, que possam ser aprofundados em estudos subsequentes e sirvam também para

que a área acadêmica e a indústria da consultoria balizem suas ações neste campo.

Alguns processos do Data Management Book of Knowledge (DMBOK – Corpo de

conhecimento da Dama sobre Governança de Dados) foram analisados de maneira geral,

pelas respostas, sem se ater aos detalhes de suas atividades. Outros foram analisados com

maior foco, considerando as respostas dadas para cada uma de suas atividades. Para facilitar

o entendimento da interpretação dos dados, serão apresentados no próximo tópico os

conceitos sintetizados pertinentes àquele corpo de conhecimento do DMBOK antes dos

resultados coletados e discutidos. Para aqueles que têm interesse em conhecer um pouco

mais a fundo estes conceitos e outras premissas do DMBOK, que nortearam a pesquisa e

esta análise, a Fumsoft disponibiliza em sua página eletrônica uma visão sintética e

comentada do documento, também elaborada pelo autor. Este artigo pode ser acessado em:

http://www.fumsoft.org.br/comunica/arquivos/uma_visao_sintetica_e_comentada_do_dm

bok_fumsoft_carlos_barbieri.pdf

http://www.fumsoft.org.br/comunica/arquivos/uma_visao_sintetica_e_comentada_do_dmbok_fumsoft_carlos_barbieri.pdf

http://www.fumsoft.org.br/comunica/arquivos/uma_visao_sintetica_e_comentada_do_dmbok_fumsoft_carlos_barbieri.pdf

6


2. GESTÃO DE DADOS

A Gestão de Dados (no inglês, Data Management ou DM), conforme o DMBOK (2009), visa

controlar e alavancar eficazmente o uso dos ativos dados e sua missão e objetivos são

atender e exceder às necessidades de informação de todos os envolvidos (stakeholders) da

empresa em termos de disponibilidade, segurança e qualidade. É uma responsabilidade

tanto da tecnologia da informação de uma empresa quanto de seus clientes internos e

externos e envolve desde a alta direção, que utiliza dados na geração de informações

estratégicas, até profissionais de nível operacional, que muitas vezes são responsáveis pela

coleta e produção dos dados.

O DMBOK (2009) estrutura o processo de DM por meio de funções e atividades e está

distribuído por dez áreas de conhecimento, conforme apresentado na Figura 1:

Figura 1 - Áreas de conhecimento na Gestão de Dados

Governança de dados

Gerência da Arquitetura de dados

Desenvolvimento de dados

Gestão de operações de bancos de dados

Gestão de Segurança de dados

7


Gestão de Dados mestres e de Referência

Gestão de Data Warehousing e BI

Gestão de Documentos e conteúdo

Gestão de Metadados

Gestão de Qualidade de dados

A pesquisa foi elaborada tomando como base as 10 áreas de conhecimento do processo de

DM propostos pelo DMBOK, com alguns desdobramentos entre os processos ou corpos de

conhecimentos. A exceção foi a parte relativa à Segurança de Dados, onde as proposições do

COBIT foram consideradas. Também foram feitas considerações sobre o Framework

Zachman e arquitetura TOGAF no capítulo relativo à Arquitetura de Dados.

8


3. ANÁLISE DOS RESULTADOS

3.1. Características das empresas respondentes

3.1.1. Perfil das empresas

Das empresas respondentes, conforme apresentado no Gráfico 1, 38,5% são de grande

porte, com faturamento bruto anual maior que R$300 milhões; 33,3% são microempresas,

com faturamento menor ou igual a R$2,4 milhões; 10,3% são pequenas empresas, com

faturamento entre R$2,4 e R$16 milhões; 6,4% são empresas médias com faturamento entre

R$16 milhões e R$90 milhões e outros 6,4% não se enquadram em nenhum dos perfis

mencionados.

Gráfico 1 – Porte das empresas participantes

9


3.1.2. Número de empregados

Segundo o Gráfico 2, observa-se que as empresas da esfera de comércio e serviços com mais

de 100 colaboradores representam 38,5% das participantes, enquanto 19,2% são

microempresas da mesma área, com até nove empregados; 15,4% são empresas da área de

indústria, com mais de 500 colaboradores; 9% das empresas são de porte pequeno, da área

de comércio e serviços, com quadro entre 10 e 49 colaboradores; 7,7% são microempresas,

da área da indústria com até 19 empregados; 5,1% das empresas são de porte médio, do

segmento da indústria, com quadro entre 100 e 499 empregados; 3,8% são de empresas de

médio porte do segmento do comércio e indústria, com quadro entre 50 e 99 colaboradores

e 1,3% são de empresas pequenas, do segmento indústria, com quadro entre 20 e 99

colaboradores.

Gráfico 2 – Tamanho das empresas participantes quanto ao número de empregados

3.1.3. Natureza das empresas

Ao verificar as empresas participantes quanto a forma jurídica (Gráfico 3) observa-se que as

empresas privadas representam 71,8% das respondentes; as públicas, 15,4% e as de

natureza mista são 12,8%.

10


Gráfico 3 – Natureza Jurídica das empresas participantes

3.1.4. Localização Geográfica

Conforme apresentado no Gráfico 4, percebe-se a participação de empresas distribuídas em

nove estados do Brasil (considerando como referência a sede), sendo 42,3% de Minas

Gerais, 23,1% de São Paulo, 14,1% do Rio de Janeiro, 14,1% do Distrito Federal e Rio Grande

do Sul, Santa Catarina, Paraná, Bahia e Alagoas com 1,3% cada.

11


Gráfico 4 – Localização geográfica das empresas participantes

3.1.5. Análise preliminar da amostra

Como a pesquisa é inédita e seu objetivo era obter a primeira fotografia da situação da

Gestão de Dados no Brasil, não houve preocupação com a escolha técnica da amostra, do

ponto de vista estatístico. Dessa forma, a amostra apresenta uma variedade de empresas de

atributos diferentes (porte, número de colaboradores, natureza), fator que precisa ser

considerado quando das análises dos resultados, pois os conceitos de Gestão de Dados ainda

são novos e a probabilidade é que se encontre maior maturidade (ou seja, as melhores

práticas DMBOK aplicadas) em empresas com maior estrutura organizacional. Cabe ressaltar

que quase 43% das empresas respondentes são classificadas como micro e pequenas

empresas.

Além disso, empresas com áreas de atuação diferentes também podem ter comportamento

diferente com relação aos dados. Por exemplo, empresas do ramo financeiro, sujeitas a

maior regulamentação ou empresas que processam dados com objetivos diretos de negócios

também tendem a ter uma percepção diferente da importância dos dados nos seus

resultados. Por outro lado, empresas que prestam serviços de desenvolvimento de software

estão nesse momento, com os olhos mais voltados para a qualidade de seus processos do

12


que dos seus dados. Isso, obviamente, não é uma constatação científica, mas é uma

percepção colhida nas quase 80 empresas onde a Fumsoft desenvolveu projetos de melhoria

de qualidade de processos.

Embora a pesquisa tenha capturado números transformados em percentuais, não é razoável

a suposição de que a amostragem realizada represente estatisticamente as empresas do

mercado brasileiro e a sua forma de tratamento de dados. De qualquer forma, a pesquisa se

revela muito valiosa por oferecer essa primeira imagem sobre gestão de dados e deve servir

para que abordagens mais focadas e análises mais apuradas sejam realizadas no futuro,

visando uma fotografia cada vez mais real e segmentada.

3.2. Governança de dados

A Governança de Dados (GD) representa o exercício da autoridade e controle (planejamento,

monitoração e aplicação ou “enforcement” de regras), procedimentos, políticas, etc.; sobre

os ativos de dados. A GD é uma abordagem de planejamento e controle de alto nível,

estabelecida sobre a gerência de dados em diversos ângulos. No conceito da DAMA, a

Governança de Dados é um dos corpos de conhecimento dentro do domínio maior de

Gestão de Dados. Seria aquele elemento central do qual irradiam as políticas, processos e

controles definidos sobre os ativos de dados, válidos e aplicados em todos os outros

processos. Para alguns autores essa diferença inexiste, podendo às vezes os conceitos serem

entendidos como sinônimos (Gestão e Governança).

Segundo o DMBOK (2009), a área de GD é dividida em atividades e subatividades,

representando a sua estrutura, em duas áreas: Planejamento da Gestão/Gerência de Dados

e Controle da Gestão/Gerência de Dados. A seguir, apresenta-se uma relação das

subatividades pertinentes a cada uma das atividades da GD seguida da análise dos

resultados de cada uma das perguntas relativas a essas atividades.

3.2.1. Planejamento de Gestão de Dados

As subatividades propostas pelo DMBOK (2009) para a atividade de planejamento de gestão

de dados são:

Entender as necessidades estratégicas de dados da empresa.

Desenvolver e manter a estratégia de dados para a empresa.

13


Definir os papéis e as organizações (estruturas corporativas) para tratar os dados

e sua gestão.

Identificar e nomear os gestores de dados (Data stewards).

Formalizar as unidades organizacionais para GD e Gestores de dados.

Revisar e aprovar a arquitetura de dados da empresa.

Planejar e apoiar (patrocinar) projetos e serviços no escopo de gerência de dados.

Estimar o valor dos ativos de dados e seus custos associados.

O Gráfico 5 abaixo, apresenta a situação das empresas participantes em relação à atividade

de planejamento de gestão de dados e suas subatividades.

Gráfico 5 - Atividades executadas atualmente quanto ao planejamento de gestão de dados

38%

40%

40%

27%

38%

32%

23%

15%

21%

13%

14%

12%

6%

9%

17%

6%

10%

8%

9%

4%

17%

18%

5%

5%

29%

37%

35%

54%

37%

40%

55%

72%

1%

3%

3%

4%

1%

1%

0%

1%

0% 20% 40% 60% 80%

Entendimento estratégico das necessidades de dados da

organização

Desenvolve e mantém uma estratégia de dados

Estabelece os papéis e as estruturas para a gestão de

dados

Identifica e designa gestores de dados (data stewards)

Desenvolve e aprova políticas, padrões e procedimentos de

dados

Revê e aprova a arquitetura de dados

Planeja e patrocina projetos e serviços de gestão de dados

Estima valores de ativos de dados e custos associados

A atividade é realizada

A atividade é realizada consistentemente entre as linhas de negócios

A atividade é realizada, monitorada e medida

A atividade não é realizada

Não Sei

14


Com relação ao Planejamento da Gestão de Dados ou Governança de Dados, o DMBOK

(2009) apresenta as seguintes considerações sobre a subatividade que trata o entendimento

estratégico sobre os dados:

Entendimento das necessidades de dados da empresa frente aos seus objetivos

estratégicos. Algo do tipo: Para onde vou em termos de negócios/estratégia,

como vou e que dados eu preciso para tal.

Políticas e diretrizes, atreladas a essa estratégia de dados e que direcionam a sua

utilização, definem a forma de integração de dados entre linhas de negócios,

alinham os modelos de dados com outros modelos na arquitetura corporativa,

regulamentam aspectos de segurança e privacidade, legislam sobre replicação e

qualidade de dados, resolvem pendências de dados, patrocinam e apoiam ações

corporativas, garantem aderência a normas reguladoras e dispõe de tratamento

sobre novas formas de dados (semi-estruturados, não-estruturados, Big Data,

etc).

Programas e Projetos (outros dois P´s da GD) que deverão ser pensados como

ações estruturadas/iniciativas para o alcance desses objetivos.

Na atividade “Entendimento estratégico das necessidades de dados da organização” ou,

numa releitura, entendimento da necessidade estratégica dos dados, observa-se que 29%

das empresas participantes da pesquisa não realizam essa atividade ou não tem essa

percepção e entendimento. Dos quase 70% que entendem 10% o fazem com maior

amplitude (realizam consistentemente entre linhas de negócios e monitoram e medem tais

atividades desse quesito). Outros quase 60% fazem consistentemente, porém sem

monitoração e medida (Gráfico 5). Esses números sugerem que as empresas, na sua maioria,

têm a percepção da importância estratégica dos dados. Isso é uma premissa válida, porém

nem sempre materializada na mesma proporção, conforme veremos a seguir.

Já em relação à atividade “Desenvolvimento e manutenção de uma estratégia de dados”, ou

seja, da concretização da percepção da necessidade acima demonstrada, observa-se que das

empresas pesquisadas, 37% não fazem nada, 21% fazem de forma consistente, monitorada e

medida e outros 40% fazem a atividade sem grandes controles (Gráfico 5). Observa-se uma

ligeira diferença entre os que entendem (no sentido de verem a importância de se ter uma

estratégia de dados) e os que efetivamente materializam essas estratégias (70% contra

61%). Ou seja, o desenvolvimento e manutenção de uma estratégia de dados é menor do

que os que entendem a sua necessidade. Esse número, inclusive poderá ser menor, quando

se detalhar o que o DMBOK define como ter uma efetiva estratégia de dados e as empresas

perceberem que isso é bem mais do que ter SGBD´s, DBA´s e AD’s, conforme discutido a

seguir.

15


Quando se analisa existência de estruturas e papéis definidos para a realização da estratégia

de dados, proposto pelo DMBOK (2009, p. 29) como uma atividade do planejamento da

gestão de dados, fica evidente que os papéis e estruturas variam de modelos adotados para

a GD, mas sempre gravitam em torno de uma camada com visão mais organizacional (comitê

supraorganizacional), uma camada tática que supervisiona as ações ao longo das áreas e os

gestores de dados nas áreas de negócios (data stewards) ou nas operacionais (data

custodians, ou DA, DBA, normalmente lotados na TI). O modelo do DMBOK oferece uma

variada gama de opções.

Assim sendo, conforme visto no Gráfico 5, um grupo de empresas em torno de 35% não tem

papéis e estruturas, um valor próximo dos que não têm nenhuma estratégia para dados,

flagrado no item anterior (37%). Um número relativamente expressivo de 63% afirmam ter

estruturas e papéis para a gestão de dados em algum grau, com 23% dizendo realizá-la com

amplitude entre linhas de negócios e com medição e monitoração (maior controle).

Esse número pode estar distorcido para cima e mereceria outra rodada futura, com uma

visão mais vertical para se capturar adequadamente a sua real fotografia. Um dos problemas

que pode gerar esses números elevados é a falta do pleno entendimento do que sejam

papéis e estruturas para a gestão de dados. Por exemplo, a simples existência da figura de

AD (Administrador de dados) e do ABD (Administrador de Bancos de dados) na área da TI,

por si só, não caracteriza a existência da Gestão de Dados no sentido amplo colocado. É

fundamental a existência de camadas em níveis estratégicos e táticos para garantir a

funcionalidade operacional dos dados nas empresas, como Comitê ou Conselho de GD

(Gestão ou Governança de Dados), CDO (Chief Data Officer), DMO (Data Management

Office), uma espécie de coordenador dos gestores de dados, além da figura dos próprios

(gestores ou stewards). Não basta ter somente ABD e AD, é preciso que haja GD!

Segundo do o DMBOK (2009) em relação à atividade “Identifica e designa data stewards” o

que deseja-se observar é a existência de gestores de dados nas áreas de negócios, visto que

nas áreas de TI normalmente já há os AD´s e ABD´s, figuras associadas aos dados. Desta

forma, das empresas participantes, verifica-se a partir do gráfico 5 que 54% não tem a figura

de um data stewards ou data steward, enquanto 43% dizem possuir. Destes, somente 16%

dizem ter data stewards com consistência no seu papel, monitoração e medição, conforme

se espera desse role. Outros 27% dizem possuir o papel oficialmente (com designação),

porém sem aparente aprofundamento (sem integração entre linhas de negócios e sem

monitoração e medição das atividades). Esse número, na visão do autor desta análise, é mais

realista e serve de calibração para o número do quesito anterior, por sugerir que mais da

metade dos respondentes não tem ainda este papel designado.

16


Quanto à atividade “Desenvolve, aprova políticas, padrões e procedimentos de dados” a

visão do DMBOK (2009) refere-se à busca de uma instância maior, com uma visão

corporativa e com autoridade para definir certas regras de dados e que valem para a

organização. De novo, percebe-se um patamar elevado, com 62% dos respondentes afirmam

manter essa visão organizacional definidora e 37% afirmam não manter tal visão (Gráfico 5).

Tais números podem ser considerados elevados e pode-se ter aqui novamente aspectos de

entendimento sobre essa visão organizacional definidora de política, procedimentos e

padrões (três dos nove P´s) da GD. Outro fator a ser considerado também é o tipo de

empresa respondente da pesquisa. Empresas como Bureau de Serviços de Dados tendem a

ter uma estruturação mais sólida neste item em particular, pois os dados são os seus

insumos de negócios, o que não necessariamente acontece com empresas cujo core business

está em outro domínio.

A atividade “Revisa e aprova a arquitetura de dados” segundo o DMBOK (2009) significa o

quanto as empresas definem e mantém modelos corporativos de dados e outros níveis

relacionados à arquitetura. Envolve o trabalho dos arquitetos de dados em conjunto com

gestores de dados das áreas por assunto, tudo orquestrado por uma visão organizacional.

Deve ser desenvolvido, mantido e aprovado por instâncias superiores e estar em

consonância com os objetivos estratégicos da empresa. A arquitetura de dados, é claro,

deverá estar em sintonia com outras arquiteturas, como de tecnologia, de processos, de

sistemas e de negócios.

Para o desenvolvimento desta atividade, os resultados obtidos pela pesquisa (Gráfico 5),

mostram que 59% dizem ter esses cuidados com a revisão e aprovação da arquitetura de

dados, enquanto 40% dizem não realizar tais práticas. Ter quase 60% das empresas

praticando a arquitetura de dados, conforme indagado, pode ser uma fotografia real, mas

me parece também um pouco alto. De novo, é mais um ponto que merece observação

cuidadosa. Normalmente as empresas têm uma arquitetura de dados focada em sistemas,

mas não necessariamente integradas e nem conectadas com outros tipos de arquiteturas,

numa visão estratégica. Há modelos de dados, em variados níveis de abstração (uns mais

lógicos e outros mais próximos da implementação), porém, sempre com forte sabor de

solução para aquele sistema específico e não dentro de um espectro mais corporativo.

Já para a atividade “Planeja e patrocina projetos e serviços de gestão de dados”, o que se

deseja focar, conforme o DMBOK (2009) são as iniciativas, na forma de programas e

projetos, que alavanquem a GD. Passam por programas e projetos que estabeleçam uma

arquitetura de dados, de DW e BI, de MDM, de qualidade de dados, de controle de

17


metadados, etc. Esses projetos, como quaisquer implementações de processos, requerem

alterações significativas na cultura da empresa, além de estabelecimento de novas

estruturas e papéis. A receita básica é uma avaliação das condições atuais existentes

naquele domínio especifico e um ou mais planos de ação para o estabelecimento das novas

condições desejadas. É importante lembrar que um projeto dessa natureza deverá ser

conduzido pelos processos padrões de GPP (Gerência de Portfólio) e de GPR (Gerência de

Projetos) da empresa, como nos modelos MPS.BR e CMMI. Alguns projetos, de escopo

maior, como a implementação de ERP´s e de CRM deverão estar em consonância com as

iniciativas de dados. Normalmente, esses projetos são iniciativas encapsuladas e

transcorrem com gerências e ações paralelas às iniciativas de dados da empresa.

Os serviços de gestão de dados, a que se refere a questão, são os diretamente associados a

esses projetos e variam, por exemplo, da coordenação da governança de dados à

modelagem de dados e análise de qualidade, passando, por gerência de dados não

estruturados e de metadados, etc.

A resposta dada pelas empresas (Gráfico 5) foi que 45% delas dizem realizar essa atividade,

embora somente 5% o façam com a completude necessária (atividade realizada, monitorada

e medida). Por outro lado, 55% dos respondentes disseram não realizá-la, o que joga uma luz

mais realista nas ações efetivas de dados, quando confrontado com os números mais

otimistas citados acima.

Para o DMBOK (2009), a atividade “Estimam valores de ativos de dados e custos associados”,

sugere uma intenção de se levantar o quanto as empresas percebem os dados como ativos

(um dos “clichês” de 2012). Na realidade, os dados são considerados ativos intangíveis e já

há movimentos em direção a posicioná-los como um ativo para o qual se estabelece

valoração. Por meios diretos ou indiretos, as empresas tentam definir valores derivados do

seu uso e aplicação. Uma delas é estabelecer um consenso sobre uma percentagem de valor

com que os dados contribuem para um projeto, relativizado a outros tipos de recursos que o

integram. Outra forma é pelo custo negativo que a sua baixa qualidade pode produzir, ou

pelos impactos negativos na reputação decorrentes dela (impactos pela baixa qualidade).

Outra forma é tentar estimar o quanto os concorrentes pagariam por aquele acervo de

dados existente. De toda a forma, essa prática é de baixo uso e o seu conceito ainda não

está maduro.

A valoração dos dados como “ativo” se reflete claramente nas respostas apresentadas n

Gráfico 5, onde dos participantes, 72% dizem não realizar a atividade e 27% dizem fazê-la.

Destes, somente 5% declaram ter a atividade feita na completude desejada. Muito

provavelmente essas empresas (entre 3 e 4, que representam 5% de quase 80 questionários

completados) são empresas que atuam no segmento de business de dados (bureau de

18


dados), onde a valoração dos dados, no caso seu insumo maior, é um fator crítico de sucesso

do seu negócio.

3.2.2. Controle da Gestão de Dados

As subatividades propostas pelo DMBOK (2009) para a atividade de controle de gestão de

dados são:

Supervisionar as unidades organizacionais e pessoas (staff) definidas para as

funções de Gerência de Dados.

Coordenar as atividades de Governança de Dados.

Gerenciar e resolver pendências relacionadas aos aspectos de dados.

Monitorar e garantir as aderências às normas regulatórias de dados.

Monitorar e garantir as conformidades com relação a Políticas, Padrões e

Arquiteturas de Dados.

Supervisionar os projetos e serviços relacionados à Gerência de Dados.

Comunicar e promover o valor dos ativos de dados da empresa.

Com relação ao Controle da Gestão de Dados ou Governança de dados, foram observadas as

seguintes tendências, evidenciadas no Gráfico 6 como as empresas participantes se

apresentam nesta atividade:

19


Gráfico 6 - Atividades executadas atualmente quanto ao controle da gestão de dados

Com relação a atividade “Supervisiona as unidades organizacionais e pessoas (staff)

definidas para as funções de GD” das empresas respondentes, 55% afirmaram desenvolver

essa atividade de supervisão sobre as áreas e pessoas envolvidas com as atividades de GD. O

número pode estar está um pouco elevado considerando o percentual de respostas que

aponta ter a figura designada de gestores de dados (fundamentais nas funções de GD), ou

seja, de 42% (Gráfico 6).

Em relação à atividade “Coordena as atividades de Governança de dados”, 53% dos

respondentes afirmam que tem ações de coordenação de atividades de GD. Por outro lado,

45% afirmam não ter ações de coordenação sobre essas atividades (Gráfico 6). Isso sugere

uma observação cuidadosa, indicando que pode haver atividades de GD sendo

desenvolvidas, como identificadas no gráfico 5, por exemplo, onde 61% desenvolvem,

aprovam políticas, padrões e procedimentos e com 59% revendo e aprovando arquitetura de

dados, sem a devida coordenação.

36%

35%

51%

31%

28%

31%

21%

10%

12%

10%

13%

12%

9%

5%

9%

6%

9%

13%

17%

8%

4%

44%

45%

27%

38%

44%

51%

64%

1%

3%

3%

5%

0%

1%

6%

0% 10% 20% 30% 40% 50% 60% 70%

Supervisiona as áreas com profissionais de dados e apoio

(staff)

Coordena atividades de governança de dados

Gerencia e resolve questões associadas a dados

Monitora e garante conformidade regulatória

Monitora e garante conformidade com políticas, padrões e

arquitetura de dados

Supervisiona projetos e serviços de gestão de dados

Comunica e promove o valor dos ativos de dados





Não Sei

20


Já para a atividade “Gerencia e resolve pendências (questões) relativas a dados” segundo o

DMBOK (2009) a intenção desta atividade é a resolução de impasses e conflitos (issues) de

dados, como por exemplo, choques no compartilhamento de dados ou divergências sobre

aspectos de segurança. Uma das principais atividades da GD é justamente a atuação sobre

esses pontos de impasses e conflitos. Dos respondentes, de acordo com o gráfico 6, 70%

apontam ter atividades para a resolução de pendências de dados, enquanto 27% sustentam

não tê-las. De todas as atividades de GD citadas nesse corpo de conhecimento de

Governança de Dados, o DMBOK, esta atividade foi a de maior valor. O ponto a ser pensado

aqui é se essas soluções estão sendo encaminhadas por uma área de GD ou se são soluções

obtidas de forma descentralizada.

Para a atividade “Monitora e garante conformidade com normas regulatórias” 57% das

empresas indicaram ter atividades para tal e 38% indicaram não realizá-la. Isso, obviamente,

depende do tipo de organização e do grau de controle externo a que ela está submetida. As

organizações do ramo financeiro, bancário e de seguros, serviços públicos, etc., na visão do

autor, normalmente possuem esses tipos de obrigações regulatórias e compuseram cerca de

35% das respondentes (Gráfico 6).

Conforme o DMBOK (2009), outra atividade de monitoramento “Monitora e garante

conformidade com políticas, padrões e arquitetura” a GD é vista como o Legislativo e

Judiciário de dados de uma empresa, devendo, dessa forma, garantir que as regras definidas

para esses ativos sejam respeitadas. Neste ponto, observa-se no gráfico 6 que 57% dos

respondentes julgam atuar garantindo o cumprimento das regras enquanto 44% julgam não

executar essa atividade. Assim, quase a metade (44%) dos pesquisados declaram não ter

nenhuma atividade de controle sobre as políticas, padrões e arquiteturas de dados, números

coerentes com as lacunas observadas nos quesitos anteriores.

Quanto à atividade “Supervisiona projetos e serviços de gestão de dados” o DMBOK (2009)

sugere também outro ponto importante da GD, que é a supervisão de projetos e serviços

associados a dados. Por exemplo, projetos de profiling nos dados, de implementação de

MDM (Master Data Management ou Gestão de Dados Mestre), ou de implementação de

gestão de segurança de dados estariam no arco de controle da GD. Neste quesito, 48%

disseram realizar a atividade, enquanto 51% apontam que não realizam essas atividades

(Gráfico 6). Essa percepção vem ao encontro do coeficiente anterior, mostrando que quase a

metade das respondentes não tem ações de GD no sentido de monitoração e supervisão de

dados.

21


Enfim, para a atividade “Comunica e promove o valor dos ativos de dados” a pesquisa tenta

observar com que grau a empresa comunica o valor dos ativos de dados que possui. Está

associado ao item anteriormente discutido do Planejamento de Gestão de Dados, analisado

no Gráfico 5, que indaga sobre o valor, traduzido em números ou em elementos

comparativos, que o acervo dos dados existentes representa. Essas duas questões tem a ver

com o “clichê” que sugere que os dados devem ser vistos como ativos da empresa ou que

certas organizações já buscam elencar os dados nos seus controles contábeis.

Segundo o Gráfico 6, somente 30% das empresas respondentes dizem ter essa atividade

realizada, enquanto que 64,1% não realizam e 6,4% dizem não saber acerca desse ponto. É

importante notar que esse aspecto é o que apresentou o maior índice de não realização

(64%), juntamente com o seu equivalente na parte de planejamento (Estima valores de

ativos de dados e custos associados), que apontou 72%. Em resumo: A cultura nas empresas

brasileiras ainda carece de amadurecimento no sentido de reconhecer os dados como

elementos de valor tangível, mensurável, contábil e visto como um ativo organizacional.

3.3. Gestão da arquitetura de dados

A Gestão da Arquitetura de Dados, de acordo com o DMBOK (2009), define as necessidades

de dados da empresa e projeta as estruturas mestres para atender essas necessidades. Inclui

o desenvolvimento e manutenção da arquitetura corporativa de dados, dentro do contexto

da arquitetura corporativa e suas conexões com as soluções implementadas via

sistemas/aplicações e os projetos que implementam esta arquitetura. A sua estrutura de

atividades é composta por:

Entender as necessidades de informação da empresa. Percebe-se aqui uma

variante com relação à outra já mencionada na função Governança de Dados. O

foco aqui é na necessidade de informações, ou seja algo mais elaborado e focado

em negócios e derivado do anterior “Entender as necessidades estratégicas de

dados”.

Desenvolver e manter o modelo corporativo de dados (MCD).

Analisar e alinhar o MCD com outros modelos de negócios.

Definir e manter uma arquitetura de tecnologia de Dados.

22


Definir e manter uma arquitetura de integração de dados.

Definir e manter uma arquitetura de DW (Data Warehousing) e de BI (Business

Intelligence).

Definir e manter uma taxonomia e padrões de nomes (namespaces) de dados

para a empresa.

Definir e manter uma arquitetura de metadados.

Ressalta-se que embora o modelo do DMBOK apresente o detalhamento acima, na pesquisa,

as perguntas foram simplificadas com a intenção de facilitar o entendimento do questionário

a ser preenchido.

Gráfico 7 – Atividades de gestão de arquitetura de dados realizadas atualmente

Com relação à gestão da Arquitetura de dados (baseado na proposta do TOGAF 9), o DMBOK

faz as seguintes considerações, evidenciadas no Gráfico 7:

Para o DMBOK (2009), a atividade “Entende as necessidades de informações da organização”

visa identificar a percepção que as empresas devem ter acerca das necessidades de

informação, do ponto de vista organizacional. No fundo, busca ver se as empresas percebem

38%

24%

27%

28%

17%

5%

8%

9%

3%

13%

5%

13%

32%

47%

53%

45%

10%

10%

8%

5%

0% 10% 20% 30% 40% 50% 60%

Entende as necessidades de informações da organização

Desenvolve e mantêm o modelo de dados

organizacional de alto nível/corporativo

Analisa e alinha o modelo de dados com outros modelos de

negócios

Revê e aprova modelo de dados da organização





Não sei

23


a necessidade dos dados para atender suas estratégias de negócios, desenvolvendo uma

visão unificada entre elementos vitais como dados, processos, negócios, sistemas,

tecnologia, etc.

A arquitetura TOGAF 9 é uma das proposições para arquitetura corporativa, que visa a

definição de uma visão integrada entre informática e negócios. Esse conceito de arquitetura

corporativa nasceu em 1989, numa publicação da IBM, quando Zachman sugeriu algo para

socorrer a área de Informática, que cada vez mais não conseguia se acoplar e apoiar com

rapidez os movimentos de negócios da empresa. Dessa proposição de Zachman nasceram

outras, dentre elas o TOGAF 9. A proposição TOGAF 9 é uma das alternativas para essa

adoção de arquitetura corporativa e juntamente com a arquitetura de Zachman e do Gartner

Group (adquirido do Meta Group), formam as referências existentes para uma empresa que

deseja a sua criação. Nesse caso, a questão está direcionada para essa percepção de

entendimento do posicionamento estratégico da informação à luz da arquitetura

corporativa.

Os resultados coletados apresentados no Gráfico 7 foram que 58% das empresas disseram

sim e 32% disseram não. A incidência de quase 60% das empresas que responderam

afirmativamente pode ser um indicativo de que a percepção está amplificada e que a

resposta indique que as necessidades de informação da empresa tenham sido desvinculadas

de uma arquitetura maior, conforme a proposição da questão central.

No que tange a atividade “Desenvolve e mantém o modelo de dados organizacional de alto

nível/visão corporativa” o DMBOK vai ao cerne da questão. Das respondentes, 42% disseram

sim e 47% disseram não realizam a atividade, além de um dos mais altos níveis da opção

“não sei”, de 10%. Os quase 60% desse item se contrapõem com os quase 60% do item

anterior, indicando que talvez esta percepção seja mais realista do que aquela. (Gráfico 7).

Na atividade “Analisa e alinha o modelo de dados com outros modelos de negócios” As

respostas foram 40% para sim e 53% para não, com 8% não sabendo sobre o quesito. O valor

está coerente com quase 60% do item anterior. (Gráfico 7). E em relação à atividade “Revê e

aprova modelo de dados da organização” dos respondentes, 50% disseram que sim e 45%

disseram que não, com 5% não sabendo. Há um equilíbrio entre os que avaliam (revisam) e

aprovam os modelos de dados e os que não o fazem.

Neste ponto aparece uma dúvida. A pergunta é acerca dos modelos de dados

organizacionais, ou seja, um nível bem mais conceitual do que os que normalmente são

desenvolvidos, quase à imagem dos modelos relacionais. Seria esse o entendimento dos

respondentes? A percepção que se tem hoje acerca dessas práticas é a clara dificuldade de

24


se manter uma arquitetura integrada de dados com outras arquiteturas. A manutenção de

um modelo conceitual de dados integrado é um desafio na medida em que (quase) não há

regras e políticas que legislem sobre a proliferação ou criação “livre” de dados e tabelas. As

empresas tendem a ter essas arquiteturas definidas, porém separadas e sem laços entre

elas. Na camada de bancos de dados, nota-se uma interação tangencial como, por exemplo,

na aprovação de tabelas de bancos de dados demandadas pelas aplicações, à luz de um

modelo conceitual. Esse é o caso de algumas empresas, um pouco mais evoluídas, que

mantém um sincronismo entre o modelo conceitual dos dados com o modelo físico de BD,

atualizando-os num repositório de modelos. Ou seja, as preocupações com os dados

acontecem num momento bem distante de uma visão estratégica, já no momento da sua

materialização física. Isso pode explicar parte das respostas (50%) da pergunta D sobre

revisão e aprovação de modelos de dados. (Gráfico 7). A parte relativa a padrões de nomes

existe normalmente, mas há tendência de uma grande lacuna no domínio dos metadados.

O DMBOK (2009) sugere no seu corpo de conhecimento a criação de modelos de dados em

cinco níveis de abstração: O primeiro, em nível de assunto, com grandes entidades de

negócios (entre 20 e 30), com simplesmente a sua definição negocial, sem atributos ou com

pouco detalhamento. O segundo nível é formado por um nível um pouco mais detalhado,

com cerca de 150-300 entidades de negócios, derivadas daquelas grandes áreas (subject

areas). Num nível abaixo viriam às entidades do nível anterior, agora com atributos. No nível

de aplicativos, há duas abstrações: uma, com a visão do modelo lógico de dados e outra com

o modelo físico (Figura 2).

Figura 2 – Níveis do Modelo de Dados Corporativo

Fonte: DMBOK (2009, p. 75)

25


O Serviço Federal de Processamento de Dados (Serpro), uma das maiores empresas de

informática do Brasil e que processa dados para o Governo Federal, contatada pelo autor via

email na pessoa de Marcelo Alexandre Kill, está empreendendo um grande esforço no

sentido de criar e manter modelos conceituais de dados. Desenvolve um projeto iniciado em

2009, cujo objetivo é a criação de um Modelo Global de Dados (MGD). A empresa

desenvolve, via engenharia reversa, a criação de modelos conceituais, através dos modelos

físicos de tabelas. Os modelos separados nasceram de sistemas não integrados, cujo

desacoplamento compromete a eficiência da gestão. Isso gerou, entre outros, sistemas

setoriais com Bancos de Dados de Órgãos replicados. Mais detalhes estão disponibilizados

na página do Serpro, no link http://modeloglobaldados.serpro.gov.br/modelo-conceitual.

Esse será um dos grandes desafios da gestão estratégica de dados, visto que uma grande

massa de dados, estruturados ao longo de muitos anos, habita bases de dados desintegradas

e replicadas. Na minha visão, pouco se conseguirá fazer com relação a esse legado. As

soluções de gestão de dados deverão ser estabelecidas para serem trabalhadas na medida

em que novos sistemas forem desenvolvidos ou novos módulos de sistemas existentes

forem implementados. O problema está posto e neste caso, mexer no passado é quase

sempre traumático e pode comprometer a credibilidade das ações futuras de GD.

3.4. Desenvolvimento de dados

O Desenvolvimento de Dados consiste em projetar, implementar e manter soluções que

satisfaçam as necessidades de dados da empresa. Compreende as atividades focadas em

dados dentro do ciclo de desenvolvimento do sistema, incluindo a modelagem de dados,

análise de requisitos de dados e projeto, implantação e manutenção de bancos de dados.

(DMBOK 2009). Sua estrutura de atividades segue descrita abaixo:

Modelagem de dados, Análise e projeto de soluções:

• Analisar os requisitos de informação.

• Desenvolver e manter modelos conceituais de dados.

• Desenvolver e manter modelos lógicos de dados.

• Desenvolver e manter modelos físicos de dados.

Projeto detalhado de dados:

• Projetar (desenhar) os Bancos de Dados físicos.

26


• Projetar (desenhar) os produtos de informação necessários.

• Projetar (desenhar) os serviços de acesso aos dados.

• Projetar (desenhar) os serviços de integração de dados.

Gerência de qualidade dos modelos de dados e dos projetos derivados:

• Desenvolver padrões para modelagem de dados e projetos.

• Revisar(auditar) a qualidade dos modelos de dados e dos projetos de bancos

de dados.

• Gerenciar versionamento e integração de modelos de dados.

Implementação de dados:

• Implementar, desenvolver e testar alterações em bancos de dados.

• Criar e manter dados para ambientes de testes.

• Migrar e converter dados.

• Construir e testar produtos de informação.

• Construir e testar serviços de acesso a dados.

• Validar requisitos de informação.

O Gráfico 8 abaixo apresenta o resultado da pesquisa quanto as atividades de

desenvolvimento de dados.

27


Gráfico 8 - Atividades de desenvolvimento de dados executadas atualmente por profissionais de dados

Com relação ao Desenvolvimento de Dados, faz-se as seguintes considerações: Esse corpo de

conhecimento desce um pouco do patamar corporativo e atinge o nível de projetos de

desenvolvimento e sua preocupação com os dados consumidos naquele contexto (de

aplicativos). A percepção que se tem hoje acerca dessas funções é que, nesse segmento, há

46%

32%

40%

45%

49%

42%

50%

45%

36%

37%

44%

45%

42%

36%

38%

14%

9%

14%

15%

12%

12%

13%

12%

18%

12%

13%

6%

10%

9%

8%

26%

46%

31%

19%

14%

19%

18%

21%

28%

29%

18%

27%

19%

32%

47%

0%

0%

0%

0%

1%

4%

5%

6%

0%

3%

3%

3%

4%

8%

3%

0% 10% 20% 30% 40% 50% 60%

Analisa requisitos de informação

Desenvolve e mantém modelos conceituais de dados

Desenvolve e mantém modelos lógicos de dados

Desenvolve e mantém modelos físicos de dados

Desenvolve o projeto de banco de dados físico

Desenvolve o projeto de produtos e informações (telas e relatórios)

Desenvolve o projeto de serviços de acesso a dados (acesso físico de servidores

remotos) Desenvolve o projeto de serviços de

integração de dados (mensagens; mapeamento de ETL)

Desenvolve padrões para modelagem e projetos de dados

Revê a qualidade dos modelos de dados e dos projetos de Bancos de dados

Implementa mudanças em banco de dados por meio de ambientes de teste e

desenvolvimento

Cria e mantém dados para testes

Migra e converte dados

Constrói e testa produtos de informação

Prepara para implatação de dados para Data Deployment ( documentação e treinamento ao suporte de usuários)





Não sei

28


certo grau de desenvolvimento, incompleto, porém consistente. A parte de modelagem

conceitual, lógica e principalmente física de dados, voltada para aplicações, teve certo

desenvolvimento no Brasil. Nasceu da influência do crescimento dos SGBD´s e do

desenvolvimento do papel do DBA.

A parte de modelos é relativamente bem resolvida verticalmente, afora a integração

horizontal entre assuntos (Subject areas). Há modelagem conceitual (num certo grau), lógica

(num certo grau) e física (essa sim, com plenitude). As empresas menos maduras fazem

bancos de dados começando diretamente pelo modelo físico, mas já há certa consciência do

“furo” que isso representa.

No que tange a revisar (auditar) a qualidade dos modelos de dados e dos projetos de bancos

de dados, há lacunas significativas, bem como no gerenciamento e versionamento e

integração de modelos de dados. No que tange a testes, há também criação de ambientes

de BD de testes, com rotinas de conversão e preparação para deployment de BD em

ambientes de homologação ou de produção.

O resultado deste quesito mostra alguns aspectos interessantes, conforme gráfico 8.

Analisando este resultado, percebe-se que se for realizado um corte em 70% de respostas,

com viés positivo para as diversas questões, observa-se que as perguntas com indicadores

acima desse nível mostram aspectos mais consolidados de práticas sobre os dados, oriunda

das ações de bancos de dados físicos: analisa requisitos, desenvolve modelos "físicos",

desenvolve projetos "físicos" de BD, desenvolve produtos (leia-se relatórios), implementa

mudanças usando bancos de dados de testes, migra e converte dados, entre outros. Se o

corte for realizado em 80%, observa-se ainda mais intensamente esses aspectos de

tratamento físico dos dados (desenvolve e mantém modelos físicos, desenvolve projetos

físicos de bancos de dados).

Se, por outro lado, observamos a faixa abaixo de 70%, percebe-se que neste ponto estão

práticas no plano lógico, ou aspectos mais explícitos de qualidade e controle sobre os dados,

como desenvolver e manter modelos lógicos de dados, rever a qualidade dos modelos de

dados, construir e testar produtos de informação (algo relacionado com Verificação de

Qualidade - VER) e aspectos de implantação e documentação. Em resumo, esse corpo de

conhecimento (de desenvolvimento de dados) está com síndrome de “academia de

ginástica”: O foco principal é no aspecto físico.

29


3.5. Gestão de operações de dados

A gestão de operações de dados engloba planejar, controlar e apoiar os ativos de dados ao

longo do seu ciclo de vida, indo desde a criação e aquisição (obtenção) até o arquivamento

final (archiving) e eliminação (purge) (DMBOK, 2009). A estrutura de atividades é descrita

abaixo:

Suporte a Bancos de dados:

• Implementar e controlar ambientes de Bancos de Dados.

• Obter dados originados de fontes externas.

• Planejar para Recuperação de dados (Recovery).

• Realizar Backup e Recovery de Bancos de Dados.

• Estabelecer níveis de serviços relacionados à performance de Bancos de

dados.

• Monitorar e ajustar aspectos de performance de Bancos de Dados.

• Planejar a retenção de dados.

• Arquivar, reter e eliminar dados.

• Suportar aspectos de Bancos de Dados especializados.

Gerência de tecnologia de dados:

• Entender os requisitos tecnológicos de dados.

• Definir arquiteturas tecnológicas de dados, já mencionadas anteriormente na

função Gerência da Arquitetura de dados como “Definir e manter uma arquitetura de

Bancos de Dados”.

• Avaliar tecnologias de dados.

• Instalar e administrar tecnologias de dados.

• Controlar e acompanhar aspectos de licenças de tecnologia de dados.

• Suportar o uso e as dúvidas (pendências) sobre tecnologia de dados.

O resultado da pesquisa quanto as atividades de gestão de operações de dados foi

compilado no Gráfico 9 abaixo:

30


Gráfico 9 - Atividades de operações com dados executadas atualmente por profissionais de dados

Com relação à gestão de operações de dados, o DMBOK (2009) faz as seguintes

considerações:

Para a atividade “Adquire dados de fontes externas”, dos respondentes, 73% disseram que

sim, que adquirem dados de fontes externas. Por outro lado, 23% disseram não realizar essa

atividade. Esses números, apresentados no Gráfico 9, podem estar ligeiramente

amplificados, principalmente pelas empresas que usam os dados como centro do seu core

business. Empresas como bureau de serviços de dados têm, nesta atividade, o seu fator de

maior importância, coletando dados em fontes de informações oficiais e tratando-as, como

numa linha de produção, para oferecer aos seus clientes.

Quanto a atividade “Planeja a recuperação de dados” os resultados apresentados no Gráfico

9 contata que 89% dizem ter essa atividade e somente 9% declaram não tê-la. A minha

42%

53%

53%

31%

54%

50%

51%

47%

45%

12%

10%

12%

8%

10%

14%

12%

12%

12%

19%

26%

32%

28%

24%

19%

22%

21%

22%

23%

9%

3%

32%

10%

12%

13%

17%

15%

4%

3%

1%

1%

1%

5%

3%

4%

6%

0% 20% 40% 60%

Adquire dados de fontes externas

Planeja a recuperação de dados

Realiza Backup e Recovery (Recuperação) de Bancos de Dados

Define níveis de serviços relacionados a performance de banco de dados

Arquiva, retém, e elimina dados

Entende os requisitos de tecnologia de dados

Define a arquitetura tecnológicas de dados

Avalia tecnologias de dados

Controla o estoque e acompanha as licenças de tecnologia de dados





Não Sei

31


curiosidade é sobre os 9% que dizem não ter planejamento de recuperação de dados.

Tomara que eu não seja cliente delas.

Já em relação à atividade “Realiza backup e recovery de Bancos de Dados” 96% dos

respondentes realizam a atividade e somente 3% não a possuem (Gráfico 9). Essa,

seguramente, é uma das áreas de Gestão de Dados mais desenvolvida, pois está também

atrelada às funções de DBA. Há uma plena adoção de técnicas para backup/restore de BD,

até pelo aspecto crucial que isso representa. Costumava dizer, na minha época de ABD na

Cemig, que a backup é a presença de Deus na TI. Aqui, de novo a minha curiosidade é sobre

as 3% que não tem backup de seus bancos de dados! (Comentário do próprio autor).

Na atividade “Define níveis de serviços relacionados à performance de bancos de dados” 67%

dos respondentes dizem estabelecer SLA (service-level agreement) de performance,

enquanto 32% dizem não ter esses acordos (Gráfico 9). Aqui, também sugere-se uma

indicação maior do que a realidade, ou seja, que quase dois terços das empresas

estabelecem níveis de serviços com relação à performance de BD. Talvez a expressão dos

respondentes seja voltada para performance, de maneira geral, do ambiente. A definição de

SLA com relação à performance de Bancos de dados é algo que é difícil de ser estabelecido.

Simplesmente porque entre o clique de uma tecla numa interface web até o retorno dos

dados de uma ou mais tabelas, há diversas camadas de tecnologia de variadas gêneses

envolvidas e não somente a presença de um SGBD. Além disso, normalmente a monitoração

de performance em Bancos de Dados é reativa, ocorrendo quando “gargalos” acontecem.

Poucas empresas, creio eu, adotam monitoração sistemática de performance em BD,

independentemente de “incidentes” relatados. Com o crescimento dos modelos ITIL pode

haver uma tendência de crescimento real nesses números. Mas, para um entendimento

inicial desta pesquisa, optou-se por acreditar que esses números estejam corretos, para o

bem dos serviços de BD.

Para o DMBOK (2009) na atividade “Arquiva, retém e elimina dados”, entende-se que haja

um plano que define ações de arquivamento de dados (entendendo-se cópias, backups,

replicações, arquivos secundários, arquivos off-line, etc.). Também o plano deve definir

aspectos de tempo de retenção e de momentos ou ciclos de eliminação de dados. Os

números da pesquisa apresentados no Gráfico 9 indicam que 89% apontam ter planos para

tal e 10% indicam não tê-lo. O número aponta um bom índice de adoção dos conceitos.

32


Para a atividade “Entende os requisitos de tecnologia de dados” o DMBOK (2009) pretende

colocar as possibilidades de diferentes tipos de tecnologia de Bancos de Dados para atender

a variados objetivos. Isso deverá estar mais explicitado nas futuras versões do DMBOK. Por

exemplo, pode haver diferentes tecnologias de BD para atender Big Data (Netezza - IBM) ou

soluções Hadoop-MapReduce para volumes de petabytes, ou bancos de dados focados em

objetos para estruturas de dados mais complexas. As mudanças nesse patamar de

tecnologia de BD normalmente se dão por fatores financeiros ou por imperiosa necessidade

de novas estruturações (para mais informações veja sobre Hadoop, NOSQL, etc.), para

atender novos tipos de demandas. Os indicadores apontaram que 83% dos respondentes

entendem os requisitos de tecnologia, enquanto 12% dizem não possuí-la (Gráfico 9).

O DMBOK (2009) indaga sobre a avaliação da arquitetura tecnológica de dados na empresa

quando considera a atividade “Define a arquitetura tecnológica de dados”. No fundo, há

algumas arquiteturas de dados clássicas: os dados transacionais estabelecidos sobre uma

arquitetura relacional, com um SGBD dessa natureza e seus utilitários de apoio. Por outro

lado, há a arquitetura voltada para sistemas informacionais, com DW, ferramentas de BI e de

ETL. Na esfera da qualidade, há a arquitetura de ferramentas para profiling e limpeza dos

dados, além da camada de metadados. A pesquisa (Gráfico 9) apontou que 85% das

empresas tem definição sobre isso, enquanto 13% dizem não possuí-la. Entendo que sejam

números consistentes.

Já na atividade “Avalia a tecnologia de dados” o DMBOK (2009) se preocupa com o fato de

as empresas terem processos para a avaliação e seleção dessas tecnologias descritas

anteriormente. Um dos processos de nível 3 do CMMI e nível C do MPS.BR, (SOFTEX, 2009) é

justamente o GDE (Gerência de Decisões), que institucionaliza procedimentos para esses

tipos de escolhas tecnológicas, dentre outras. Dos respondentes, 79% disseram ter essa

preocupação e 17% afirmam não tê-la (Gráfico 9). Os processos de avaliação em empresas

sem processos formais para tal ocorrem baseados em critérios mais intuitivos, mas não

menos importantes, como custo, tipo de tecnologia, disponibilidade de mão de obra e de

treinamento, etc.

O DMBOK (2009) ressalta na atividade “Controla o estoque e acompanha as licenças de

tecnologias de dados” a preocupação com o controle de licenças e cópias dos produtos

relacionados com dados. Passa por auditorias periódicas e trabalhos de conscientização, a

fim de evitar riscos financeiros e legais, provenientes de usos indevidos de licenças de

ferramentas de dados, como SGBD´s, geradores de relatórios e cubos, camadas de ETL, etc.

33


Dos respondentes, 78% disseram possuir esse tipo de controle contra 15% que confirmaram

não possuir (Gráfico 9).

3.6. Gestão de segurança de dados

A Gestão de Segurança de dados (DMBOK, 2009) envolve planejar, desenvolver e executar as

políticas de segurança e procedimentos a fim de prover a adequada autenticação, acesso e

auditoria de dados e informações. Sua estrutura de atividades é descrita abaixo:

Entender as necessidades de segurança de dados e os requisitos regulatórios

associados.

Definir Política de segurança de dados.

Definir Padrões de segurança de dados.

Definir Procedimentos e controles de segurança de dados.

Gerenciar usuários, passwords e membros de grupos de usuários.

Gerenciar visões e permissões de acesso aos dados.

Monitorar autenticação de usuários e comportamento de acesso.

Classificar o grau de confidencialidade das informações.

Auditar a segurança dos dados.

A pesquisa realizada considerou parcialmente os aspectos de segurança do DMBOK, tendo

como centro as questões na linha sugerida pelo Control Objectives for Information and

Related Technology (Cobit). O Cobit é uma proposta mais focada em Governança de TI, mas

cuida de dados e informação como elemento fundamental e de risco para as organizações.

Muitas empresas que tem Sarbannes Oxley (SOX) se valem do framework Cobit. Os objetivos

de controle listados no processo Ensure Systems Security, dentro do domínio Delivery and

Support, definem os pontos fundamentais de segurança do modelo.

Nesse corpo de conhecimento, a pesquisa, compilada no gráfico 10, mostrou que esse

quesito foi o que mais apresentou viés positivo, comparando as atividades realizadas

(atividade é realizada, consistentemente entre as linhas de negócios e também com

monitoração e medida) com as não realizadas (Gráfico 10). Com exceção dos quesitos de

estabelecimento de um comitê de direção de segurança e de um grupo de aconselhamento

de segurança para políticas e revisões, todas as outras perguntas mostraram que a

realização das atividades vitais de segurança é maior do que a sua não realização. A

percepção da necessidade de segurança com 75% sim contra 21% não, a definição de

políticas de segurança com 72% sim contra 24% não, a definição de procedimentos para

responder a incidentes de segurança, com 61% sim a 32% não, a classificação da do grau de

34


confidencialidade da informação, com 68% sim a 28% não e a gerência de usuários, senhas,

grupos, etc, com 87% sim e 10% não, mostram que, conceitualmente, o assunto segurança

de dados é levado bem a sério nas empresas, embora sem a preocupação de aspectos de

governança, como a existência de um grupo ou comitê superior de aconselhamento que

defina e acompanhe o assunto.

35


Gráfico 10 - Atividades de gestão de segurança de dados executadas atualmente

45%

36%

29%

27%

29%

40%

45%

41%

50%

46%

31%

32%

36%

36%

31%

36%

45%

15%

17%

10%

6%

8%

5%

9%

13%

9%

9%

5%

6%

4%

6%

10%

5%

8%

15%

19%

22%

10%

6%

14%

9%

14%

28%

21%

23%

21%

21%

14%

12%

14%

19%

21%

24%

32%

49%

50%

33%

28%

28%

10%

19%

28%

28%

28%

31%

37%

37%

21%

4%

4%

6%

8%

6%

8%

9%

4%

3%

5%

13%

13%

12%

13%

10%

8%

8%

0% 20% 40% 60%

Entende as necessidades de segurança de dados e requisitos regulatórios

Define políticas de segurança de dados

Define procedimentos para responder e manusear incidentes de segurança

Estabelece comitê de direção para segurança de sistemas de informação

(gerenciamento executivo)

Estabelece grupo de aconselhamento em segurança de dados (Políticas e

Revisões de procedimentos)

Identifica administradores de segurança

Produz e mantém armazenamento de ativos de informações

Classifica a confidencialidade da informação incluíndo política de acesso

a informação

Gerencia usuários, senhas, e grupos de membros (identificação)

Gerencia visões e permissões de acesso a dados (autenticação por informação

de ativo)

Monitora periodicamente os direitos de autenticações de usuários

Previne/Gerencia super-usuários em dados de produção

Acompanhamento de violações de acesso via logs e relatórios

Gerencia a extração de dados privados/confidenciais

Previne/Gerencia dados privados/confidenciais em Laptops e

PDAs

Periodicamente audita a segurança de dados

Remove direitos de acesso em caso de rescisão contratual





Não sei

36


A conclusão é que essa, certamente, é uma das áreas de Gestão de Dados mais

desenvolvida, senão a mais. Os aspectos de segurança e riscos consequentes são

naturalmente entendidos pela alta gerência, pois o assunto é critico. Por isso, os aspectos de

segurança são bem implementados. Políticas, padrões, procedimentos e auditoria de

segurança são bem resolvidos de maneira geral nas empresas. Os “hackers” e a computação

doméstica prestaram um bom serviço nesse segmento, criando o conceito de necessidade

imperiosa de se ter controles sobre quem acessa “o quê”, “como”, “quando” e “por quê?”.

3.7. Gestão de dados mestre e de referência

Segundo o DMBOK (2009), a Gestão de Dados Mestres e de Referência se resume em

planejar, implementar e controlar atividades para garantir consistência de dados replicados

em diferentes contextos, com relação a uma versão “Golden” (única), também chamada de

verdade universal, que represente o dado na forma consistente, íntegra e confiável. A sua

estrutura de atividades é descrita abaixo:

Entender as necessidades de integração de dados Mestres e de Referência. Os dados

Mestres são os dados fundamentais de uma empresa e envolvem clientes,

fornecedores, colaboradores, contas, locais, entre outros. Os dados de Referência

estão relacionados a códigos, como estado, país, status de um pedido, Código

Internacional de Doenças (CID), códigos de procedimentos e tratamentos (CPT), entre

outros. Num pedido, por exemplo, que representa um dado do tipo transacional

(normalmente associado a uma data), existem dados Mestres (clientes e produtos

entregues, vendedor envolvido, entre outros), dados de Referência, como o status do

pedido, CEP padrão do fornecedor, etc., que no conjunto formam os dados

Transacionais do Pedido. Essa classificação de tipos de dados está mais detalhada

adiante.

Identificar as fontes de dados Mestres e de Referência e seus responsáveis e

envolvidos (contributors).

Definir e manter a arquitetura de integração de dados, já mencionada anteriormente

na função Gerência da Arquitetura de dados como “Definir e manter uma arquitetura

de integração de dados”.

Implementar soluções de gerência de Dados Mestres e de Referência.

Definir e manter regras de “match” para os dados replicados, ou seja, padrões para

que se possa identificar duas ocorrências como sendo do mesmo objeto. Por

exemplo: Dois registros de cliente com nome Carlos Barbieri podem ser considerados

o mesmo objeto (Carlos Barbieri)?

37


Definir os “Golden Records” (conceito de fonte única, integra e confiável, que

procura garantir a verdade sobre os dados). Por exemplo, um único cadastro lógico

de clientes, formado por informações advindas de várias fontes físicas.

Definir e manter hierarquias e afiliações (conceitos de MDM). As hierarquias e

afiliações complementam as informações de relacionamentos dos dados Mestres,

mostrando, por exemplo, dois registros mestres de clientes, relacionados como

Todo-Parte (um cliente é parte de outro cliente, ou seja, faz parte do mesmo grupo,

ou é afiliada; enfim, tem um relacionamento com a outra empresa). Também há o

relacionamento conhecido como “É um tipo de”. As duas classificações de dados são

muito aplicadas no conceito de objetos (Todo-Parte ou composição e agregação e “É

um tipo de”, definindo tipos e subtipos) adotados em Modelagem de Classes e

objetos.

Planejar e implementar integrações de novas fontes de dados.

Replicar e distribuir Dados Mestres e de Referência.

Gerenciar alterações de Dados Mestres e de Referência.

O resultado da pesquisa quanto as atividades de Gestão de dados mestre e de referência

foi compilado no Gráfico 9 abaixo:

Gráfico 11 - Atividades de gestão de dados mestres e de referência executadas atualmente

35%

19%

19%

26%

26%

13%

6%

6%

4%

5%

8%

8%

6%

8%

6%

37%

58%

59%

53%

54%

8%

9%

9%

10%

9%

0% 50% 100%

Entende as necessidades de integração dos dados mestres e

de referência

Define e mantém regras de Match Code (batimento)

Estabelece seus golden records (registros dourados)

Replica e distribui os dados mestres e de referência

Gerencia as mudanças dos dados mestres e de referência





Não sei

38


Se por um lado o corpo de conhecimento anterior (Segurança) foi um dos que apresentaram

maior viés positivo, essas práticas de MDM foram as que apresentaram os menores índices

de realização de atividades e também estão dentre os maiores indicadores de

desconhecimento. O indicador de desconhecimento pode ser interpretado nessa pesquisa

segundo duas óticas. O respondente “desconhece” o sentido central da pergunta ou

conhece do assunto, mas não tem certeza ou conhecimento da sua aplicação na empresa

(Gráfico 11). Em qualquer das duas linhas, esse ponto é relevante, pois a média das

percentagens da resposta “Não sei” foi 9%.

Nesse corpo de conhecimento, somente o entendimento das necessidades de integração de

dados mestres e de referência apresentaram um viés positivo (56% disseram que entendem

e 37% dizem não ter essa percepção de necessidade). Todas as outras questões tiveram um

viés negativo (o “não realiza” é maior do que as alternativas de implementação) conforme

evidenciado no Gráfico 11. Isso sugere que essa é uma das áreas com maior potencial de

crescimento dentro da gestão estratégica de dados.

Embora tenha nascido dentro do domínio de clientes, o conceito de MDM hoje já é visto

como ampliado para outros tipos de dados mestres. Veio para resolver algo que, em tese,

deveria ter sido resolvido pelas abordagens de Bancos de Dados. Com a proliferação dos

dados, tabelas e sistemas, o conceito ganhou força e exige procedimentos. Com o crescente

número de fusões e merges de empresas, o problema de duplicação de dados mestres se

amplificou. Esse processo tem grande oportunidade de aplicação, principalmente em

empresas que não adotaram um ERP como solução maior de integração de sistemas. Nessa,

a própria estratégia de implementação do ERP já considera os aspectos de fontes únicas de

dados mestres. De qualquer forma, a abordagem envolve a busca de uma nova arquitetura

com uma camada de tecnologia, que alia análise de possíveis conflitos de dados, com

distribuição/replicação automática de atualizações por entre arquivos/bases de dados. Há

algumas topologias sugeridas para sua implementação e todas deverão ser cuidadosamente

analisadas, pois algumas estratégias implicam complexidades de técnicas de Bancos de

Dados distribuídos/replicados.

3.8. Gestão de Data Warehousing e Business Intelligence

A Gestão de Data Warehousing (DW) e Business Intelligence (BI) de acordo com o DMBOK

(2009) consiste em planejar, implementar e controlar processos para prover dados de

suporte à decisão e apoio a colaboradores envolvidos em produção de relatórios, consultas e

análises. Dentre as atividades envolvidas, estão:

39


Entender as necessidades de informações analíticas (BI - Business Intelligence).

Definir e manter a arquitetura de DW e de BI, já mencionada anteriormente na

função Gerência da Arquitetura de dados como “Definir e manter uma arquitetura de

DW e de BI”.

Implementar os DW e DataMarts.

Implementar as ferramentas de BI e de interface para usuários.

Processar os dados para o ambiente de BI.

Monitorar e ajustar os processos de DW.

Monitorar e ajustar as atividades e aspectos de performance de BI.

Os resultados obtidos na pesquisa quanto a função de gestão de Data Warehousing e

Business Intelligence são apresentadas no gráfico 12.

Gráfico 12 - Atividades de gestão de Data Warehousing e Business Intelligence executadas atualmente

A pesquisa não apontou nenhuma novidade com relação aos aspectos que se esperava de

DW e BI. De acordo com o gráfico 12, todos os números apresentaram viés positivo, com

6,4% de desconhecimento médio. Os valores mais altos se apresentaram no entendimento

da necessidade de informações de BI (78%) contra 15% que disseram não ter essa

compreensão. A definição de uma arquitetura, a criação de depósitos informacionais e a

implementação de ferramentas para usuário foram atividades com índices de 65% a 69%

entre os respondentes. Essa é outra área de conhecimento com razoável maturidade

definida.

47%

33%

37%

33%

36%

19%

22%

23%

22%

22%

12%

10%

9%

12%

10%

15%

27%

24%

27%

26%

6%

8%

6%

6%

6%

0% 20% 40% 60%

Entende as necessidades de informações de Business

Intelligence

Define e mantém arquitetura de DW / BI

Implementa Data Warehouses e Data Marts

Implementa ferramentas de BI e interfaces para usuários

Processa dados para Business Intelligence





Não sei

40


Hoje, grande parte das empresas já busca soluções de BI visando prover informações para

tomadas de decisão e análises mais elaboradas como analytics. Os desafios que surgirão

nesse campo ficam por conta do crescimento dos dados (Big Data) e do uso mais intensivo

de ferramentas de analytics (sentiment analysis, text mining, etc.), buscando entender novas

formas de dados (mídias sociais) ou novos elementos de aproximação com os seus usuários

(BI mobile). Isso não está explicitamente contemplado no modelo DMBOK, mas certamente

estará nos próximos releases. Os conceitos de aplicação de BI em Big Data ainda estão em

formação e sua ainda baixa incidência se alinha com os níveis de desenvolvimento flagrado

no outro corpo de conhecimento (dados não estruturados) e conteúdo.

3.9. Gestão de documentos e conteúdo

A Gestão de Documentos e conteúdo envolve planejar, implementar e controlar atividades

para armazenar, proteger e acessar dados encontrados em arquivos eletrônicos e registros

físicos (texto, gráficos, imagens, áudio e vídeo), ou seja, o foco em dados não estruturados.

(DMBOK, 2009). Sua estrutura segue:

Gestão de Documentos e de Registros

• Planejar a gerência de Documentos e de Registros.

• Implementar Sistemas de gerência para Aquisição, Armazenamento, Acesso e

controle de Documentos e Registros.

• Backup e Recuperação de Documentos e Registros.

• Retenção e eliminação de Documentos e Registros.

• Auditar Gerência de Documentos e Registros.

Gestão de Conteúdo

• Definir e manter taxonomia corporativa para documentos e conteúdo. Já

mencionada anteriormente na função Gerência da Arquitetura de Dados como

“Definir e manter uma taxonomia e padrões de nomes (namespaces) de dados

para a empresa”.

• Documentar /indexar metadados sobre informações de conteúdo.

• Prover acesso e recuperação de conteúdos.

• Estabelecer Governança sobre qualidade de conteúdos.

O Gráfico 13 apresenta o resultado quanto às atividades de gestão de documentos e

conteúdo realizadas atualmente pelas empresas pesquisadas.

41


Gráfico 13 - Atividades de gestão de documentos e conteúdo realizadas atualmente

Para o DMBOK (2009) a essência deste processo é entender como a empresa trata os

documentos e conteúdos. No fundo, esse corpo de conhecimento começou com a

preocupação com os dados que não estão regularmente controlados via bancos de dados

relacionais e se desloca, hoje, em direção à gerência de todos os tipos de dados não

estruturados. Com o crescimento do conceito de Big Data, englobando dados não

tradicionais, esse item ganha importância e poderá ser revisto nas próximas atualizações do

modelo DMBOK.

Nesse momento, o processo genericamente pretende definir linhas de controle sobre a

coleta, armazenamento, acesso e uso dos dados e informações armazenadas fora dos

domínios dos SGBD´s relacionais. Com a chegada dos conceitos de Big Data, NoSQL,

Hadoop/MapReduce, Netezza, MongoDB (SADALAGE, 2013), entre outros, estarão aqui,

talvez de forma mais atualizada no futuro, as considerações sobre essas novas tecnologias.

Atualmente, a ideia se concentra no controle e gerência dos documentos, vistos como um

50%

42%

53%

47%

31%

31%

31%

36%

9%

10%

8%

9%

6%

4%

4%

9%

8%

10%

10%

6%

3%

4%

3%

4%

26%

29%

22%

26%

45%

50%

53%

37%

8%

8%

8%

12%

15%

12%

10%

14%

0% 20% 40% 60%

Planejamento para gestão de documentos / registros

Implementa sistemas para gestão de documentos / registros para aquisição, armazenamento, acesso, e controles de

segurança

Realiza backup e Recuperação de documentos / registros

Retém e elimina documentos / registros

Audita gestão de documentos / registros

Define e mantém taxonomia da organização

Documenta / Indexa metadados de conteúdo de informação

Fornece acesso e recuperação a conteúdo





Não sei

42


objeto e na gerência de seu conteúdo, ou seja, as suas partes integrantes, assuntos, palavras

chaves, taxonomias de conhecimento, entre outras. Além disso, também a sua forma de

relacionamento com os dados estruturados que habitam os gerenciadores tradicionais deve

ser considerada.

A pesquisa, apresentada no Gráfico 13, demonstra que as respostas que possuem o viés

positivo (atividade realizada, realizada consistentemente e monitorada e auditada) são

exatamente as que tocam no sentido mais amplo da gerência de documentos

(Planejamento, implementação, recuperação e backup, retenção/descarte e acesso ao

conteúdo). Nas perguntas associadas a conceitos de qualidade (audita a gestão do processo)

e elementos mais evoluídos da gerência de documentos, como definição e manutenção de

taxonomia e indexação de metadados, observa-se o viés negativo (atividade não realizada e

“não sei”). Isso se explica, pois esses últimos elementos fazem parte das estruturas básicas

da Gerência de Conhecimento, patamar ainda em gestação na maioria das empresas.

Também a ausência de auditoria de qualidade sobre os processos expressa certo grau de

imaturidade das empresas, ainda praticando níveis mais artesanais e menos calcados em

modelos de maturidade.

Dentre as dez funções de gestão de dados propostas pelo DMBOK e abrangidas nesta

pesquisa, a Gestão de Documentos e conteúdo, é uma das que apresentaram os maiores

indicadores de “não sei”, com uma média 12,8%, mandando sinais para a área de

treinamento e/ou ambiente acadêmico. Esse é outro domínio que exige atenção dentro do

espectro de Gestão de Dados, não só pelo seu desconhecimento e pela sua operação, mas

também pelo que está por vir. Hoje há muitos sistemas isolados, já rodando nas empresas,

em áreas de dados especiais. Gerência Eletrônica de Documentos (GED) e sistemas de

tratamentos de dados georreferenciados são exemplos deles. Em primeiro lugar, são

sistemas implantados de forma isolada, com baixa conexão com sistemas corporativos e

normalmente com tecnologias independentes. Com o crescimento de Big Data, com novas

fontes de dados, como redes sociais, fotografias, dados de RFID, e-mails, entre outras, isso

certamente mudará. A empresa deverá analisar cuidadosamente a sua real necessidade e a

demanda por tipos específicos de dados, não devendo se importar com a pluralidade desses

ativos, mas sim com a especificidade de seus requisitos e com as necessidades demandadas

por seus negócios. Novas abordagens, como a gerência de conhecimento ou sentiment

analysis, web mining, text mining, pesquisa de reputação e imagem /tendência de churn em

mídias sociais, exigirão uma nova postura com relação a esse corpo de conhecimento.

43


3.10. Gestão de metadados

A Gestão de Metadados implica em planejar, implementar e controlar atividades que

viabilizem um fácil acesso aos metadados integrados e de qualidade (DMBOK, 2009). A

estrutura está listada a seguir:

Entender os requisitos de metadados.

Definir a arquitetura de metadados, já mencionada anteriormente na função

Gerência da Arquitetura de dados como “Definir e manter uma arquitetura de

metadados”.

Desenvolver e manter os padrões de metadados.

Implementar um ambiente gerenciado de metadados.

Criar e manter metadados.

Integrar metadados.

Gerenciar Repositórios de metadados.

Distribuir e entregar metadados.

Consulta, Relatórios e Análises sobre metadados.

O Gráfico 14 demonstra os resultados quanto a Gestão de Metadados.

44


Gráfico 14 - Atividades de gestão de metadados executadas atualmente

Esse processo é aquele em que praticamente todas as respostas ficaram fora do viés

positivo, ou seja, houve a predominância absoluta da resposta “A atividade não é realizada”,

com um grau médio de “não sei” de quase 8%. A única resposta com viés positivo foi o

entendimento dos requisitos de metadados, na clássica imagem de que se entende a

importância daquilo como requisito, mas não se implanta. (Gráfico 14).

Outro ponto importante de se aprofundar aqui é com relação à diferença entre metadados

de negócios e metadados técnicos. Como a pesquisa não detalhou essa diferença, parte das

respostas positivas ainda podem estar direcionada para os metadados técnicos,

normalmente mantidos em ambientes de bancos de dados e de seus catálogos e não para os

metadados de negócios. O item “Cria e mantém metadados”, que apresentou um indicador

de 46% no viés positivo, empatado com o viés negativo, talvez possa ser explicado por esse

aspecto. (Gráfico 14).

A Gestão de Metadados se mostra, nessa pesquisa, como a parte da gestão estratégica de

dados com maiores lacunas, dentre todas. Os metadados podem ser considerados como um

dos temas mais falados e menos implementados no mundo dos dados. O metadado é como

aquela placa que identifica “comida a quilo”, que fica ao lado dos rechauds. Sem a perfeita

identificação dos pratos oferecidos, você não sabe o que está consumindo. Poucas empresas

44%

36%

36%

29%

41%

32%

33%

8%

4%

4%

5%

1%

4%

3%

4%

5%

4%

4%

4%

1%

6%

37%

47%

50%

54%

46%

55%

50%

8%

8%

6%

8%

8%

8%

8%

0% 20% 40% 60%

Entende os requisitos de meta-dados

Define a arquitetura de meta-dados

Desenvolve e mantém padrões de meta-dados

Implementa um ambiente gerenciado de meta-dados

Cria e mantém meta-dados

Integra meta-dados

Gerencia repositórios de meta-dados





Não sei

45


se preocupam com uma arquitetura de metadados, afora aqueles que são produzidos

automaticamente pelos SGBD´s para abrigar informações físicas sobre tabelas, campos,

índices, triggers, entre outros. Mas isso é muito pouco, e nesse particular a Gestão

Estratégica de Dados terá muito trabalho pela frente.

3.11. Gestão da qualidade de dados

A Gestão de Qualidade de dados consiste em planejar, implementar e controlar atividades

que apliquem técnicas de gerência de qualidade de dados para medir, avaliar, melhorar e

garantir a adequação dos dados ao seu uso pretendido (DMBOK, 2009). A estrutura de

atividades deste quesito segue:

Desenvolver e promover aspectos de conscientização sobre Qualidade de dados.

Definir requisitos de Qualidade de dados.

Estabelecer processos de “profiling”, análise e avaliação de Qualidade de dados.

Definir métricas para Qualidade de dados.

Definir Regras de negócios para Qualidade de dados.

Testar e validar os requisitos de Qualidade de dados.

Definir e avaliar níveis de serviços de Qualidade de dados.

Medir e monitorar continuamente a Qualidade de dados.

Gerenciar as pendências de Qualidade de dados.

Corrigir os defeitos de Qualidade de dados.

Projetar e implementar procedimentos operacionais de Gerência de Qualidade de

dados.

Monitorar os procedimentos operacionais e a performance da Gerência de Qualidade

de dados.

O Gráfico 15 apresenta os resultados da pesquisa quanto aos quesitos da Gestão da

qualidade de dados.

46


Gráfico 15 - Atividades de Gestão de Qualidade de Dados realizadas atualmente

Observa-se no Gráfico 15, que na maioria das questões, houve a prevalência do viés de não

realização das atividades (quatro questões contra duas). Os aspectos de definição de

requisitos de qualidade, de análise e avaliação da qualidade dos dados, de definição de

métricas para se gerenciar a qualidade e de gestões sobre qualidade se mostraram com viés

de não realização. Somente duas perguntas apresentaram viés positivo de realização: A

promoção da conscientização em qualidade de dados (com 51% para a realização sobre 47%

para a não) e a limpeza e correção de defeitos de qualidade de dados (com 49% sobre 47%).

Neste último, inclusive, há uma questão fundamental que não foi expressa na pesquisa: O

fato de se limpar e corrigir os defeitos de dados de forma preventiva e profilática e não de

forma reativa, como provavelmente ocorre na maioria das empresas. As respostas podem

ter sido dadas com a percepção de que existe a correção a posteriori e não a priori, que

seria, esta sim, o grande objetivo da prática.

O grau médio de desconhecimento sobre o assunto é pequeno, com cerca de 3% dos

respondentes, apontando que a qualidade dos dados faz parte do contexto de gestão das

empresas, embora ainda realizada com certa discrição.

40%

31%

19%

19%

26%

35%

10%

9%

8%

6%

10%

8%

1%

6%

8%

9%

9%

6%

47%

51%

62%

63%

53%

47%

1%

3%

4%

3%

3%

4%

0% 10% 20% 30% 40% 50% 60% 70%

Define e promove a conscientização em qualidade

de dados

Define requisitos de qualidade de dados

Analisa, avalia e gera o perfil da qualidade dos dados

Define métricas de qualidade de dados

Gerencia questões de qualidade de dados

Limpa e corrige defeitos de qualidade de dados





Não sei

47


Essa é outra dimensão que apresenta grande lacuna no espectro da gestão estratégica de

dados. A Qualidade de dados talvez seja um dos mais importantes domínios da GD e

paradoxalmente legado a um segundo plano. Há hoje diversas proposições de processos de

qualidade (MIT/Wang, Larry English, Danette McGilvray, Jack Olson, entre outros). O grande

desafio aqui é mostrar que a qualidade tem ROI e isso não é tarefa fácil pela intangibilidade

dos conceitos.

Existem diversos domínios na percepção da qualidade: Qualidade intrínseca, que envolve a

credibilidade que os dados sugerem e a reputação dos projetos a que eles servem. Veja, por

exemplo, dados de cadastros do INSS e do Bolsa Família, citados em BARBIERI (2011). Há

aspectos de falta de integração de dados processados por BP (Processos de negócios)

diferentes. Existem lacunas de qualidade dos dados nos aspectos de sua documentação,

metadados, padrões, regras de negócios para seu processamento, com clara ausência de

dicionários, glossários ou repositórios de metadados.

No domínio da integridade, os dados são observados: a validade ou range de valores

aceitáveis, máscaras de edição ou de aceitação e integridade referencial. Novamente aqui,

observa-se o papel dos SGBD como indutor de certos pontos de qualidade, como a

integridade referencial e cláusulas Check. Os aspectos de duplicação de registros já se

tornaram alvos das técnicas de MDM, como dito anteriormente, porém com discretíssima

aplicação. O sentido de precisão dos dados, quando confrontados com referências oficiais,

como os dados referenciais de CEP, domínios de internet, cadastro de logradouros oficiais,

códigos de doenças, entre outros, já é bem observado nas empresas.

Aspectos mais amplos como disponibilidade dos dados (tê-los quando precisamos),

apresentação (forma de visualização) e amplitude (cobertura com que os dados atingem os

objetivos propostos) são considerados medianamente nas empresas. Embora seja de

fundamental importância e um dos pilares da Gestão estratégica de dados, a qualidade

ainda tem muito caminho a percorrer, conforme sugere a pesquisa e as percepções

qualitativas observadas nas empresas em que atuamos.

3.12. Ferramentas de apoio a Gestão de Dados

A pesquisa ainda abrangeu uma questão onde foi solicitado às empresas que citassem as

ferramentas que apoiavam a gestão de dados e suas funções. Segue abaixo a lista compilada

das principais ferramentas citadas:

48


Ferramentas para análise estatística: Microstrategy, Oracle Analyze, SAS, BROffice,

MS-Sharepoint, MS-SQL Server

Ferramentas de Data Profiling: Informatica, Infosphere Information Analyzer, MS-SQL

Server, Talend, Suite IBM

Framework de aplicação e Persistência: Hibernate, JBoss Seam, SQL Azure, MS Entity

Framework, Red Hat

Ferramentas de testes: Test Manager, Visual Studio, Team Foundation System (TFS),

Rational Test Suite, HP ALM, Wapt Pro, Red hat

Ferramentas para desenvolvimento de software: RSA, Visual Studio, dotNet, Java,

Delphi, PHP, PL/SQL, Eclipse, Uniface, Suite Rational, VB, C++, C#, Flex, ASP

SGBD: DB2, Oracle, Adabas, Postgres, SQL Azure, MS-SQL Server, MySQL, Firebird,

Informix, Sybase, MongoDB e Netezza (IBM)

Ferramentas para internet, portal corporativo e e-mail: Websphere (IBM), Wiki,

Dropbox,Outlook, Gmail, MS-Sharepoint, Exchange, Lotus Notes, WebLogic, Media

Wiki, Drupal, Navita, Confluence, Joomla, Postfix, ERStudio, IBM Websphere, Portal,

Wordpress, Zimbra

Ferramentas para higienização de dados: Informatica, SQL Azure, Spectrum, Data

Quality, Infobusca, MS-Sharepoint, MS-SQL Server, Talend, Suite IBM

Ferramentas de integração de dados: SQL Azure, MS-Integration Services,

Informatica, PDI-Pentaho, Data Stage, SOA-IBM, Oracle, MS-DTS, Oracle Golden Gate,

ODI-Oracle Data Integrator, MQ-IBM, JMS, EMS, Postgres,MS-Sharepoint, Talend,

Informatica, Suite IBM

Ferramentas de BI: Microstrategy, BO-Business Objects, IBM BDW, Oracle BI, MS,

SAP-BI, Pentaho, Powercenter, Oracle BIEE, Web Intelligence, Cognos, Hyperion,

CorVu, Oracle BI, MS-Analysis Services, ER Studio, Talend, Suite IBM

Ferramenta para gerenciamento de registros: SQL Azure, EA, MS - Sharepoint

Ferramentas para dashboards-KPI: Microstrategy, XCelsius, Oracle BIEE, MS-Analysis

Services, Cognos, ICG, Powerpoint, BO, MS-Sharepoint

49


Ferramentas para controle de configuração: HP Service Manager, Portal Windows,

Azure, TFS(Team Foundation System),ClearCase(IBM), Subversion, CVS, RTC-Rational

Team Concert

Ferramentas para gerenciamento de incidentes: HP Service Manager, Warpnet, CA-

harvest, CA-SDM, MS-Sharepoint

Ferramentas para desenvolvimento XML: Visual Studio-2012, Uniface, Notepad++

Ferramentas para gestão de Dados Mestres e de Referência: IBM WSI, Visual Studio,

Oracle UCM, Uniface, Suite IBM

Ferramentas para gerenciamento de conteúdos e documentos: Content Manager,

Dropbox, MS-Sharepoint, UpImage,SVN, Centera, Documentum, MFS-Microsoft, File

Server, Wordpress, CVS, Google apps

Ferramentas de produtividade de escritório: MS-Office, Springpad, ScrumMe, MS-

Sharepoint, Wiki, BROffice

Ferramentas para modelagem de processos: IBM Modeler, MS-Visual Studio, EA-

Enterprise Architect, ARIS, Bizage, UML, Visio, IBM Process Designer

Ferramentas de inferência de regras de negócios: Cognos, Oracle, Caliber, EA, ILog,

MS-Sharepoint, IBM BRMS

Ferramentas para modelagem de dados: CA-Erwin, MS-Visual Studio, EA, SQL Server

Management Studio, Entity Framework, DBDesigner, Power Designer,SQL Developer

Data Modeler, Oracle Designer, Toad Data Modeler, MS-Sharepoint, ER Studio Data

Architect, ERwin-Navigator

Ferramentas para modelagem de objetos: Rational-RSA, MS-Visual Studio, AS-System

Architect, Rational Rose, Java doc, Power Designer, MS-Sharepoint

Ferramentas para repositório e gerenciamento de modelos: CA-ERWin, Dropbox, EA,

Power Designer, ModelMart, Uniface, Toad, Oracle Designer, MS-Sharepoint,

ERStudio Navigator

50


4. REFERÊNCIAS BIBLIOGRÁFICAS

BARBIERI, C. BI2 – Business Intelligence - Modelagem e Qualidade. Elsevier, 2011.

BARBIERI, C. Posts sobre Governança de Dados, Big Data, entre outros. Disponível em

http://blogdobarbi.blogspot.com

DMBOK. MOSLEY, M. ; BRACKETT, M.; EARLEY, S. HENDERSON, D. DAMA Guia para o corpo

de conhecimento em gerenciamento de dados. Technics Publications, versão brasileira

2012.

DMBOK. MOSLEY, M.; BRACKETT, M.; EARLEY, S.; HENDERSON, D. The DAMA Guide to The Data Management Body of Knowledge: DAMA - DMBOK Guide. 1. ed. Estados Unidos: Technics Publications, 2009.

ELMASRI. R. ; NAVATHE. S. Fundamental of Data Base Systems: Addison Wesley, 2000.

SADALAGE P.; FOWLER, M. NoSQL Distilled: A Brief Guide to the Emerging World of

Polyglot Persistence. Addison-Wesley, 2013.

SERPRO. Modelo Global de dados - Integração de dados e processos. Disponível em http:// http://modeloglobaldados.serpro.gov.br/. Acesso em 22 de junho de 2012.

SOARES, S. Big Data Governance: An Emerging Imperative. Mc Press, 2012.

SOFTEX - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO. MPS.BR – Guia de Implementação – Parte 5: Fundamentação para Implementação do Nível C do MR-MPS:2009, 2009. Disponível em: http://www.softex.br

Documents

ANÁLISE DA PESQUISA: O perfil das empresas brasileiras em ... · Governança de dados ... Gestão de Data Warehousing e BI Gestão de Documentos e conteúdo Gestão de Metadados