Gerenciamento de Dados Mestre: o quê, o por quê e o como

O processo desgastante pelo qual as empresas estão passando para emitir relatórios consistentes, cumprir regulamentos, além do grande interesse na Arquitetura Orientada a Serviço (SOA) e no Software como Serviço (SaaS) despertou um grande interesse no Gerenciamento de Dados Mestre (MDM). Este artigo explica o que é MDM, porque é importante, como gerenciá-lo e identifica, ao mesmo tempo, alguns dos principais padrões de gerenciamento e as melhores práticas que estão surgindo. Este artigo é um tratamento de alto nível do espaço do problema. Em artigos subseqüentes, desdobraremos as questões técnicas e de procedimento que envolvem o Gerenciamento de Dados Mestre.

O que são dados mestre?

A maioria dos sistemas de software possui listas de dados, compartilhados e utilizados por vários dos aplicativos que compõem o sistema. Por exemplo, um sistema ERP típico terá, no mínimo, três Mestres: Clientes, Itens e Contas. Esses dados mestre são, quase sempre, um dos principais ativos da empresa. Não é raro que a aquisição de uma empresa ocorra, em princípio, pelo acesso aos dados mestre de Clientes.

Definições rudimentares

Existem alguns tipos de dados mestre bem conhecidos e facilmente identificáveis, como "cliente" e "produto". Na verdade, muitos definem dados mestre simplesmente recitando uma lista de itens de dados mestre, comum a todos, como, por exemplo: cliente, produto, local, funcionário e ativo. Mas, saber como identificar os elementos de dados que devem ser administrados por um sistema de gerenciamento de dados mestre é muito mais complexo e desafia essas definições rudimentares. Na verdade, há muita confusão com relação à definição/qualificação dos dados mestre, e isso exige um tratamento mais abrangente.

Nas empresas existem, essencialmente, cinco tipos de dados:

• Não estruturados – Estes dados são encontrados nas mensagens eletrônicas, em artigos como este, nos artigos de revistas, portais intranet corporativos, nas especificações de produtos, no material de referência de marketing e nos arquivos em PDF
  
• Transacionais – Estes são os dados relativos a vendas, entregas, faturas, registros de problemas, reclamações e outras interações, monetárias ou não.
  
• Metadados – Estes são os dados sobre outros dados e podem residir em um repositório formal ou em várias outras formas como documentos em XML, definições de relatórios, descrições de colunas em um banco de dados, arquivos de log, conexões e arquivos de configuração.
  
• Hierárquicos – Os dados hierárquicos armazenam as relações entre outros dados. Podem ser armazenados como parte de um sistema contábil ou separadamente, como descrições das relações do mundo real, estruturas organizacionais ou linhas de produtos de uma empresa. Às vezes, os dados hierárquicos são considerados um superdomínio MDM, porque é crítico entender e, algumas vezes, descobrir, as relações entre os dados mestre.
  
• Mestre – Os dados mestre são nomes críticos de um negócio e, em geral, classificam-se em quatro grupos: pessoas, coisas, lugares e conceitos. Outras categorizações desses grupos são denominadas áreas de assunto, áreas de domínio ou tipos de entidade. Por exemplo, no grupo pessoas há clientes, funcionários e vendedores. Entre as coisas existem produtos, itens, armazéns e ativos. No grupo dos conceitos existem contratos, garantias e licenças. Por fim, entre os lugares existem as localizações dos escritórios e as divisões geográficas. Algumas dessas áreas de domínio podem ainda ser subdivididas. Os clientes podem ser segmentados com base nos incentivos e no histórico. Empresas podem ter clientes normais, assim como clientes de primeira linha e executivos. Os produtos podem ser segmentados por setor e indústria. Os requisitos, o ciclo de vida e o ciclo CRUD (Criar, Ler, Atualizar, Excluir) de um produto no setor CPG (bens de consumo embalados) são, provavelmente, muito diferentes daqueles da indústria do vestuário. A granularidade dos domínios é determinada, essencialmente, pela magnitude das diferenças entre os atributos de suas entidades.
  

Decidindo o que gerenciar

Embora identificar as entidades de dados mestre seja bastante simples, nem todos os dados que se enquadram na definição de dados mestre devem ser, necessariamente, gerenciados como tal. Este artigo limita a definição de dados mestre aos seguintes critérios, os quais devem ser considerados em conjunto, no momento de decidir se uma determinada entidade deve ser tratada como dados mestre.

Comportamento

Os dados mestre podem ser descritos pela forma com que interagem com outros dados. Por exemplo, em sistemas transacionais, os dados mestre estão, quase sempre, envolvidos com dados transacionais. Um cliente compra um produto. Um fornecedor vende um item e um parceiro entrega uma caixa de materiais em um local. Um funcionário está hierarquicamente subordinado ao seu gerente o qual, por sua vez, também está subordinado a um gerente (outro funcionário). Um produto pode ser um item de várias hierarquias que descrevem seu posicionamento em um armazém. Esta relação entre dados mestre e dados transacionais pode ser considerada, fundamentalmente, como uma relação verbo/substantivo. Os dados transacionais capturam os verbos, como vender, entregar, comprar, enviar um email e revogar; os dados mestre são os substantivos. Estes são os mesmos dados de relacionamento - fatos do depósito e compartilhamento de dimensões.

Ciclo de vida

