Governança de Dados-Parte-X- Resumo dos pontos fundamentais da GD

Depois de analisarmos várias escolas de Governança de dados, aqui vai uma espécie de “Road map” de GD,  ou os  12 Mandamentos, que  devem ser observados quando falarmos de sua implementação prática nas empresas:

1)Criação de um grupo de estudo,  envolvendo a TI e as áreas de negócios  cujos dados sejam mais sensíveis e críticos, como dados financeiros, de clientes, de vendas, etc.  É fator crítico de sucesso o alto envolvimento das áreas de negócios, com a busca de patrocinadores fortes e comprometidos com a melhoria da gestão de dados;

2)Definir políticas para a conceituação de Dado, como um ativo(asset) da empresa e diretrizes para a formação do Comitê de Governança de dados da empresa. As políticas deverão ser regras gerais consensadas entre as unidades organizacionais envolvidas e aprovadas pela alta gestão da empresa e deverão ser parte de processos e padrões definidos para a Governança de dados na empresa;

3)Definir os riscos de dados “impuros” (data flaws) ou como os aspectos de baixa qualidade dos dados criam impactos nos negócios da empresa. A definição de riscos potenciais ou  de “business cases” de problemas derivados de qualidade de dados é fator crítico na aprovação de um Programa de Governança de dados, pela alta gerência e fundamental para sua sensibilização ;

4)Inventariar nas  áreas envolvidas, TI inclusive, as principais fontes de dados, de forma a se ter uma visão do grau de replicação de arquivos considerados críticos, como BD de Clientes,  de Pessoal, de Materiais, Financeiro, etc; Esse item, que oferece uma visão qualitativa do problema, compõe parte do item 3 acima descrito;

5)Selecionar as bases de dados consideradas mais críticas para tratamento quantitativo de qualidade. Buscar e aplicar soluções de “data profiling” em bases escolhidas baseadas em priorização, visando demonstrar o grau de qualidade dos dados considerados críticos;

6)Analisar as lacunas observadas e o nível de maturidade atual em dados. Com eles, fazer a  proposição de plano de ação, que poderá envolver  a criação de gestores de dados(data steward) localizados em áreas críticas de negócio da empresa. Os gestores de dados atuam em áreas funcionais/linhas de negócios com a responsabilidade de aplicar e preservar as políticas, regras , diretrizes de qualidade, como criação, uso, replicação,etc;  

7)Pensar a GD em camadas  funcionais distintas, com papéis definidos e pessoas alocadas:

·         A camada estratégica, onde está o Comitê de GD, ou de Conselho de Dados, ou que nome venha a ter. Formado por gerentes funcionais de áreas (TI, inclusive), terá o objetivo de estabelecer  as políticas e diretrizes que definem o dado como um ativo da empresa. Resolverá impasses que certamente surgirão e será uma espécie de Comitê Consultivo;

·         A camada tática com o Grupo de implementação do programa de GD(CDO-Chief Data Office, ou DMO-Data Management Office, ou DGPG-Data Governance Program/Process Group), formado pela gerência média, responsáveis pela execução dos planos de ação. As palavras chaves aqui são: envolvimento, cooperação e convencimento por resultados concretos. A gerência de uma área de negócios deverá ter pleno entendimento das definições de GD, vindas do Comitê acima, a fim de apoiar as ações de seus gestores de dados e as definições do CDO/DMO/DGPG;

·         A camada operacional, com os gestores de dados(data steward) alocados nas áreas e linhas de negócios, responsáveis pelas atividades do dia a dia. Por exemplo, na área de Faturamento de uma empresa de energia elétrica , poderá haver gestores de dados divididos em domínios ou subdomínios, como faturamento secundário/primário/grandes consumidores de alta tensão, etc. O aproveitamento de recursos humanos nas áreas de negócios, com grande conhecimento do assunto(subject área) pode ser considerada  uma excelente estratégia na definição dos gestores de dados(data steward). Esse conceito é chamado “Governança de dados não invasiva”, e foi definido por Robert Seiner, da Kikconsulting, especialista em Governança e Administração de dados;

8)Iniciar ações para conhecer e entender os dados existentes através de levantamento de termos de negócios, visando a formação do repositório de metadados, contendo definições, relacionamentos e áreas de negócio responsáveis pela sua criação, custódia e consumo (CCC);

