Como você imagina a internet?

Manifesto for Software Craftsmanship

http://manifesto.softwarecraftsmanship.org/

Simply Explained

Seven Impossible Days

JavaOne

Steve Vai - In My Dreams With You

The Story of Cosmetics

Insertion Sort

import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class AlgorithmTestCase {

        protected Logger logger = LoggerFactory.getLogger(getClass());

        @Test
        public void insertionSortTest() {
                final int[] array = { -9, 9, 8, 7, 6, 5, 4, -8, 3, 2, 1, 0, 8945121 };

                int[] order = insertionAscSort(array);
                show(order);

                final int[] desc = insertionDescSort(array);
                show(desc);
        }

        private final int[] insertionAscSort(int[] array) {

                int i, j, elemento;

                for (i = 1; i < array.length; i++) {

                        elemento = array[i];

                        for (j = i - 1; j >= 0 && array[j] > elemento; j--) {
                                array[j + 1] = array[j];
                                array[j] = elemento;
                        }

                }

                return array;
        }

        private final int[] insertionDescSort(int[] array) {

                int i, j, elemento;

                for (i = 1; i < array.length; i++) {

                        elemento = array[i];

                        for (j = i - 1; j >= 0 && array[j] < elemento; j--) {
                                array[j + 1] = array[j];
                                array[j] = elemento;
                        }

                }

                return array;
        }

        private final void show(int[] array) {
                logger.info("Result");
                for (int i = 0; i < array.length; i++) {
                        logger.info("Array: " + array[i]);
                }
        }

}

Escassez de Comida

Venha Tesouro...

Não se misture com essa gentalha!

so ya thought ya might like to go to the show

The "Java Life" Rap Music Video - JavaOne 2011

The Ecstasy of Gold by Ennio Morricone

Computação Soberana

Neide tem 14 anos.

Depois da escola, antes de ir trabalhar com a irmã, ela passa no telecentro da Vila Tiradentes e vê que 11 pessoas já acessaram os serviços soberanos que ela tinha colocado no ar, no dia anterior.

Ela não tem micro em casa, muito menos internet rápida e nem dinheiro para alugar hospedagem de site. Por isso, ela antes usava um hospedeiro gratuito de sites estáticos chamado GeoCities, que faturava colocando propaganda no site dela.

Ela tem um colega de classe, porém, o Pedro, cujo pai tem micro e internet rápida na lojinha da qual é dono. Juntando o Pedro e mais 4 amigos, que ela conheceu através da rede, ela conseguiu, ao todo, uns 7MHz de processamento e uns 20MB da espaço em HD.

Na verdade, ela conseguiu o dobro disso, mas cedeu a outra metade ao Gladson, ao Maicon e à Carla, outros três pequenos freqüentadores do telecentro. São mais novos que a Neide e ela está ensinando a eles os primeiros passos na informática.

A estória da Neide está só começando.



Antes
=========

Antes de alcançarem Soberania de Computação, as pessoas chegavam a receber centenas de mensagens indesejadas por dia, contendo vírus, correntes, propaganda e outras tranqueiras. Era o famigerado "spam".

Havia, também, na maioria das páginas da Web, animações de propaganda perturbando os internautas, que, naquela época, tinham que se conformar com aquilo.

As pessoas eram obrigadas a fazer cópias freqüentes de todos seus arquivos em mídias removíveis, como disquetes ou CDs. Isso era chamado de "backup". Por excesso de confiança em suas HDs, muitos perderam toda uma vida de fotos digitais, trabalhos, mensagens, contatos e músicas.

Para poder participar da internet, as pessoas tinham que pagar um "provedor" e obter um tal de "endereço IP", arbitrariamente distribuído por um órgão controlador.

Para manterem-se em contato, as pessoas viviam mandando e recebendo eMails pentelhos de "Anotem aí meu novo celular" ou "Anotem aí meu novo endereço de eMail".

EMails, por sinal, eram mensagens que as pessoas mandavam, sem estarem codificadas, por incrível que pareça, através de intermediários chamados de "provedores", ou seja, sem a menor garantia de privacidade. E pagavam por isso.