Os dados mestre podem ser descritos pela forma com que são criados, lidos, atualizados, excluídos e pesquisados. Este ciclo de vida é chamado de ciclo CRUD e é diferente para diferentes tipos de elementos de dados mestre e empresas. Por exemplo, a criação de um cliente depende, em grande parte, das regras do negócio da empresa, do segmento da indústria e dos sistemas de dados. Uma empresa pode ter vários vetores para a criação de clientes: Internet, diretamente pelos representantes de conta ou por meio das lojas de varejo. Outra empresa talvez só permita a criação de clientes por meio de contato direto telefônico da central de chamadas. Além disso, a forma de criação de um elemento do cliente será, por certo, diferente da criação de um elemento do fornecedor. O quadro a seguir ilustra os vários ciclos CRUD de quatro áreas de assunto comuns de dados mestre.

Exemplo de ciclo CRUD

	Cliente	Produto	Ativo	Funcionário
Criar	Visita do cliente, como no site da Web ou nas instalações; conta criada	Produto comprado ou fabricado; envolvimento SCM	Unidade adquirida pela abertura de uma PO; processo de aprovação necessário	RH admite, vários formulários, orientação, seleção de benefícios, alocações de ativos, atribuições de escritórios
Ler	Visões contextualizadas com base nas credenciais do usuário	Catálogos periódicos do estoque	Objetivos periódicos de relatório, cálculo de depreciação, verificação	Acesso ao escritório, revisões, reclamações de seguros, imigração
Atualizar	Endereços, descontos, telefones, preferências, contas de crédito	Mudanças de embalagem, matérias-primas	Transferências, manutenção, relatórios de acidentes	Status de imigração, estado civil, promoções, aumentos, transferências
Destruir	Morte, falência, liquidação, não telefonar.	Cancelado, substituído, não está mais disponível	Obsoleto, vendido, destruído, roubado, sucateado	Rescisão, morte
Pesquisar	Sistema CRM, sistema de central de chamadas, sistema de gerenciamento de contatos	Sistema ERP, sistema de processamento de pedidos	Rastreamento do Razão, gerenciamento do BD de ativos	Sistema LOB RH

Cardinalidade

Quando a cardinalidade (número de elementos de um conjunto) diminui, a probabilidade de um elemento ser tratado como elemento de dados mestre (mesmo em uma área de assunto comumente aceita, como clientes) também diminui. Por exemplo, se uma empresa tiver apenas três clientes, provavelmente não os considerará como dados mestre de clientes (pelo menos, não no contexto de suportá-los com uma solução de gerenciamento de dados mestre), simplesmente porque não haverá benefício em gerenciar esses clientes com uma infra-estrutura de dados mestre. No entanto, uma empresa com milhares de clientes consideraria a área de assunto Cliente muito importante, devido às questões concomitantes e aos benefícios relacionados ao gerenciamento de tal conjunto de entidades de grande porte. O valor do cliente para cada uma dessas empresas é o mesmo. Ambas dependem de seus clientes para continuar no negócio. Só que uma delas precisa de uma solução de dados mestre de cliente; a outra não. A cardinalidade não altera a classificação de um determinado tipo de entidade; entretanto, a importância de ter uma solução para gerenciar um tipo de entidade aumentará, na medida em que aumenta a cardinalidade do tipo de entidade.

Vida útil

Os dados mestre tendem a ser menos voláteis do que os dados transacionais. Na medida em que ficam mais voláteis, são considerados, tipicamente, mais transacionais. Por exemplo, alguns podem considerar "contrato" um elemento de dados mestre. Outros, podem considerá-lo uma transação. Dependendo da duração de um contrato, as duas alternativas são viáveis. Uma agência promovendo atletas profissionais pode considerar seus contratos como dados mestre. São diferentes entre si e, de modo típico, têm duração superior a um ano. Pode ser tentador ter, simplesmente, um item de dados mestre chamado "atleta". Entretanto, os atletas podem ter mais de um contrato em um determinado momento: um com suas equipes e outros com as empresas patrocinadoras. A agência precisaria gerenciar todos esses contratos no decorrer dos respectivos prazos, na medida em que os elementos do contrato são renegociados ou os atletas negociados. Outros contratos (por exemplo, contratos com os detalhes de um carro ou a pintura de uma casa) parecem-se mais com uma transação. São contratos ocasionais, de curta duração, para a prestação de serviços contra pagamento e, em geral, são assinados e destruídos no período de poucas horas.

Complexidade

Entidades simples, mesmo as importantes, são raramente um desafio para gerenciar e, quase nunca, são consideradas elementos de dados mestre. Quanto mais simples for um elemento, haverá menos probabilidade de se gerenciar a mudança desse elemento. Em geral, esses ativos são simplesmente coletados e registrados. Por exemplo, a administração do Fort Knox provavelmente não rastreará as informações de cada barra de ouro ali armazenada; em lugar disso, manterá apenas a contagem dessas barras. O valor de cada barra de ouro é substancial, a cardinalidade elevada e a vida útil, longa; no entanto, a complexidade é baixa.

Valor

Quanto mais valioso for o elemento de dados para a empresa, maior será a probabilidade de ser considerado um elemento de dados mestre. Valor e complexidade trabalham juntos.

Volatilidade

Embora os dados mestre sejam tipicamente menos voláteis do que os transacionais, as entidades com atributos que nunca se alteram, não exigem, de modo geral, uma solução de dados mestre. Por exemplo, moedas raras pode parecer um item que atende a muitos dos critérios para tratamento de dados mestre. Um colecionador de moedas raras terá, provavelmente, muitas delas. Assim, a cardinalidade é elevada. São valiosas. E também, complexas. Como exemplo, as moedas raras possuem histórico e descrição. Existem atributos, como a condição de observação, o reverso, a legenda, a inscrição, a orla e o campo. Existem outros atributos, como as iniciais do projetista, o desenho da borda, as camadas e a figura.