9)Pensar a Governança de dados em alguns projetos específicos com respectivos planos, selecionados pela prioridade, definidos em programas, como MDM(Master Data Management), Segurança de dados, Qualidade dos dados para tomada de decisão(BI com Analytics), Dados não estruturados(Geo-BI, por exemplo),etc. Por exemplo, na trilha MDM, identificar as ações para reduzir as replicações de fontes de dados críticos(Consumidor, Órgãos, Produtos, etc) , levantados no item 4. Envolver as áreas de negócios que atuam no domínio daquele dado e criar ações alinhando “business e TI”. Esses projetos devem ser vistos como iterações do processo maior de GD, aplicando-se  neles as atividades de identificação de metadados, definição de métricas, garantia da qualidade, etc.  Na trilha de BI com Analytics, considerar aspectos de governança no sentido de identificar por áreas de negócios: os seus usuários, os relatórios ou cubos produzidos e consumidos, o valor de retorno dessas informações de BI para o usuário, freqüência e tipo de solicitações atendidas, etc. Esse trabalho deverá ser feito com envolvimento do Núcleo de BI  e apontará , de certa forma, o grau de maturidade com que a área de BI atua. Ver mais adiante detalhamento sobre maturidade em BI, conforme pesquisa da TDWI.  Na camada de dados não estruturados, entender que 80% dos dados de uma empresa hoje estão na forma semi ou não estruturada. Assim aspectos relacionados com dados de mapas, GED (Gestão Eletrônica de Documentos), etc devem ser observados  e também  merecer os olhares da GD;

10)Sempre atuar com o conceito de “quick hits”, ou seja realizando projetos que retornem rapidamente resultados visíveis e importantes;

11)Definir procedimentos de monitoração dos projetos, através de ações de medições(MED) ou de garantia da qualidade(GQA), criando indicadores, como número e tipos de “incidentes” relativos a dados, problemas de reclamações externas devido a erros de dados, não-conformidades com definições regulatórias detectadas, etc;

12) Por fim, entender que GD é um  programa e não um projeto isolado e portanto tem características contínuas, e que o processo desenhado para implementá-lo deverá ser constantemente avaliado por medições e ganhos tangíveis, o que viabiliza a sua continuidade e minimiza os riscos de seu colapso. 

Se você quiser criar uma memória sintética , pense nos “9 P”  da GD, grifados até aqui, ao longo do texto:

1)Patrocínio

2)Políticas

3)Processos

4)Padrões

5)Papéis e Pessoas

6)Procedimentos

7)Programas/Projetos(Planos)

Com esse artigo, encerramos o primeiro bloco que objetivou o entendimento dos conceitos alicerces de GD através de várias óticas. No próximo bloco de posts discutiremos os aspectos de Maturidade em GD, analisando várias propostas de modelos de maturidade, inclusive uma baseada nas premissas e experiências obtidas nas diversas implementações de modelos de maturidade para software: MGD-Melhoria de Gestão de Dados. 

Governança de Dados-Parte IX- Visão Sunil Soares/IBM sobre Governança de Dados-Segunda parte-cont. do post anterior

4)Com os resultados do passo anterior, construir um Plano de GD, com foco nos  “Ps” como Pessoas e Papéis, Processos, Patrocínio, Procedimentos e Planos detalhados . O objetivo do plano é “encaminhar soluções” sobre as lacunas mostradas  no passo anterior. Poderá ser um Plano ou um programa contendo vários projetos.

5)Definir uma estrutura organizacional: Nesse passo, deverão ser pensadas as formas de estruturação de pessoas e papéis, a fim de se criar o arcabouço organizacional da GD. Uma das propostas mais encontradas é a definição de três(3) camadas: No alto, um Conselho, formado por pessoas influentes nas áreas “targets” do programa, como vice-presidentes de marketing, ou de finanças, ou de logística, etc. Esse conselho será o tira-teima dos problemas que certamente aparecerão em função da falta de “ownership” de dados nas empresas. No segundo nível aparece o que poderia ser chamado de DMO-Data Management Office, que seria uma gerência constituída por uma liderança tática definida, vindo da área de business, com participação de elementos da TI. Essa camada, representa o nível gerencial tático sobre os dados da empresa, da mesma forma que os PMO estabelecem controles sobre os projetos da companhia. Na terceira camada, no nível mais operacional, ficariam os “gestores de dados”, ou data steward, elementos escolhidos e lotados em cada área de business envolvida no projeto, com o objetivo de aplicar os conceitos de gestão sobre os dados daquele domínio. Seguirão os processos e regras definidas nos níveis hierárquicos anteriores. Há algumas proposições sobre o tipo de Data steward(gestor de dados):