Muitos ainda deixavam seus eMails particulares hospedados em servidores de "WebMail", correndo o risco de ter sua privacidade invadida pela patota de operadores do sistema ou de ter seus eMails perdidos por eles, de uma hora pra outra.

Quando faziam buscas na internet, em vez de receberem primeiro as páginas mais relevantes para elas, as pessoas recebiam primeiro as páginas que o site de buscas, por exemplo um tal de "Google", considerava ser as mais relevantes.

As pessoas que compartilhavam músicas, filmes e outros arquivos, através de sisteminhas "peer-to-peer", chegavam a esperar dias para baixar um filme e ainda tinham que ficar garimpando numa torrente de arquivos bichados, falsos e incompletos.

Com capacidade de expressão limitada a insípidos "blogs", a maioria das pessoas era mera consumidora de informação produzida por terceiros e enlatada pelos auto-denominados "provedores de conteúdo".

Aqueles que só usavam um determinado sistema de mensagens instantâneas eram incapazes de comunicar-se com aqueles que usavam qualquer outro sistema. "ICQ" e "MSN" eram alguns dos que existiam na época. Muitas pessoas trabalhavam com vários desses sistemas, abertos ao mesmo tempo, para poder conversar com todos seus amigos.

Alguns participavam de redes de relacionamento rudimentares, como o "Orkut" e o "LinkedIn". Eram limitadas, não se comunicavam entre si e, por serem baseadas em sites centralizados, ofereciam os mesmos riscos de confiabilidade e violação de privacidade que os servidores de WebMail.

Se, em vez de usar servidores alheios, alguém quisesse colocar seu próprio servidor na internet, com um nome de "domínio" próprio, era obrigado a pagar, todo ano, mais uma taxa arbitrária. Caso seu nome de domínio já tivesse sido escolhido, esse alguém tinha que se conformar e escolher outro.

Para colocar no ar um site seguro, as pessoas eram obrigadas a comprar "certificados digitais" de alguma dentre meia-dúzia de empresas, como a "Verisign" ou a "Certisign". Todo mundo, através dos cadeadinhos em seus browsers, confiava cegamente nessas empresas, as donas da verdade.

A maioria das pessoas se refugiava na ignorância. Algumas, inseridas naquele contexto deprimente, chegaram a criar para si uma ilusão de liberdade, uma liberdade paleativa chamada "Software Livre".

Usuários de Software Livre ou não, portanto, todos não passavam de súditos. Subjugados por um punhado de "autoridades" da internet, conformavam-se às leis arbitrárias, ditadas por elas.



A Virada
===========

Aí, as pessoas cansaram dessa palhaçada.

Decidiram que seriam livres para compartilhar informação e recursos de hardware com seus amigos, da forma como bem entendessem.

Essa liberdade ficou conhecida como soberania de computação.



Depois
==========

Além de simplesmente eliminar todas as mazelas acima, a computação soberana abriu, ainda, uma série de possibilidades com as quais as pessoas sequer sonhavam.

Organizações, famílias e grupos de afinidade em geral abandonaram as patéticas "listas de discussão" baseadas em eMail e passaram a compartilhar bases de informação extremamente ricas, intricadas e amigáveis.

Não era mais necessário ficar manualmente atribuindo e revogando direitos de acesso para cada usuário de sistemas restritos. Os administradores de sistemas foram liberados para fazer coisas mais úteis.

Tornou-se trivial trabalhar em conjunto com outras pessoas, compartilhando projetos on-line, sem ter que ficar mandando eMails pra lá e pra cá, duplicando versões e mais versões de "documentos" anexos.

As pessoas passaram a usar a internet, não apenas como ferramenta de comunicação com seus contatos, mas também como forma de expressão. Extrapolando os limites dos "blogs", todas as pessoas passaram a ter voz influente, ouvida por suas comunidades na internet, sem depender de provedores ou hospedeiros.


Quando alcançaram soberania de computação, portanto, as pessoas tomaram para si o direito de livre publicação. Completou-se, assim, o ciclo iniciado por Gutenberg, quinhentos anos antes, quando deu às pessoas o livre acesso à informação.

Depois dos devidos ajustes legislativos em seus países, as pessoas passaram a fazer compras e estabelecer crédito usando moedas eletrônicas que elas próprias emitiam. Cada pessoa passou a ser sua própria casa da moeda, recuperando a autonomia do escambo, perdida milhares de anos antes.