No entanto, moedas raras não precisam ser gerenciadas como um item de dados mestre porque não se alteram com o passar do tempo - ou, pelo menos, não o suficiente. Talvez seja preciso acrescentar mais informações, na medida em que o histórico de uma determinada moeda seja revelado ou se for preciso corrigir certos atributos. Mas, de modo geral, as moedas raras não seriam gerenciadas por meio de um sistema de gerenciamento de dados mestre pois não são suficientemente voláteis para justificar uma solução.

Reuso

O reuso é um dos motivadores primários para o gerenciamento de dados mestre. Em outras palavras, por exemplo, o sistema CRM faria todo o gerenciamento de um cliente e nunca precisaria compartilhar quaisquer informações sobre esse cliente com outros sistemas. Todavia, nos ambientes complexos de hoje, as informações dos clientes precisam ser compartilhadas entre vários aplicativos. É nesse ponto que começam os problemas. Como, por vários motivos, ter acesso a um dado mestre nem sempre é possível, as pessoas começam a armazenar os dados mestre em vários locais, como nas planilhas e nos locais de armazenamento específicos dos aplicativos. Existem ainda outros motivos para gerenciar dados mestre não reutilizados pela empresa, tais como a degradação e a decomposição da qualidade dos dados. Entretanto, se uma entidade de dados mestre for reutilizada em vários sistemas, por certo será gerenciada por meio de um sistema de gerenciamento de dados mestre.

Para resumir, embora seja simples enumerar os vários tipos de entidades de dados mestre, algumas vezes é mais difícil decidir quais itens de dados de uma empresa devem ser tratados como dados mestre. Quase sempre, os dados que normalmente não se enquadram na definição de dados mestre podem precisar ser gerenciados como tal, e aqueles que se enquadram na definição, não. Em última análise, ao decidir sobre quais tipos de entidades devem ser tratados como dados mestre, é melhor classificá-los quanto ao comportamento e aos atributos no contexto das necessidades do negócio, do que confiar em simples listas de tipos de entidades.

Por que devo gerenciar dados mestre?

Porque são usados por vários aplicativos: um erro de dados mestre pode causar erros em todos os aplicativos que os estiverem utilizando. Por exemplo, um endereço incorreto no mestre de clientes poderá significar pedidos, faturas e folhetos de marketing enviados ao endereço errado. Da mesma forma, um preço incorreto no mestre de itens pode ser um desastre de marketing, assim como um número de conta incorreto no mestre de contas, pode causar multas enormes e até a prisão do CEO - um ponto final na carreira da pessoa que cometeu o erro!

Veja uma história de horror típica, relacionada a dados mestre: Um cliente de cartão de crédito muda-se da Rua 9 (Norte), 2847 para a Rua 11 (Norte), 1001. O cliente informou a mudança de endereço imediatamente, mas não recebeu sua fatura por muitos meses. Um dia, o cliente recebeu um telefonema ameaçador do departamento de cobranças do cartão de crédito perguntando o porquê de a fatura não ter sido paga. O cliente confirma se eles têm o endereço novo e o departamento de cobranças confirma que o endereço no arquivo é Rua 11 (Norte), 1001. O cliente pede uma cópia da fatura para liquidar a conta.

Depois de mais duas semanas sem receber a fatura, o cliente liga e descobre que a conta foi encaminhada a uma agência de cobranças. Desta vez, o pessoal descobre que, apesar de o endereço no arquivo estar correto, Rua 11 (Norte), 1001, o endereço de cobrança é Rua 11 (Norte), 101. Depois de muitos telefonemas e correspondências trocadas entre advogados, a pendência finalmente é resolvida e a empresa de cartão de crédito perdeu um cliente, para sempre. Neste caso, a cópia dos dados mestre estava certa, mas a outra cópia, errada. Os dados mestre precisam, ambos, estar corretos e consistentes.

Ainda que não haja erros nos dados mestre, poucas organizações têm apenas um conjunto de dados mestre. Muitas empresas crescem devido a fusões e aquisições. Cada empresa adquirida traz o próprio mestre de clientes, mestre de itens, etc. Este fato não seria ruim, se fosse possível juntar os dados mestre novos com os dados mestre atuais; entretanto, a não ser que a empresa adquirida seja de um ramo completamente diferente, em um país distante, há grande possibilidade de alguns clientes e produtos aparecerem nos dois conjuntos de dados mestre, os quais, em geral, estarão em formatos diferentes, com diferentes chaves de banco de dados. Se as duas empresas usarem o nome Dun & Bradstreet ou o número do seguro social como identificador do cliente, descobrir quais registros de cliente referem-se ao mesmo cliente será uma tarefa simples; mas, isso, raramente acontece. Na maioria dos casos, os números dos clientes e dos itens são atribuídos por software que cria os registros mestre e, assim, a probabilidade de o mesmo cliente ou o mesmo produto ter o mesmo identificador, nos dois bancos de dados, é bastante remota. A tarefa de reconciliar dados mestres de itens pode ser árdua, se partes equivalentes tiverem sido compradas de fornecedores diferentes, com números de fornecedores diferentes.