·         Orientado a sistemas: Essa abordagem  define o gestor(steward) associado a um ou mais sistemas de informações. Por exemplo, um gestor de dados que tomaria conta (dos dados) dos sistemas de Faturamento e Arrecadação do SAP para empresa “utilities”. Normalmente ficam situado no âmbito da TI-Tecnologia de Informação, o que pode sugerir dificuldades na venda da idéia para toda a empresa ;

·         Orientado a unidade organizacional: Essa abordagem define o gestor de dados num nível funcional, dentro de uma unidade da empresa. Por exemplo, a área de Faturamento poderia ter um data steward, que seria o gestor para os dados que circulam por aquela unidade organizacional. Ele estaria gerindo outros dados de outros sistemas, que estivessem naquela mesma unidade da empresa, expandindo o escopo da proposição anterior;

·         Orientado para Assunto: Essa abordagem define o gestor de dados num âmbito corporativo, ficando com a incumbência de gerir o dado de forma mais ampla, num conceito de Entidade, ou “assunto”. Isso perpassaria várias unidades organizacionais e vem ao encontro do conceito de MDM(Master Data Management) . Assim um gestor seria responsável pelo assunto Cliente, Fornecedor ou Conta, etc, com forte associação com o conceito de dados mestres. Tem a vantagem da visão mais completa, porém sugere maiores dificuldades na sua implantação.  Essas diferentes estratégias de definição de gestores de dados, tem graduações proporcionais de dificuldades de implementação e dependerão da maturidade da empresa. A mais facilmente implementada é aquela mais focada em sistemas de informações e a mais difícil esta relacionada com a visão mais corporativa de dados e sua gestão como um ativo da empresa.

·         Ver os conceitos ilustrados nas figuras abaixo (final do texto) com a separação em 3 níveis hierárquicos e o posicionamento organizacional dos Gestores de Dados, conforme algumas soluções: Visão corporativa(Assunto),Visão de Unidade Organizacional e Visão de Sistema de Informação.

6,7,8)Entender os dados, construir o Dicionário de Dados e criar um repositório de metadados podem ser vistas como etapas de prospecção e mergulho nos dados existentes naqueles domínios em estudo, objetivando o pleno entendimento de seus depósitos, campos, descrições, dicionários, etc, visando a criação de uma camada documentacional . O Dicionário de dados ajuda no entendimento dos dados existentes e o repositório de metadados seria a sua extensão com a criação e merge  dos metadados técnicos (advindos das inspeções e descobertas de BD), e dos metadados de negócios, advindo dos DD, caso existentes. Os principais passos para se alcançar esses objetivos seriam:

·         Baseado no domínio de estudo, identificar as principais fontes de dados, ou seja: tabelas de bancos de dados, tabelas dimensões de sistemas analíticos, arquivos independentes, arquivos manuais, etc

·         Identificar e entender  os principais tipos de dados, segundo a classificação:

o   Dados Mestres, ou seja  os objetos, pessoas, clientes, fornecedores, vendedores, colaboradores, representando os diversos papéis de relacionamentos  da pessoa física ou jurídica com a empresa. Alguns autores ainda classificam os dados mestres de acordo com a sua volatilidade. Por exemplo, dados mestres do tipo Contrato normalmente são mais estáticos depois de criados, enquanto que dados mestres de Clientes podem ser mais voláteis, quando esses elementos|(clientes) evoluem no seu ciclo de vida;

o   Dados Transacionais, ou seja aqueles normalmente com uma ou mais referência temporal, como Ordens de pedido, Notas fiscais, Ordens de compra, lançamentos,etc;

o   Dados de Referência, ou seja lista de valores padronizados (paises, estados, datas, códigos, etc), usados em codificações ou decodificações, com o objetivo de trazer maior clareza sobre a definição do dado. Alguns exemplos: dados de códigos postais(CEP) com associações com unidades geográficas, dados de códigos de padrões universais de produtos e serviços, como UNSPSC( convenção hierárquica, definida e adotada pelas Nações Unidas - de âmbito e aplicação mundial, usada para classificar todos os tipos de produtos e serviços). Os dados de referência estão próximos dos dados mestres, com um sabor mais de origem  externa(nem sempre)  e codificado. Ambos (Mestres e Referências) são fundamentais na geração dos dados transacionais