Qualquer pessoa passou a ser capaz de, com um único clique de mouse, hospedar qualquer serviço em sua máquina, para ser acessado por ela e por seus amigos; e esses serviços permaneciam no ar, mesmo quando essa pessoa desligava sua máquina.



Como?
==========

O acima é a história que vamos contar para nossos filhos e netos. Então, serão comuns estórias como a da Neide que, por enquanto, é somente um flash do futuro.

Vou mostrar que, retomando algumas liberdades simples, que temos no mundo real mas perdemos no mundo virtual, viver essa nova realidade é apenas uma questão de tempo. Por ser uma experiência extremamente gostosa, não é de muito tempo que estamos falando.

"Estamos falando de um novo software? Uma nova tecnologia?"

Sim, mas não só isso. É muito mais simples e muito mais abrangente que isso. É de uma nova atitude que estamos falando. É o querer "Ser livre para compartilhar informação e recursos de hardware com os amigos.".

Quando alcançarmos essa liberdade, teremos alcançado soberania de computação.


>>Liberdade para Compartilhar Informação e Recursos de Hardware com os Amigos<<


"Tá, e daí? Como vamos alcançar essa liberdade?"

Aos poucos.


Primeira Liberdade: Nome Próprio
------------------------------------

Você deve ser livre para escolher para si um nome, qualquer nome.

Não precisa ser um nome esquisito do tipo "jose sem acento underscore da underscore silva arroba iarrú ponto com ponto bê erre". Pode ser "José da Silva", com direito a acento, espaços, letras maiúsculas e tudo.

E não precisa ser um nome novo, exclusivo, inédito. Se você mudasse seu nome, só porque algum imbecil dissesse que já existe um José da Silva cadastrado no sistema dele, você não seria soberano. Você seria um merda.

E também não precisa ser um nome definitivo. Sendo soberano, você pode mudar quantas vezes quiser, claro.

Eu, por exemplo, atualmente me chamo "Klaus Wuestefeld".


Segunda Liberdade: Apelidos
-------------------------------

Você deve ser livre para chamar seus amigos do que bem entender.

Se você tiver um dentista chamado "Fernando dos Santos" e um primo também com o mesmo nome, você pode dar a um o apelido de "Dentista", por exemplo, e ao outro o apelido de "Nando".

Perceba que, para você, o Nando agora se chama "Nando" e não "fernando dos santos tudo junto arroba rótimeiou ponto com".

A secretária do seu dentista, para você, passa a ser simplesmente "Dentista -> Secretária", e não mais "ana ponto claudia 2004 arroba terra ponto com ponto bê erre".

Dessa forma, conseguimos libertar-nos da ilusão de que precisa haver um único esquema absoluto de endereçamento.

Quando caímos nessa falácia, estamos, na verdade, adotando e nos subordinando a um esquema que alguém inventou e, com isso, abdicando de nossa soberania. Os endereços IP como "200.181.15.26" e nomes de domínio como "prevayler.org" são exemplos disso.

Você sabe quem manda na distribuição desses endereços? Se não sabe, talvez de forma sutil, mas está deixando alguém que nem conhece ter domínio sobre você.

O mesmo se aplica a um país inteiro que, vergonhosamente, se subordina a um esquema gringo desses.

"É proibido, então, usar endereços IP ou nomes de domínio?"

Claro que não. Sendo soberanos, podemos usar o que quisermos.

Se, além de "Mãe -> Site", você quiser continuar chamando o site da sua mãe também de "agá tê tê pê dois pontos barra barra dáblio dáblio dáblio ponto provedor ponto com ponto bê erre barra til fulanadetal", tudo bem.

Você só deixará de ser soberano, se for incapaz de usar o seu próprio esquema de endereçamento, quando bem entender.

Para ser soberano, portanto, você vai usar um esquema RELATIVO de endereçamento, tendo a si próprio como ponto de origem. "Você -> Dentista -> Secretária", é um exemplo de caminho RELATIVO, partindo de você. "A cunhada do meu tio" é outro exemplo.