Mesclar listas mestre pode ser muito difícil. O mesmo cliente pode ter vários nomes, números de cliente, endereços e telefones em diferentes banco de dados. Um exemplo: William Smith pode aparecer como Bill Smith, Wm. Smith e William Smithe. Os comandos normais JOIN e SEARCH do banco de dados não conseguirão resolver essas diferenças. Para tanto, será preciso ter uma ferramenta sofisticada que entenda apelidos, grafias alternativas e erros de digitação. Essa ferramenta, provavelmente, terá de reconhecer que variações de nomes podem ser resolvidas, se todas estiverem no mesmo endereço ou tiverem o mesmo número de telefone. Ainda que criar uma lista mestre do zero seja um desafio assustador, uma lista mestre comum traz, ao final, muitos benefícios positivos:

• Faturamento consolidado, único, economiza dinheiro e aprimora a satisfação do cliente.
  
• Enviar o mesmo folheto de marketing a um cliente que esteja em várias listas de clientes desperdiça dinheiro e irrita o cliente.
  
• Antes de encaminhar uma conta de cliente a uma agência de cobranças, seria bom saber se ele também é devedor em outros departamentos da empresa ou, mais importante, se não é o maior cliente de outro departamento.
  
• Ter em estoque o mesmo item com números diferentes não apenas é um desperdício de dinheiro e de espaço em prateleira, mas também pode, em potencial, resultar em faltas de estoque artificiais.
  

Os movimentos recentes na direção de SOA e SaaS fazem do Gerenciamento de Dados Mestre uma questão crucial. Por exemplo, se criar um único atendimento ao cliente que se comunica por meio de mensagens XML bem definidas, você poderá pensar que definiu uma visão única de seus clientes. Mas, se o mesmo cliente estiver presente em cinco bancos de dados com três endereços e quatro telefones diferentes, qual será a resposta do atendimento ao cliente? Similarmente, se decidir assinar um serviço CRM fornecido por meio de SaaS, o prestador de serviço precisará de uma lista de clientes do banco de dados. Você mandará a lista de qual banco de dados?

Por todos esses motivos, manter o conjunto de dados mestre de sua empresa, consistente, de alta qualidade, torna-se, rapidamente, uma necessidade. Os sistemas e os processos necessários para a manutenção desses dados são conhecidos como Gerenciamento de Dados Mestre.

O que é gerenciamento de dados mestre?

Para os fins deste artigo, definimos Gerenciamento de Dados Mestre (MDM) como a tecnologia, as ferramentas e os processos necessários para criar e manter listas de dados mestre, consistentes e precisos. Há dois itens nessa definição que precisam ser destacados. Primeiro: MDM não é apenas um problema tecnológico. Em muitos casos, alterações fundamentais no processo do negócio serão necessárias para a manutenção de dados mestre limpos e, algumas das questões MDM mais difíceis são mais políticas do que técnicas. O segundo item a ser observado é que o MDM trata da criação e da manutenção de dados mestre. O investimento em tempo, dinheiro e esforço na criação de um conjunto de dados mestre, limpo e consistente, será um desperdício se a solução não incluir ferramentas e processos que mantenham os dados mestre limpos e consistentes, na medida em que são atualizados e ampliados.

Embora o MDM seja mais eficiente quando aplicado a todos os dados mestre da empresa, em muitos casos, o risco e o custo de um esforço aplicado a toda a empresa são difíceis de justificar. Pode ser mais fácil começar com alguns recursos principais de Dados Mestre e ampliar o esforço, depois que o sucesso esteja demonstrado e as lições aprendidas. Se for começar pequeno, deve pensar em analisar todos os dados mestre que talvez queira incluir, para não tomar decisões de projeto ou escolher ferramentas que o forçarão a recomeçar quando tentar incorporar uma nova fonte de dados. Por exemplo, se a sua implementação inicial do mestre de Clientes inclui apenas os 10.000 clientes com os quais trabalha a equipe de vendas diretas, você não quererá tomar decisões que o impossibilitarão de acrescentar, mais tarde, os 10.000.000 de clientes da Web.

Um plano de projeto MDM sofrerá as influências de requisitos, prioridades, disponibilidade de recursos, prazo e do tamanho do problema. A maior parte dos projetos de MDM compreende estas fases, como mínimo:

1. Identificar as fontes de dados mestre. Esta etapa é, usualmente, um exercício bastante revelador. Algumas empresas descobrem que possuem dúzias de bancos de dados, com dados de clientes, cuja existência o departamento de TI desconhecia.
   
2. Identificar os produtores e os consumidores dos dados mestre. Quais aplicativos produzem os dados mestre identificados na primeira etapa e - em geral mais difícil de determinar - quais aplicativos usam os dados mestre. Dependendo da abordagem usada na manutenção dos dados mestre, esta etapa talvez não seja necessária. Por exemplo, se todas as alterações forem detectadas e tratadas no nível do banco de dados, provavelmente não terá importância saber de onde vêm essas alterações.
   
3. Coletar e analisar os metadados sobre os dados mestre. Para todas as fontes identificadas na primeira etapa, quais são as entidades e os atributos dos dados e o que significam? Incluem-se o nome do atributo, o tipo de dados, os valores aceitos, as restrições, os valores padrão, as dependências e o proprietário da definição e da manutenção dos dados. O proprietário é o mais importante e, quase sempre, o mais difícil de determinar. Se houver um repositório carregado, com todos os metadados, esta etapa será de fácil execução. Se, entretanto, for preciso começar com base nas tabelas do banco de dados e no código-fonte, esta etapa poderá representar um esforço significativo.
   