o   Metadados, ou seja os dados sobre os dados, que podem ser técnicos, como nome, comprimento, lay-out, array, etc ou de  negócios que são usados para aplicações no entendimento do negócio(títulos, nomes de telas, estatísticas, páginas web, etc), ou metadados de auditoria, com dados como tipo de informação para rastreamento, visando proteção, recuperação, quem, quando, como , o porquê, audit, log, etc;

o   Dados Históricos, que são dados de variadas naturezas(Mestres, Transacionais), com referência passada de tempo, normalmente não mais alteráveis e usado como registro de fatos acontecidos e  de valor histórico;

o   Dados Temporários que são dados usados em certas circunstâncias técnicas, na memória de sistemas, por exemplo, como elemento de otimização de tempo, performance, constantes, etc.

·         Criar os modelos de dados, casos inexistentes, ou entendê-los casos existam, a fim de produzir a visão documentacional composta por entidades, relacionamentos e atributos chaves e  atributos descritivos;

·         Criar os repositórios de metadados, com os elementos do tipo técnico, de negócio ou de auditoria.

9)Definir métricas: Esse passo é fundamental como estabelecimento de baselines que serão confrontadas após os ciclos dos programas de GD, que objetivam melhorar a performance dos dados. Serão as definições de KPI´s  de natureza técnica e de negócios. Os conceitos fundamentais sobre medidas e medições são:

•      Medidas são valores numéricos que representam extensão, quantidade, tamanho, dimensão ou capacidade de um produto ou de um processo. Por exemplo, são expressas por  metro linear para comprimento, escala Richter para intensidade de terremoto, metro cúbico para volume, quilograma para peso, contadores para registros/eventos  para medidas diversas dentro do processo de desenvolvimento de sistema, etc. São normalmente definidas por convenção;

•      Métricas representam o valor resultante do ato de colocar as medidas numa escala de relatividade. Por exemplo, metros cúbicos/hora, metros/segundo, quantidade de não conformidades (NC) na Fase de Elaboração, Esforço Realizado e Esforço Planejado em homens/hora estimado no mês de setembro de 2007, no projeto XABC, etc.;

•      Medição representa o ato ou processo de levantar medidas/métricas sobre produtos e processos com o objetivo de prover informações para uma análise e/ou tomada de decisão;

•      Indicadores são informações relacionadas a uma medida, métrica ou combinação de métricas que pode ser utilizada para ter uma compreensão de uma certa entidade objeto da análise;

•      Um exemplo que ilustra os conceitos: quando você realiza uma avaliação para começar a “malhar” numa academia, uma das métricas obtidas é o seu índice de massa corporal, que indica se você está com seu peso ideal ou não. Para tal, duas medidas são importantes: altura (H) e peso (P). A medição é o ato de levantar essas duas informações. Existe uma métrica chamada “índice de massa corporal (IMC)” que é calculada, em função das duas medidas, segundo a seguinte fórmula: IMC = P / H2.  A partir dessa métrica, foram estabelecidos indicadores que apontam se um adulto está acima do peso, se está na faixa aceitável ou abaixo do peso ideal. Por exemplo, para que uma pessoa seja considerada dentro do peso normal, o IMC deverá estar entre 18,5 e 25.  No ambiente de Processos de Software existem várias medidas que poderão ser obtidas, dentro dos domínios de tempo (tempo estimado e tempo realizado para certa atividade ou conjunto delas), custo (custo estimado e custo realizado para certa atividade ou conjunto delas), qualidade (número de defeitos observados em certas atividades ou conjunto delas), esforço (esforço em homens/horas estimado e realizado para certa atividade ou conjunto delas). As métricas poderão ser obtidas por operações realizadas entre essas medidas. Por exemplo, o valor agregado é definido como a percentagem de conclusão de uma atividade declarada no ato da medição multiplicada pela quantidade de horas planejadas para a realização daquela atividade. É importante definir para cada medida/métrica os limites ou faixas que representem valores bons, aceitáveis ou inaceitáveis. Por exemplo, se a densidade de defeitos for menor do que X defeitos por ponto de função, ela é considerada boa. Com valores entre X e Y ela é considerada mediana, e maior do que Y ela é considerada inaceitável. Normalmente, para essas situações de limites críticos, o processo de medições da empresa deverá definir ações a serem implementadas, visando a correções ou ajustes a respeito.