[Eu usei setinhas (->) para indicar o caminho, mas você pode usar o que quiser, claro. Se não pudesse, não seria soberano.]

Einstein mostrou que, até no mundo físico, absolutismo e objetividade são meras ilusões. Estamos simplesmente nos dando conta de que o mesmo se aplica ao mundo virtual.


Terceira Liberdade: Confiança
---------------------------------

Voce deve ser livre para confiar em quem você quiser.

Qualquer um consegue ser soberano sozinho, isolado numa ilha, mas isso não tem a menor graça. A coisa começa a pegar e, ao mesmo tempo, começa a ficar interessante, quando você interage com outras pessoas.

O que determina a intensidade de suas interações com outras pessoas é o grau da confiança que você tem em cada uma delas.

Qual é o endereço do site do seu banco?

Esse endereço vai apontar para o que seu provedor de internet quiser. Seu provedor de internet pode te enganar, fazendo-se passar por qualquer site não seguro da internet.

Em conchavo com alguma da empresas "donas da verdade" como a Verisign ou a Certisign, qualquer provedor de internet do mundo poderia fazer-se passar por qualquer site, de qualquer organização, incluindo sites seguros (com cadeadinho), como o site do seu banco.

Tá, mas por que os provedores de internet não fazem isso? Por que a Verisign não faz isso? Por que devo confiar neles?

"Ora, porque a maioria das pessoas confia."

A maioria do povo alemão confiou em Hitler e o resto da história já conhecemos. E o povo alemão ainda conhecia o sujeito. Dos internautas que sabem o que significa o tal "cadeadinho", apenas uma fração sequer ouviu falar em Verisign, Certisign e curriola.

Para ser soberano, portanto, você pode simplesmente parar de confiar em quem não conhece. Você pode simplesmente mandar seu provedor de internet e as "donas da verdade" catar coquinho.

Agora, se você confia no seu irmão e ele disser que confia no cunhado dele, sua tendência, por causa da indicação, é passar a confiar um pouco no tal cunhado, não é?

Podemos representar confiabilidade como uma porcentagem, onde 0% seria confiabilidade nenhuma e 100% seria confiabilidade total.

Se você disser que confia 70% em seu irmão e ele disser que confia 50% no cunhado dele, por exemplo, você pode considerar uma confiabilidade de 35% (70% x 50%) para o cunhado do seu irmão.

Perceba que, dessa forma, a confiança que você tem em alguém vai sempre diminuindo à medida que as relações vão se distanciando, exatamente como na vida real.

E, também como na vida real, você pode confiar mais ou menos em determinada pessoa, dependendo do assunto. Você pode confiar 70% no seu irmão, quando o assunto é futebol. No quesito "Música", por outro lado, a confiabilidade do seu irmão, para você, pode ser só de 1%, devido ao deplorável gosto musical dele.

"Quais são os quesitos que posso usar?"

Você não está entendendo. Sendo soberano, você é livre para usar os quesitos que quiser e, se não quiser quesito nenhum, tudo bem também.

"Para que serve saber que o cunhado do meu irmão tem uma confiabilidade de 35% e que o tio da namorada do vizinho do papagaio do dentista do meu avô tem, para mim, confiabilidade de 0,06%?"

Vamos usar isso para assegurar nossa quarta liberdade.


Quarta Liberdade: Privacidade
---------------------------------

A privacidade tem dois aspectos:

Você deve ser livre para ver somente aquilo que quer ver e;
Você deve ser livre para manter informações ocultadas de pessoas em quem você não confia.

Esse segundo aspecto do sigilo é óbvio. Seguem, então, alguns exemplos do primeiro aspecto.

Sempre que fizer uma busca por uma página, música, filme ou qualquer recurso que seja, você pode ordenar os resultados por ordem de confiabilidade, deixando as tranqueiras lá pro final.

Sendo soberano, você pode decidir que quer ser interrompido por mensagens urgentes de quem tiver mais de 60% de confiabilidade, mas que todas as mensagens de remetentes com menos de 1% de confiabilidade vão direto pro lixo.

Sendo soberano, você pode dizer adeus aos spammers.


Quinta Liberdade - Expressão
--------------------------------

Você deve ser livre para se expressar.