4. Indicar os administradores dos dados. Deverão ser indivíduos com conhecimento dos atuais dados-fonte e capazes de determinar como transformar a fonte no formato de dados mestre. Em geral, os administradores deverão ser indicados pelos proprietários de cada fonte de dados mestre, arquitetos responsáveis pelos sistemas MDM e representantes dos usuários dos dados mestre no negócio.
   
5. Implementar um programa de governança dos dados e um conselho para a governança dos dados. Este grupo deve ter o conhecimento e a autoridade para tomar decisões sobre como os dados mestre devem ser mantidos, o que contêm, por quanto tempo serão mantidos e como as alterações serão autorizadas e auditadas. Centenas de decisões devem ser tomadas no decorrer de um projeto de dados mestre e, se não houver um organismo e um processo para a tomada de decisões, bem definidos, o projeto poderá falhar porque a política impede uma tomada de decisão efetiva.
   
6. Desenvolver o modelo de dados mestre. Decidir qual a aparência dos registros mestre: quais atributos estão incluídos, de que porte e tipo são os dados, quais valores são aceitos, etc. Esta etapa deve incluir, também, o mapeamento entre o modelo de dados mestre e as atuais fontes de dados. Normalmente, esta é a etapa mais importante e a mais difícil do processo. Se você tentar contentar a todos, incluindo todos os atributos-fonte na entidade mestre, acabará, quase sempre, com dados mestre muito complexos e complicados para serem úteis. Por exemplo, se não conseguir decidir se o peso deve ser apresentado em libras ou quilos, uma alternativa poderia ser incluir ambos (WeightLb e WeightKg). Ainda que esta alternativa satisfaça a todos, você estará desperdiçando megabytes de armazenamento com números que podem ser calculados em microssegundos e, também, correndo o risco de criar dados inconsistentes (WeightLb = 5 e WeightKg = 5). Embora este seja um exemplo bastante trivial, uma questão maior seria manter vários números de itens para o mesmo produto. Como em qualquer esforço de comissão, haverá brigas e negociações que resultarão em decisões de qualidade inferior. É importante definir, antecipadamente, o processo de decisão, as prioridades e o tomador de decisão final, para garantir a execução do processo sem sobressaltos.
   
7. Escolher um conjunto de ferramentas. Será preciso comprar ou construir ferramentas para criar as listas mestre limpando, transformando e mesclando os dados-fonte. Além disso, será preciso uma infra-estrutura para usar e manter a lista mestre. Mais adiante, neste artigo, estas funções são abordadas em detalhes.
   Você poderá usar um único conjunto de ferramentas, de um mesmo fornecedor, para todas essas funções, ou talvez queira adotar uma abordagem de best-of-breed (a melhor ferramenta para cada função). Em geral, as técnicas para limpar e mesclar dados são diferentes, para diferentes tipos de dados; assim, não há muitas ferramentas que atendam a todo espectro dos dados mestre. As duas principais categorias são as ferramentas que integram os dados do cliente (CDI) para criação do mestre de clientes e as ferramentas de gerenciamento de informações de produto (PIM) para criação do mestre de produtos. Algumas ferramentas executarão as duas tarefas mas, em geral, são melhores em uma das tarefas, apenas.
   O conjunto de ferramentas deve ter, ainda, suporte para localização e reparo de problemas com a qualidade dos dados e também manutenção de versões e hierarquias. O controle de versões é um recurso crítico, pois entender o histórico de um registro de dados mestre é vital para a manutenção de sua qualidade e precisão no decorrer do tempo. Por exemplo, se uma ferramenta para mesclagem combinar dois registros de John Smith em Boston e se você decidir que realmente existem duas pessoas diferentes com esse nome, nessa cidade, você precisará saber como eram os registros antes de serem mesclados, para conseguir desfazer essa ação.
   
8. Projetar a infra-estrutura. Depois de os dados mestre estarem limpos e consistentes, você precisará colocá-los à disposição de seus aplicativos e providenciar processsos para a sua administração e manutenção. Esta etapa é uma questão bastante grande e, por isso, dedico uma seção inteira ao assunto, mais adiante neste documento. Depois que esta infra-estrutura estiver implementada, você terá vários aplicativos que dependerão de sua disponibilidade; assim, confiabilidade e escalabilidade são considerações importantes a serem incluídas no seu projeto. Na maioria dos casos, você mesmo terá de implementar partes significativas da infra-estrutura, porque ela será projetada para adequar-se à infra-estrutura, às plataformas e aos aplicativos atuais.
   
9. Gerar e testar os dados mestre. É nesta etapa que você usará as ferramentas desenvolvidas ou compradas para mesclar os dados-fonte na lista de dados mestre. Em geral, este é um processo iterativo que exige explorar regras e configurações para chegar na correspondência correta. Este processo também exige grande volume de inspeção manual para confirmar se os resultados estão corretos e se atendem aos requisitos estabelecidos para o projeto. Nenhuma ferramenta conseguirá a correspondência correta, todas as vezes; assim, será preciso ponderar as conseqüências entre correspondências falsas vs correspondências perdidas, para determinar como configurar essas ferramentas. Correspondências falsas podem levar à insatisfação do cliente, se as faturas estiverem imprecisas ou se a pessoa errada for presa. Se houver grande volume de correspondências perdidas os dados mestre terão menor utilidade, e você não obterá os benefícios esperados do investimento em MDM.
   