Do ponto de vista de GD as métricas deverão centrar em informações que agreguem valores ao negócio, principalmente no que tange a aspectos de dados relacionados com conteúdo, disponibilidade, integridade, segurança, etc e que possam implicar riscos e perdas no escopo do negócio, de sua credibilidade, de  aspectos de aderência a padrões,etc. Por exemplo, um campo código que indique uma classificação industrial ou geográfica poderá ter implicações sérias de riscos, caso não estejam adequadamente preenchidos. Uma análise de risco, numa instituição financeira, aplicada por tipo de indústria, poderá perder o seu valor caso esses códigos não esteja devidamente corretos e íntegros. O mesmo se aplicaria para estratégias a serem aplicadas em áreas de um país, com códigos regionais frágeis e sem qualidade. Um número de telefone, elemento de informação que pode ser importante em ações de marketing, por vezes, deverá ser validado contra arquivos externos oferecidos por provedores, como companhia de telecomunicação. O quanto dessas verificações resultaram em acertos poderia ser uma métrica sobre campos de telefones. Da mesma forma, a incidência de registros duplicados de fornecedores, vendedores, colaboradores, etc pode ser uma medida a se gerenciar, buscando-se gradativamente a sua minimização. A verificação de data de nascimentos de grandes arquivos mestres pode apontar erros como um número excessivo de pessoas com mais de certa idade, ou com idades impossíveis. Um medida sobre essas discrepâncias poderia ser feita em sistemas que apoiam linhas de negócios onde a idade do cliente, paciente, colaborador é considerada importante. Consistências em CPF ou no número da carteira do plano de saúde podem ser importantes em certos domínios de negócios. Essas métricas estariam, de certa forma,  atreladas aos aspectos de negócios da empresa. Outras métricas, poderiam ser definidas, associadas aos aspectos de documentação dos dados(metadados), como ausência de informações de origem de certo arquivo, no que são chamados metadados órfãos, ou seja não trazem os dados completos de sua origem. Por exemplo, um arquivo documentado sem a informação do seu departamento de origem(orfandade ou a ausência de linhagem dos dados). Métricas também podem ser definidas em certos assuntos emergentes como dados não estruturados, com medições de percentagem de documentos de negócios que estão sendo preparados para buscas de text mining. Indicadores de BI, como número de usuários, relatórios e suas execuções, por área de negócios, grau de atendimento da área de BI, etc. As métricas, ensina Sunil Soares, no seu Selling Information Governance to the business practices, devem ser D.A.T.A, ou sejam: Digestible, ou facilmente digerida por quem as consome. Para tal deve ser concisa, clara e objetiva. As métricas devem ser Actionable, ou seja devem sugerir ações concretas quando atingirem certos limites estabelecidos; Timely, ou disponíveis no tempo, ou seja devem ser entregues no menor tempo possível, encurtando a distância entre o ponto de sua captura e o momento de sua análise e consumo; e Auditable, ou auditável, no sentido de que os números obtidos naquela métrica devem ser rastreados de volta ao ponto da coleta ou captura, a fim de oferecer uma tonalidade de confiabilidade. 

10)A partir desse ponto, o road map da IBM, sugere trilhas paralelas, que poderão ser projetos fundamentais do Programa de GD, como: Governança de Dados Mestres, com a definição de gestores de dados de áreas de domínios envolvidas, gerenciamento da qualidade dos dados desses DM analisados, e definição de  soluções arquiteturais para MDM dessas fontes. 

Figuras:

Links para correções-BI2-Modelagem e Qualidade-Carlos Barbieri

Link para correção dos pequenos erros encontrados no BI2-Modelagem e Qualidade-Carlos Barbieri:

Os links estão acumulados num arquivo Dropbox, acessado por:

http://tinyurl.com/cwkkele

Grato
CB

Governança de Dados-Parte IX- Visão Sunil Soares/IBM sobre Governança de Dados-Primeira parte:

Vou centrar as minhas percepções em cima da figura  9.1.  A figura mostra uma adaptação feita por mim, sobre o RoadMap apresentado por Sunil Soares , na página 8, do seu livro  The IBM Data Governance Unified Process, publicado por MC Press, em 2010. Fiz uma análise do roadmap apresentado pela IBM , inserindo idéias e posições próprias, embora o enredo seja baseado nas premissas apresentadas nos trabalhos pesquisados.  

1)Definir um problema: Você deve vender uma proposta de GD sempre com ênfase num problema de dados, seja de segurança, privacidade, riscos em regulações exigentes, problemas de consistência, integridade, precisão e disponibilidade de dados, etc. O problema deverá ser centrado em cima de dados sensíveis, de áreas importantes e vitais para o “business da empresa”. O problema será a semente para se iniciar as ideias de GD. Se a sua empresa não apresenta problemas de dados( o que é altamente improvável), você não precisa de GD. Esqueça;