Depender de um hospedeiro de sites ou de blogs não é ser livre. Estar limitado a esse tipo ridículo de veículo também está longe de ser livre.

Além disso, deve ser extremamente fácil para seus amigos, para as pessoas que confiam em você, ouvir sua voz, saber da sua opinião a respeito dos assuntos que lhes interessam.

Gosto musical é um exemplo bem prosaico disso.

Quais são as dez melhores músicas de todos os tempos?
Quais são as dez piores músicas?
Quais são as dez melhores músicas de fossa?
Quais são as dez músicas que mais teimam em sair da cabeça?
Quais são as dez melhores músicas para se cantar no chuveiro?

Tenho certeza que você estaria interessado na opinião de seus amigos, assim como muitos estariam interessados na sua opinião, neste tipo de assunto.

Imagine que você dê notas para aquelas que são, na sua opinião, as dez melhores músicas para se ouvir transando.

Enquanto a média das suas notas é oito, você percebe que as notas de uma amiga sua, muito mais exigente que você, é quatro. Para efeito de comparação, você resolve multiplicar por dois as notas dela, para que fiquem na mesma escala que as suas.

Você percebe, ainda, que outro amigo seu mantém duas listas: as dez melhores para se ouvir transando em casa e as dez melhores para se ouvir transando no carro. Isso é frescura demais pra você, então você simplesmente junta as duas listas numa só e pega as dez primeiras músicas.

Você, agora, pode publicar uma síntese das suas melhores músicas junto com as de seus amigos, na mesma classificação e na mesma escala.

Perceba que SÍNTESE, portanto, também é uma forma de expressão.

Ela é justamente a força que equilibra o caos criado por milhões de partes soberanas, publicando uma infinidade de informações da forma como bem entendem. Você tem acesso a essas informações não diretamente, se não quiser, mas através de sínteses; e sínteses feitas pelas pessoas nas quais você mais confia para cada assunto.


Sexta Liberdade - Hardware
------------------------------

Você deve ser livre para compartilhar seus recursos de hardware como bem entender.

Pela primeira vez na vida, a capacidade da minha HD superou minha capacidade de instalar programas e armazenar arquivos lá dentro. Pela primeira vez, tenho espaço sobrando, e são algumas dezenas de Gigas.

Mesmo assim, sou obrigado a ficar fazendo backup de meus arquivos, incluindo minhas fotos digitais, para não correr o risco de perdê-los. A minha mãe se encontra exatamente na mesma situação.

Depois de procurar por horas, não encontrei solução alguma que me permitisse criar, através da internet, de forma completamente transparente, no espaço vago da minha HD, uma réplica dos arquivos da minha mãe e vice-versa.

Talvez até exista tal solução, mas certamente não é de uso comum.

Para sermos verdadeiramente soberanos, devemos ser capazes de nos associar livremente e compartilhar o espaço de nossas HDs. O mesmo se aplica à nossa memória RAM, nossos processadores e nossos links de internet.

Com isso, podemos dizer adeus aos hospedeiros de internet, tais quais os conhecemos hoje.

Se você, minha mãe e eu formarmos um cluster de 3 máquinas, teremos presenças na internet mais robustas e com maior disponibilidade que 99% dos sites comerciais de hoje, mesmo sem fazer backup.

E não precisa parar por aí. Quantos amigos você tem que possuem máquinas em casa com internet rápida? Federando-se a seus amigos soberanos, você pode estabelecer uma presença praticamente invulnerável na internet.

Mesmo que sua máquina seja desligada, sua presença virtual continuará viva e perfeitamente bem, hospedada nas máquinas das pessoas em quem você confia.


Sétima Liberdade - Software
-------------------------------------------

Você deve ser livre para compartilhar todo software que usa com quem você bem entender.

Para isso, usar Software Livre é indispensável, claro. As quatro liberdades definidas pela Free Software Foundation são, portanto, consideradas as liberdades 7.0, 7.1, 7.2 e 7.3 da computação soberana.

Mas usar software livre não é o suficiente. O software tem que ser extremamente fácil, trivial de instalar e de usar.

Recentemente, os produtos de Software Livre têm melhorado nisso, mas é um ponto que as principais definições de "Software Livre" ainda deixam de fora.