10. Modificar os sistemas de produção e de consumo. Dependendo de como a sua implementação MDM estiver projetada, talvez seja preciso modificar os sistemas que produzem, mantêm ou consomem dados mestre para trabalhar com a nova fonte de dados mestre. Se os dados mestre são usados em um sistema independente dos sistemas-fonte - um data warehouse, por exemplo - os sistemas-fonte talvez não tenham de ser modificados. Entretanto, se os sistemas-fonte forem usar os dados mestre, mudanças serão provavelmente necessárias. Os sistemas-fonte terão de acessar novos dados mestre ou estes terão de estar sincronizados com os sistemas-fonte, para que estes últimos tenham uma cópia dos dados mestre limpos para uso. Se não for possível alterar um ou mais sistemas-fonte, este talvez não consiga usar os dados mestre ou estes últimos terão de estar integrados ao banco de dados do sistema-fonte por meio de processos externos, como gatilhos e comandos SQL.
    Os sistemas-fonte que geram novos registros devem ser modificados para procurar conjuntos de registros mestre existentes, antes de criar novos registros ou de atualizar os registros mestre existentes. Este procedimento confirma que a qualidade dos dados gerados na fonte é boa e, assim, o MDM poderá funcionar de modo mais eficiente e o próprio aplicativo gerenciará a qualidade dos dados. O MDM deve ser aproveitado não apenas como um sistema de registros, mas também como um aplicativo que possibilita a manipulação de dados, de modo mais eficiente e limpo, em todos os aplicativos da empresa. Como parte da estratégia de MDM, os três pilares do gerenciamento de dados precisam ser investigados quanto a origem, ao gerenciamento e ao consumo dos dados. Não é possível ter uma estratégia MDM robusta, em nível de empresa, se qualquer desses aspectos for ignorado.
    
11. Implementar os processos de manutenção. Como declaramos anteriormente, qualquer implementação de MDM deve incorporar ferramentas, processos e pessoas para manter a qualidade dos dados. Todos os dados devem ter um administrador, que será responsável por garantir a qualidade dos dados mestre. Em geral, o administrador dos dados será uma pessoa que trabalha no negócio, com conhecimento dos dados, que possa reconhecer dados incorretos e que tenha conhecimento e autoridade para corrigir as falhas. A infra-estrutura do MDM deverá incluir ferramentas que ajudem o administrador dos dados no reconhecimento das falhas, simplificando as correções. Uma boa ferramenta para a administração dos dados deve indicar as correspondências questionáveis realizadas: clientes com nomes diferentes e números de cliente que têm o mesmo endereço, por exemplo. O administrador talvez também queira revisar os itens acrescentados como novos, porque os critérios de correspondência estavam próximos, mas abaixo do limiar. É importante que o administrador de dados consulte o histórico das alterações feitas nos dados pelos sistemas MDM para isolar a fonte de erros e para desfazer alterações incorretas. A manutenção também inclui os processos para 'arrastar' as mudanças e as adições para o sistema MDM, e para distribuir os dados limpos nos lugares certos.
    

Como se vê, o MDM é um processo complexo que pode durar um tempo longo. Como muitas coisas em software, implementar o MDM gradualmente é a chave do sucesso, para que o negócio possa realizar uma série de benefícios a curto prazo, já que o projeto completo é um processo a longo prazo. Nenhum projeto de MDM poderá ter êxito sem o suporte e a participação dos usuários do negócio. Os profissionais de TI não conhecem o domínio para criar e fazer a manutenção de dados mestre de alta qualidade. Projetos de MDM que não incluam modificações nos processos que criam, mantêm e validam, correm o risco de fracassar como dados mestre. O restante deste artigo abordará os detalhes da tecnologia e dos processos para criar e fazer a manutenção dos dados mestre.

O que fazer para criar uma lista mestre?

Quer você compre uma ferramenta ou decida desenvolver uma própria, existem duas etapas básicas para a criação de dados mestre: limpar e padronizar os dados e fazer a correspondência de dados provenientes de todas as fontes para consolidar as duplicidades. Antes de começar a limpar e normalizar os dados, é preciso entender o modelo de dados para os dados mestre. Como parte do processo de modelagem, os conteúdos de cada atributo foram definidos e um mapeamento foi definido de cada sistema-fonte para o modelo dos dados mestre. Estas informações são usadas para definir as transformações necessárias para limpar os dados-fonte.

Limpar os dados e transformá-los em modelo de dados mestre é muito similar aos processos Extrair, Transformar e Carregar (ETL) usados para preencher um data warehouse. Se você já tem ferramentas ETL e a transformação definida, pode ser mais fácil apenas modificá-las, conforme o necessário para os dados mestre, do que aprender uma nova ferramenta. Abaixo, algumas funções típicas da limpeza de dados:

• Normalizar os formatos de dados. Deixar os números de telefone com a mesma aparência, colocar os endereços, etc. no mesmo formato.
  
• Substituir valores faltantes. Inserir os valores padrão, procurar os CEPs dos endereços, verificar o número da Dun & Bradstreet.
  
• Padronizar valores. Converter todas as medidas para o sistema métrico, os preços para a mesma moeda, modificar os números de itens de acordo com um padrão industrial.
  
• Atributos de mapa. Analisar o nome e o sobrenome de um campo de nome de contato, mover o Nº do item e o partno para o campo PartNumber. >
  

A maior parte das ferramentas limpará os dados possíveis, colocando o restante em uma tabela de erros para processamento manual. Dependendo da forma de trabalho da ferramenta que faz a correspondência, os dados limpos serão colocados em uma tabela mestre ou em uma série de tabelas de teste. Na medida em que cada fonte é limpa, a saída deverá ser examinada para confirmar se o processo de limpeza está trabalhando corretamente.