2)Buscar apoio da Alta Gerência: O problema apresentado deverá ser o mote para você ganhar o apoio da alta gerência com relação à iniciação de um programa de GD. De novo, se não há problemas, esqueça a GD. O problema é que  sempre há problemas de dados, em grande parte submersos, invisíveis e perigosos. O apoio da alta direção é fator fundamental num programa dessa natureza que mexerá e regularizará um insumo que, normalmente não tem dono, ou o que é pior, tem vários; 

3)Realizar uma avaliação de Maturidade: Essa é , na realidade, a primeira fotografia da situação. As empresas normalmente não tem muita ideia da situação de seus dados, a menos daquelas que ainda mantém uma área se preocupando com eles(são poucas), independente do nome que essa função tenha: administração de dados, gestão estratégica de dados, etc. A proposta da IBM é a fotografia realizada via a avaliação de sua maturidade de dados. Essa é uma abordagem que normalmente é feita  em cima de uma área estratégica da empresa, com um escopo que permita um retorno rápido e objetivo. Há modelos da própria IBM sugerindo níveis diferentes de maturidade de dados, baseados no estilo CMMI, que poderiam ser usados em workshops envolvendo os principais das áreas “targets”, juntamente com a TI. Discutiremos os aspectos de maturidade de dados nos próximos posts, com muito mais detalhes, mas por ora, aqui vai uma ideia inicial: Os níveis de maturidade são:

·         Nível Definido-Possui como características:

o   Ações reativas

o   Não há medições de qualidade

o   Políticas inexistentes ou informais

o   Ações sem coordenação centralizada

o   Os erros são corrigidos  nos dados e não na fonte, sem causas raízes identificadas

·         Nível Repetido-Possui como características:

o   Ações ainda tímidas para se antecipar aos erros de dados

o   Algumas dimensões de qualidade são articuladas, como  completude, precisão, disponibilidade, atualidade,etc

o   Primeiras políticas  de Privacidade  e controle de uso aparecem

o   Identificação de erros de não completude, sintaxe, estrutura, etc

o   Primeiras práticas compartilhadas na área de dados

o   Primeiras tentativas de organizar , como elemento essencial de gestão de dados(semente MDM)

·         Nível Definido-Possui como características:

o   Estrutura de GD já existente, com Políticas, Guias, padrões corporativos e Metadados definidos ou em definição

o   Ferramentas e processos de Qualidade de dados(Data Quality) aplicados

o   Processo definido para  precisão e validação de dados. Aqui saímos do contexto de projetos e migramos para um foco mais organizacional

·         Nível Gerenciado-Possui como características :

o   Gerência  Quantitativa de qualidade, com a mensuração de indicadores que reflitam numericamente o estado dos dados, principalmente apontando fragilidades de conteúdo, forma, disponibilidade que implicam riscos no negócio

o   Certificações de fontes de dados, garantindo a não replicação

o   Auditoria formal e institucional de Qualidade de dados

o   GD com forte presença dos representantes  de linhas de negócios

o   Primeiras ações em MDM, visando a gerência de dados mestres

·         Nível Otimizado:

o   Processo automatizado de detecção de erros

o   Controle de dados ao longo de toda empresa

o   Métricas e políticas constantemente revisadas

o   GD  e Qualidade de dados institucionalizada

o   MDM implementado

Outra alternativa que poderia ser aplicada seria um projeto focado de Data Profiling, em cima de dados fundamentais da empresa, do tipo Master, como Fornecedores, Clientes, Produtos, etc. Essa avaliação, amostral sobre dados fundamentais, poderá ser feita de forma mais rápida e trazer resultados imediatos sobre o nível de qualidade dos dados. Há empresas e ferramentas especializadas nesse segmento e os grandes produtores de tecnologia já oferecem um arsenal de opções para tratamento de dados. A IBM, oferece uma suíte de produtos empacotados na família Infosphere Information Server, com módulos voltados para  MDM(Master Data Management), Análise de informações, avaliação de qualidade, profiling, conexões diversas e governança via metadados. A Oracle e Microsoft, também oferecem soluções nessas áreas, dentro das suas linhas próprias de produtos. Também cresce no Brasil o número de empresas prestadoras de serviços nesse espaço. Em BH, aparece a MD2 e em São Paulo, a ASSESSO, ambas com especialização em ferramentais de limpeza e estruturação de dados e portfólio de projetos em grandes empresas.   

(Continua no próximo post)