Quanto mais amigável de instalar e de usar for determinado software, maior o número de pessoas com as quais você será livre para compartilhá-lo.



Conclusão
=============

Mesmo recorrendo a todo o arsenal de Software Livre à minha disposição, sem antes passar meses programando, nem eu, que cresci em meio a computadores, sou capaz de compartilhar informação e recursos de hardware com meus amigos de forma completamente livre.

Isso é ridículo.

Alguns amigos e eu estamos desenvolvendo aplicativos que, além de serem livres, tornam trivial a qualquer pessoa alcançar soberania de computação.

"Por que vocês estão fazendo isso?"

Porque podemos. Somos programadores. É praticamente nosso dever terminar de vez com a palhaçada que é, hoje, usar a internet.

Além disso, um mundo de pessoas independentes e soberanas vai ser muito mais interessante que hordas e hordas de internautas passivos e embotados.

"Mas é necessário ser programador para ajudar?"

Não. De nada adianta um software se ninguém souber dele e se ninguém usá-lo. Para usar o que estamos desenvolvendo, basta querer ser livre, verdadeiramente livre.



Final da Estória
=================

Neide está feliz porque, tirando o site dela do GeoCities, além de poder usar conteúdo dinâmico, ela vai finalmente conseguir sumir com aquela maldita propaganda que aparecia em seu site.

Ela vai poder usar programação de verdade, que começou a aprender no ano passado, e criar seu próprio serviço soberano. Outras pessoas, quem sabe, podem até vir a copiá-lo e instalá-lo em suas próprias máquinas.

Ela sai do telecentro, rumo ao trabalho da irmã, de cabeça erguida, sorrindo. Ela saltita.

Pode ser que ela não seja ninguém no mundo real, mas ela sabe que, pelo menos no mundo virtual, ela tem futuro.

Ela é alguém.

Klaus Wuestefeld
(Publicado originalmente no MundoOO em 26/08/2004)

Uso de Termos e Abreviações do Latim

Alguns termos e abreviações do Latim são usados com frequência ao se escrever um texto científico
ou técnico. Os mais comuns estão relacionados em seguida.

• ca. – circa (em torno, aproximadamente)
• cf. – confer (compare)
• e.g. – exempli gratia (por examplo)
• et al. – et alii, et aliae, et alia (e outros)
• etc. – et cetera (e outras coisas, assim por diante)
• et seq. – et sequientes (e o que segue)
• f.v. – folio verso (no verso da página)
• ibid. – ibidem (no mesmo lugar)
• id. – idem (o mesmo)
• i.e. – id est (isto é)
• inf. – infra (abaixo)
• loc. cit. – loco citato (no lugar citado)
• n.b. – nota bene (note bem)
• op. cit. – opere citato (no trabalho citado)
• Q.E.D. – quod erat demonstrandum (o qual era para ser provado)
• q.v. – quod vide (o qual ver, uma referência a outra parte de um trabalho publicado)
• [sic] – sic (assim, da forma como está escrito)
• sup. – supra (acima)
• s.v. – sub verbo, sub voce (sob a palavra)
• ut sup. – ut supra (como acima)
• v. ou vs. – versus (invertido, contra)
• viz. – videlicet (como chamado)

Jon Anderson & Milton Nascimento - Soon - Amor Real

Dica do amigo: http://www.umserpensante.com/

Service Desk

Objetivo

Oferecer um ponto único de contato para os Clientes quando necessitam de apoio técnico, ajuda ou fazer consultas relacionadas com a Infra-estrutura de TI.

Tomar as ações necessárias para manter a Infra-estrutura de TI em produção dentro da normalidade reduzindo ao mínimo qualquer impacto sobre o negócio do Cliente.

Monitorar o cumprimento dos acordos de nível de serviços firmados entre os fornecedores de serviços de TI e o Cliente garantindo o processo de escalação.

Tipos de Service Desk

Existem diferentes tipos de Service Desk os mais comuns são:

Call Center: Um centro para receber e encaminhar incidentes para outras áreas, não executam outras atividades.

Service Desk Básico: Recebe e encaminha os incidentes para outras áreas, acompanha passo a passo as ações tomadas, informa o cliente sobre a situação do incidente