Fazer a correspondência dos registros de dados mestre para eliminar duplicidades é a etapa mais difícil mas, também, a mais importante para a criação dos dados mestre. Correspondências falsas podem, de fato, perder dados (duas empresas Acme serem transformadas em uma só, por exemplo), assim como correspondências perdidas reduzem o valor de se manter uma lista comum. A precisão da correspondência das ferramentas MDM é um dos mais importantes critérios de compra. Algumas correspondências são bem simples de se fazer. Se todos os clientes tiverem o número do seguro social ou se todos os produtos utilizarem um esquema de numeração comum, o comando JOIN do banco de dados fará a maior parte das correspondências. Isso quase nunca acontece no mundo real; todavia, os algoritmos de correspondência também são, normalmente, muito complexos e sofisticados. A correspondência para identificação dos clientes pode ser feita pelo nome, nome de solteira, apelido, endereço, telefone, número do cartão de crédito, etc.; já para os produtos, pode-se usar nome, descrição, número do item, especificações e preço. Quanto maior e mais próximo for o grau de correspondência dos atributos, maior será o grau de confiança que o sistema MDM terá nessa correspondência. Este fator de confiança é calculado para cada correspondência e, se ultrapassar um determinado limiar, haverá correspondência entre os registros. Normalmente, o limiar é ajustado de acordo com as conseqüências de uma correspondência falsa. Por exemplo, é possível especificar que, se o nível de confiança for superior a 95%, os registros serão automaticamente mesclados e se ficar entre 80% e 95%, o administrador dos dados deverá aprovar a correspondência, antes da mesclagem.

A maior parte das ferramentas mescla um conjunto de entradas na lista mestre e, assim, o melhor procedimento é iniciar a lista com os dados mais confiáveis e, em seguida, mesclar as outras fontes, uma de cada vez. Se houver um grande volume de dados com muitos problemas, este processo pode levar muito tempo. Talvez seja preciso começar com os dados dos quais espera-se obter mais benefícios após sua consolidação; execute um projeto piloto com esses dados, para confirmar se seus processos funcionam e se é possível observar os benefícios esperados para o negócio; depois, conforme permitirem prazo e recursos, acrescente as outras fontes. Esta abordagem significa que o seu projeto será mais demorado e, possivelmente, custará mais, mas o risco será menor. Além disso, possibilitará começar com poucas organizações e acrescentar outras, na medida em que o projeto se comprove bem-sucedido, em lugar de tentar colocar tudo no mesmo barco, desde o início.

Privacidade é outro fator a ser considerado ao mesclar os dados-fonte na lista mestre. As informações dos clientes que fazem parte do mestre de podem ficar visíveis a qualquer dos aplicativos que tenham acesso a esse mestre. Se os dados dos clientes tiverem sido obtidos conforme termos de política de privacidade que limita o uso a um determinado aplicativo, você talvez não consiga fazer a mesclagem no mestre de clientes. Se a equipe de planejamento de MDM puder contar com um advogado, será muito bom.

Neste ponto, se sua meta era elaborar uma lista de dados mestre, tudo ok! Basta imprimi-la ou gravá-la em um CD e seguir adiante. Se quiser manter os dados mestre atualizados, sempre que houver acréscimos ou modificações, terá de desenvolver infra-estrutura e processos para gerenciá-los com o passar do tempo. A próxima seção oferece algumas opções sobre como fazer isso, exatamente.

Como fazer a manutenção de uma lista mestre?

Existem muitas ferramentas e técnicas diferentes para gerenciar e usar dados mestre. Neste artigo, abordaremos três dos cenários mais comuns:

• Abordagem de cópia única – Neste caso, há apenas uma cópia mestre dos dados mestre. Todas as adições e alterações são feitas diretamente nos dados mestre. Todos os aplicativos que usam os dados mestre são reescritos para usar os novos dados em lugar de seus dados atuais. Esta abordagem garante a consistência dos dados mestre, mas na maioria dos casos não é prática. Modificar todos os aplicativos para usar uma nova fonte de dados com esquema e dados diferentes é, no mínimo, mais caro; se alguns de seus aplicativos forem comprados, isso talvez seja impossível.
  
• Várias cópias, manutenção única – Neste caso, os dados mestre são acrescentados ou alterados na única cópia mestre dos dados, mas as alterações são enviadas aos sistemas-fonte nos quais as cópias ficam armazenadas localmente. Cada aplicativo poderá atualizar as partes dos dados que não fazem parte dos dados mestre, mas não poderá alterar ou adicionar dados mestre. Por exemplo, o sistema de inventário poderá alterar as quantidades e o local dos itens, mas novos itens não poderão ser adicionados, assim como os atributos incluídos no mestre de produtos não poderão ser alterados. Este procedimento reduz o número de alterações que serão necessárias nos aplicativos, mas estes precisarão desativar um mínimo de funções que acrescentam ou atualizam os dados mestre. Os usuários precisarão aprender novos aplicativos para acrescentar ou modificar dados mestre e algumas das coisas que normalmente fazem, não funcionarão mais.
  