Service Desk Intermediário: Recebe e resolve parte dos incidentes, encaminha os incidentes não resolvidas para outras áreas, acompanha passo a passo as ações tomadas, informa o cliente sobre a situação do incidente.

Service Desk Avançado ou Especializado: incorpora partes do Gerenciamento de Incidentes e Problemas, resolve a maior parte dos incidentes.

Atividades

O Service Desk executa a primeiro nível de apoio para os Serviços de TI

Exceto o Call Center, todos os tipos de Service Desk executam as seguintes atividades:

• Recebe Telefonemas, faxes, e-mails, etc., sobre incidentes;
• Registra todos os incidentes (incluindo Requisições para Mudança);
• Classifica os Incidentes;
• Prioriza os incidentes;
• Escala os Incidentes;
• Procura por uma Solução de Contorno;
• Acompanha o Incidente;
• Atualiza o Cliente e o Grupo de TI sobre o progresso do Incidente;
• Realiza atividades de comunicação para outros processos;
• Verifica o Banco de dados da Configuração diariamente;
• Envia relatórios gerenciais sobre a desempenho do Service Desk para os Gerentes e Clientes.

Exemplo de como o Service Desk manuseia um incidente:

Benefícios

Os benefícios colhidos com a implementação de um SD podem ser a Melhoria:

• da Satisfação e da percepção do Cliente;
• da comunicação e informação através de um único ponto de contato;
• da qualidade e rapidez do atendimento das requisições do Cliente;
• do trabalho em equipe e a comunicação;
• do uso dos recursos da TI;
• do aumento da produtividade do pessoal de negócio;
• do controle e gerenciamento da infra-estrutura;
• da informação de apoio às decisões;
• e a redução de impactos negativos sobre o negócio.

Um benefício chave de um SD é o fornecimento de informação gerencial como:

• O uso de recursos pela equipe;
• As deficiências do serviço;
• As metas alcançadas;
• O desempenho do serviço;
• As necessidades de treinamento do Cliente.

E para terminar

Segue abaixo os tópicos essenciais para implementar e manter um Service desk:

• Entender as necessidades do Negócio;
• Entender os requisitos do Cliente;
• Fornecer os recursos para treinar os Clientes, equipes de apoio e a equipe do SD;
• Definir de forma clara os objetivos e os serviços que devem ser entregues;
• Rever os Acordos de Nível de Serviço.

Os custos com a implantação do SD estão associados com:

• Pessoal: Salários, treinamento, encargos, benefícios, etc.;
• Infra-estrutura: Salas, mobiliário, hardware, software, meios de comunicação, ferramentas, manutenção, etc;
• Procedimentos: Consultoria externa, et;
• O Cliente: Treinamento.

Rush - YYZ

Rush - Tom Sawyer

Gerenciamento de projetos - Reino Perdido Parte

Filme "A Meta". 01

Teoria das Restrições

Bad Moon Rising - The Traveling Band

Se alguém não quiser trabalhar, então não coma também

Introdução

          Estamos vivendo uma grande revolução tecnológica e global. A tendência é criar cada vez mais uma crescente relação de dependência entre os países formando grandes aldeias globais ou comunidades. São notáveis as transformações ocorridas em todos os segmentos sociais em virtude da globalização, que para facilitar a integração entre os países criam Zonas de Livre Comércio, União Aduaneiras, Mercado Comum e até mesmo, comunidades.
          Devido as constantes transformações e integrações surge a necessidade da evolução tecnológica para facilitar os meios de comunicação entre as sociedades. Atualmente, as empresas tem cada vez mais a necessidade de se adaptar e responder rapidamente as mudanças de mercado por uma questão de sobrevivência. Essa necessidade aumenta a demanda por meios cada vez mais rápidos e fáceis de a comunicação trafegar.
          Quanto maior a demanda pela velocidade de informação, tanto maior a exposição das pessoas as esses meios. Sabendo que é natural que as empresas busquem a otimização da utilização de seus recursos visando maximizar seu resultado e por conseqüência se manter no mercado, inicia-se um grande conflito: “Um funcionário deve ou não ter direito a privacidade em relação à utilização dos meios eletrônicos disponibilizados pela empresa onde trabalha?”. Até que ponto uma empresa pode invadir a privacidade dos seus funcionários?

Justificativa

          Ao contratar um funcionário, uma empresa está confiando nele todas as informações que esta possui em relação ao cargo que o cidadão irá atuar dentro da empresa. Da mesma forma, o funcionário estabelece um contrato de comum acordo onde ele se responsabiliza pela garantia do sigilo de tais informações bem como do uso da estrutura da empresa para o crescimento desta numa relação profissional e comercial.
          Assim, efetivamente não deveria ser considerada uma quebra de sigilo a abertura de emails de funcionários por parte da empresa, pois afinal a informação foi gerada na empresa, com a infraestrutura desta e com fins destinados à própria empresa. Ou seja, a informação contida nos emails pertence em última instância à empresa e não ao funcionário em si. Além disso, controle e monitoramento dos dados trafegados pelos funcionários podem ser de uma exigência legal (como no caso de combate a pedofilia). Vamos analisar que não existe uma resposta única e seguir a idéia do velho “cada caso é um caso”.

Desenvolvimento

          Uma empresa por definição é um conjunto de pessoas trabalhando juntas para atingir um objetivo em comum que seria difícil ou impossível de se atingir sozinho. Como um conjunto de pessoas, essa esta sujeita a todas as nuances do comportamento condicionado humano. A empresa por ser a dona dos recursos tende a monitorá-los e controlá-los. As pessoas, por outro lado, tendem a utilizá-los não somente para o trabalho, mas para o uso pessoal. Neste cenário surge o conflito.
          Empresas nos geral seguem o modelo fordista de trabalho, mesmo nos dias de hoje, e costumam tratar as pessoas como incapazes de tomar suas decisões e de ter suas próprias idéias. No mundo real (fora da empresa) as pessoas tem que sobreviver, isso acarreta uma série de decisões e novas idéias para que isso seja possível, contudo as empresas ainda insistem em criar um ambiente contrário para as pessoas enquanto essas estão no papel de funcionário, salvo algumas exceções.
          Como a situação atual exige informação (consumo e geração da mesma) controlá-la e monitorá-la tem um custo, que no geral não é pequeno. Controle de acesso de páginas, utilização de email, acesso de arquivos, acesso de documentos, etc. E por dados históricos, quanto mais você inibir o acesso ao recurso (no caso informação), mais as pessoas vão procurar alternativas para obtê-las, o que ocasionalmente tem um custo também.
          Em resumo: de um lado temos a empresa (que é representado por uma ou mais pessoas também), detentora dos recursos, que tem a obrigação de maximizar a utilização dos mesmos, contudo trata as pessoas como crianças monitorando e controlando suas ações. Do outro lado temos as pessoas, que fornecem suas informações para vários sites de relacionamento (que usam as informações obviamente), mas que ficam incomodadas ao saber que a empresa que lhes paga para trabalhar monitora e controla o acesso de suas informações dentro do ambiente.
          Neste ponto chega à pergunta: Qual seria a melhor alternativa? E como sempre a resposta: Depende, cada caso é um caso. Mas citando a Judith Mair: “Chega de Oba-Oba”. A empresa é criada pra fornecer um serviço, ponto. O funcionário é contratado para ajudar nesse serviço, ponto. Criemos então alguns indicadores que deixem claro o seguinte: "se alguém não quiser trabalhar, então não coma também".

Conclusão

          A discussão de a empresa tem ou não o direito de monitorar e controlar as informações de um funcionário é antiga, apenas adaptada à situação atual. Não existem soluções magias e nem a melhor solução. Monitorar, controlar, criar políticas, regras, leis e qualquer outra bobagem apenas geram mais problemas. A palavra de ordem é: consientização.

Referências bibliográficas

COSTA, José Eduardo. Big Brother corporativo. Você S.A. São Paulo, n. 84, jun. 2005.
CALVO, Adriana Carrera. O uso indevido do correio eletrônico no ambiente de trabalho. Disponível em: . Acesso em: 12 jul. 2005.
DANEMBERG, Roberta. Qual o limite da privacidade do empregado? Revista Consultor Jurídico, [S.l.], 16 maio 2005.

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.