• Mesclagem contínua – Neste caso, os aplicativos podem alterar as respectivas cópias dos dados mestre. As alterações feitas nos dados-fonte são enviadas ao mestre, onde são mescladas na lista mestre. Depois, as alterações do mestre são enviadas aos sistemas-fonte e aplicadas às cópias locais. Esta abordagem exige poucas alterações nos sistemas-fonte; se necessário, a propagação da mudança poderá ser feita no banco de dados e, assim, não haverá alteração de nenhum código do aplicativo. Numa primeira análise, esta parece ser a solução ideal. As alterações nos aplicativos ficam minimizadas e não será necessário nenhum novo treinamento. Todos continuam a fazer o que estavam fazendo, mas com mais qualidade e com dados mais completos. Esta abordagem tem vários problemas:
  
  • Possibilidade de conflitos de atualização e dificuldade de reconciliação. O que acontecerá se dois sistemas-fonte alterarem o endereço de um cliente para valores diferentes? Não há forma de o sistema MDM decidir qual deles deve ser mantido e, assim, será preciso que o administrador dos dados intervenha; durante esse impasse, o cliente fica com dois endereços diferentes. Casos como este devem ser resolvidos pela criação de regras para a governança dos dados e de procedimentos operacionais padrão para garantir a redução ou a eliminação dos conflitos de atualização.
    
  • Adições devem ser novamente mescladas. Quando um cliente é adicionado, existe a possibilidade de outro sistema já ter adicionado o cliente. Para resolver esta situação, todas as adições de dados devem passar novamente pelo processo de correspondência, para evitar novas duplicidades no mestre.
    
  • Fica mais difícil manter valores consistentes. Se o peso de um produto for convertido de libras em quilos e, depois, para libras novamente, o arredondamento poderá alterar o peso original. Este fato pode ser frustrante para o usuário que digita um valor e, segundos depois, observar que ele se modifica.
    

Em geral, tudo isso pode ser planejado e resolvido, facilitando um pouco a vida do usuário, ao custo de uma infra-estrutura de manutenção mais complicada e de mais trabalho para os administradores de dados. Esta pode ser uma troca aceitável, mas deve ser feita de modo consciente.

Controle de versões e auditoria

Independentemente da forma com que os dados mestre são gerenciados, é importante saber como os dados ficaram nesse estado. Por exemplo, se um registro de cliente tiver sido consolidado com base em dois registros mesclados, diferentes, será preciso saber como eram os registros originais, caso o administrador de dados determine que os registros foram mesclados por engano e, de fato, deveriam ser dois clientes diferentes. O gerenciamento de versões deve ter uma interface simples, para exibir as versões e reverter toda a mudança, ou apenas parte dela, para uma versão anterior. A ramificação normal das versões e o agrupamento das alterações usadas pelos sistemas de controle de fonte também podem também ser muito úteis para a manutenção das diferentes alterações de derivação e reversão dos grupos de alterações para uma ramificação anterior.

A administração dos dados e o cumprimento dos requisitos quase sempre incluirão uma forma de determinar quem fez e quando foi feita cada alteração. Para ser compatível com esses requisitos, o sistema MDM deve ter um recurso de auditoria das modificações dos dados mestre. Além de manter um log de auditoria, o sistema MDM deve ter uma forma simples de localizar a alteração específica procurada. Os sistemas MDM podem auditar diariamente milhares de alterações e, por isso, os recursos de pesquisa e de emissão de relatórios do log de auditoria são muito importantes.

Gerenciamento de hierarquias

Além dos próprios dados mestre, o sistema MDM deve manter as hierarquias de dados - por exemplo, lista de materiais dos produtos, estrutura do território de vendas, estrutura da organização dos clientes, etc. É importante que o sistema MDM faça a captura dessas hierarquias, mas é também útil que ele possa modificar as hierarquias independentemente dos sistemas de base. Por exemplo, quando um funcionário é transferido para um centro de custo diferente, pode haver impactos nos sistemas de viagens e reembolso de despesas, folha de pagamento, relatório de horas, estruturas de relatórios e gerenciamento de desempenho. Se o sistema MDM gerenciar hierarquias, e se houver alteração na hierarquia, ainda que em uma única posição, essa alteração poderá ser propagada para todos os sistemas de base. Talvez também haja motivos para manter hierarquias no sistema MDM que não existam nos sistemas-fonte. Por exemplo, receitas e despesas talvez precisem ser agregadas no território ou nas estruturas organizacionais que não existem em qualquer sistema-fonte simples. O planejamento e a previsão também podem exigir hierarquias temporárias para calcular valores "what if" para as alterações organizacionais propostas. Em muitos casos, as hierarquias históricas também são necessárias para agregar informações financeiras em estruturas que existiram no passado, mas não na estrutura atual. Por esses motivos, é muito importante ter no sistema MDM um recurso de gerenciamento de hierarquia, flexível e poderoso.

Conclusão

A ênfase recente no cumprimento dos regulamentos, na SOA e nas fusões e aquisições transformou a criação e a manutenção de dados mestre, precisos e completos, em um imperativo do negócio. Negócios de pequeno e grande portes devem desenvolver processos e procedimentos para a manutenção e a governança dos dados, para obter e manter dados mestre exatos. Embora seja fácil pensar no gerenciamento de dados mestre como uma questão tecnológica, uma solução puramente tecnológica, sem as correspondentes alterações nos processos e nos controles do negócio, provavelmente deixará de produzir resultados satisfatórios. Este artigo abordou as razões para adotar o gerenciamento de dados mestre, o processo de desenvolvimento de uma solução e as várias opções para a implementação tecnológica da solução. Artigos futuros desta série explicarão as questões tecnológicas e de procedimento que devem ser resolvidas para implementar um sistema MDM.