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.

He-man com traços realistas

Uma ferramenta que pode ajudá-lo a tomar melhores decisões

O que existe em comum entre a escolha da composição da ração de aves para abate, a definição da agenda de trabalho de médicos e enfermeiras num hospital, a escolha do local de construção de um centro de distribuição de produtos e a determinação dos padrões de corte de chapas numa indústria de embalagens?

Estes e muitos outros problemas práticos podem ser resolvidos por meio de técnicas de Pesquisa Operacional, uma ciência multidisciplinar que integra conhecimentos da Matemática, Estatística e Computação para a criação de ferramentas de tomada de decisão.

As raízes da Pesquisa Operacional estão na Segunda Guerra Mundial, quando os comandos militares britânicos e americanos reuniram cientistas para criar métodos de alocação de recursos escassos, como aviões, radares e submarinos, para um grande número de alvos e operações militares (daí o nome "Operacional"). Com o crescimento econômico pós-guerra, os métodos e ferramentas desenvolvidos passaram a ser aplicados nos ramos comercial, industrial e governamental, em que os recursos a serem alocados eram matérias-primas, pessoas, máquinas, etc.

Método

A partir da definição do problema a ser resolvido, os analistas de Pesquisa Operacional desenvolvem modelos dos sistemas em questão, com os quais se possa prever e comparar o resultado de alternativas de decisão e estratégias de controle. A figura 1 ilustra, de forma simplificada, as principais fases de um estudo de Pesquisa Operacional.

Na prática, um projeto de Pesquisa Operacional nem sempre é feito na forma sequencial mostrada na figura 1. Os resultados preliminares, por exemplo, podem evidenciar inconsistências no modelo, levando a uma redefinição da formulação inicial. Ainda assim, as etapas mostradas na figura 1 podem ser utilizadas na aplicação de qualquer ferramenta das duas grandes áreas da Pesquisa Operacional: a Otimização e a Simulação.

Otimização

Otimização é o processo de busca pela melhor solução de um problema que possua várias (ou infinitas) soluções possíveis. Por exemplo, considere o caso de uma empresa que produza latas de metal com chapas de aço que podem ser estampadas em n padrões diferentes (semelhantes aos três mostrados na figura 2).

A modelagem desse problema de corte, como a de qualquer problema de otimização, depende da definição de três itens: variáveis de decisão, que representam as grandezas que podem ser controladas no problema, uma função objetivo que determine a qualidade da solução obtida e restrições, que estabelecem limitações impostas às variáveis de decisão. Para o exemplo anterior, as variáveis de decisão poderiam ser:

pi = quantidade de chapas estampadas no padrão i (i = 1, 2, ..., n)

x = quantidade de latas produzidas (e vendidas)

Conhecidas as quantidades de tampas e corpos gerados pelo padrão Ti (respectivamente, Ti e Ci), o preço unitário de venda das latas (L) e a disponibilidade (D) de chapas, pode-se escrever o seguinte modelo de otimização:

x, pi : números inteiros e maiores ou iguais a zero (i = 1, 2, ..., n)

Esse modelo pode ser resolvido por softwares como o Risk Solver Platform, da Frontline Systems, que funcionam agregados a planilhas eletrônicas. O uso de planilhas facilita a visualização dos dados de entrada (parâmetros) e saída (valores das variáveis de decisão e função objetivo) do modelo, a análise dos resultados e, eventualmente, a validação do modelo.

Simulação

A maioria dos modelos de otimização não consegue capturar a natureza aleatória e dinâmica de algumas classes de problemas reais. Nesses casos, é mais adequado construir modelos computacionais de simulação, em que as entidades e operações do sistema são representadas de forma gráfica.

SERVICE DESK

A Service Desk is a functional unit made up of a dedicated number of staff responsible for dealing with a variety of service events, often made via telephone calls, web interface, or automatically reported infrastructure events.
The Service Desk is a vitally important part of an organization’s IT Department and should be the single point of contact for IT users on a day-by-day basis – and will handle all incidents and service requests, usually
using specialist software tools to log and manage all such events.

The value of an effective Service Desk should not be underrated – a good Service Desk can often compensate

for deficiencies elsewhere in the IT organization, but a poor Service Desk (or the lack of a Service Desk) can give a poor impression of an otherwise very effective IT organization!

Aperfeiçoamento Profissional

O processo de aperfeiçoamento profissional implica reflexão, diagnóstico, eliminação de deficiências, caminhos alternativos, estímulo, auto-estima, avaliação... Para alguns de nós, professores, o aperfeiçoamento pode implicar maior clareza do que é o processo de construção/reconstrução de conhecimento, refinamento de nosso desempenho, adensamento de conhecimentos...

Individualismo

A prática do individualismo reduz as relações de lealdade e aprofunda os problemas de comunicação, prejudicando a possibilidade de consenso quanto a objetivos e processos de trabalho. Dessa forma, cada um explora sua racionalidade individual como se fosse a melhor e a mais útil para a coletividade organizacional.Em suas ações diárias, deixa de reconhecer a importância da dimensão coletiva para o progresso decisório.

A Fantástica Prisão do Aqui e Agora

As vezes, as pessoas se distanciam excessivamente, dos problemas agudos da realidade para se restrigirem a uma percepção alegre e tranquila da vida, situada no futuro, repleta de sonhos concretizados.

Visão

A visão é a construção de uma alternativa para a empresa – o lugar para onde a organização pretende-se dirigir é o futuro que desejamos criar, combinando as melhores informações a projeções, predições, suposições e sonhos de uma equipe.

O processo de decisão estratégica

Ainda hoje, na maioria das organizações, o processo de decisão estratégica se concentra no topo. Argumentos lógicos e sentimentos são compartilhados apenas entre dirigentes e assessores de alto nível. Para os demais funcionários, usa-se um processo de disseminação, menos participativo, mais informativo e catequizador.

Apresentando uma verdade construída e tecnicamente melhor, disponibilizam-se poucas chances de argumentação em contrário. Estabelecidos os ideais, espera-se adesão e comprometimento. Pelo fato de a decisão ter sido definida no topo, passa-se, implicitamente, a mensagem de que aqueles que ocupam postos de hierarquia mais baixa não têm perspectivas, autoridade ou sabedoria para argumentar.

No cotidiano decisório mais típico, não se procura consenso em todos os níveis hierárquicos, até porque ele seria desnecessário.

Defesa do TCC do MBA

9 Princípios de Inovação da Google

1 - Inovação, não perfeição instantânea:

Lançar idéias rápida e freqüentemente é mais importante do que ficar tentando atingir o produto/serviço perfeito para depois lançá-lo. O feedback dos usuários/clientes irá aprimorar melhor a idéia e a resposta deles irá indicar os projetos mais promissores.

2 - Compartilhe tudo que você puder:

Pequenas equipe que se comunicam abertamente tem trazido grandes resultados para o Google. Eles acreditam em transparência no ambiente de trabalho e de forma que todos saibam em que projetos os colegas estão trabalhando. Eles têm um software onde podem procurar um nome e ver em que projeto esta pessoa está trabalhando e acompanhar o andamento do trabalho. Se eles tiverem alguma idéia sabem com quem podem falar.

3 - Se você é brilhante nós estamos contratando:

Há sempre vagas para os mais brilhantes no Google. Eles preferem os generalistas, que podem contribuir de diferentes formas em diferentes projetos do que os especialistas.

4 - Deixe seus funcionários perseguirem seus sonhos:

O Google trabalho no modelo 70/20/10. O desenvolvimento dos programas atuais e de novas funcionalidades ocupa 70% do tempo. Novos projetos da empresa ocupam 20% do tempo e os outros 10% são usados pelos colaboradores em seus projetos pessoais. Assim surgiu o Orkut e o Google Earth.

5 - Idéias vêm de toda parte:

Algumas vezes o Google vai buscar suas idéias fora de casa. O Google Mastheads surgiu da contribuição de não-empregados, um deles uma menina de 13 anos.

6 - Dados e não opiniões:

Tome suas decisões com base em fatos e não em opiniões. Com tantas idéias no ar, procure basear suas decisões em informações e não em suposições.

7 - Criatividade adora restrições:

“Deixe as pessoas explorarem, mas estabeleça limites claros para estas explorações”. Caldeirões de idéias tendem a explodir se ninguém controla a temperatura.

8 - Procure usuários e ofereça usabilidade - o dinheiro vai atrás:

Em outras palavras, faça o que os clientes querem e precisam, e não o que eventualmente venda mais e melhor. Assim você manterá a liderança inovadora.

9 - Não mate idéias, modifique-as:

O Google não joga idéias fora. Modifica e transforma as idéias em algo util para a empresa.

O Modelo M/M/c: População Infinita

Grandes Paradoxos da Vida

Sempre te incentivaram a estudar e ser o melhor, só não te falaram que quando isso acontecesse, você não seria mais bem-vindo...

Pesquisa Operacional

A Pesquisa Operacional (PO) é uma ciência aplicada cujo objetivo é a melhoria da performance em organizações, ou seja, em sistemas produtivos usuários de recursos materiais, financeiros, humanos e ambientais (os chamados "meios de produção"). Ela trabalha através da formulação de modelos matemáticos a serem resolvidos com o auxílio de computadores, sendo feita em seguida a análise e a implementação das soluções obtidas.

Dessa forma, a técnica é precedida pela modelagem e seus resultados são sujeitos à análise de sensibilidade. A modelagem tem muito de arte e exige o desenvolvimento de uma capacidade (em grande parte não lógica) de interação com o problema, seus agentes e seu meio ambiente. O modelo matemático, que é uma simplificação, dificilmente pode levar em conta muitos aspectos não qualificáveis que aparecem no exame do problema e por isso a análise de sensibilidade deve ser realizada para avaliar o seu significado e a sua influência. Enfim, a implementação da decisão reata o contato com a realidade do problema e com o meio no qual ele se encontra inserido.

O campo de atuação da PO se estende da produção de matérias-primas e bens de consumo ao setor de serviços e às aplicações de interesse social como as relacionadas à saúde, à educação e à psico-sociologia, no que concerne a modelos organizacionais e descritivos. Esta multiplicidade de aplicações aponta para a necessidade de se evitar a estreiteza da especialização, o que levou a Área a adotar uma orientação metodológica, facultando a seus alunos, tanto como a seus docentes/pesquisadores, uma ampla gama de oportunidades em termos de novos problemas. Esta orientação foi adotada no trabalho didático associado à formação de mestres, resultando daí uma formação bastante eclética que procura abranger os diversos aspectos do mercado de trabalho no que se refere ao instrumental teórico.

A PO tem sido grandemente empregada em organizações governamentais (federais, estaduais e municipais), militares e de utilidade pública (como escolas, sindicatos, hospitais e bibliotecas). Torna-se cada vez mais comum seu emprego em áreas das mais variadas. A seguir alguns dos problemas que têm sido resolvidos por técnicas particulares da PO:

- PROGRAMAÇÃO LINEAR: tem sido usada com sucesso na solução de problemas relativos à alocação de pessoal, mistura de materiais, distribuição, transporte, carteira de investimento.

- TEORIA DAS FILAS: tem tido aplicação na solução de problemas relativos a congestionamento de tráfego, máquinas de serviços sujeitas a quebra, determinação do nível de uma força de serviço, programação do tráfego aéreo, projetos de represas, programação de produção e operação de hospitais.

- SIMULAÇÃO: tem sido aplicada também com sucesso a áreas como programação de produção, transportes, negócios, comunicações, bancos, escritórios, supermercados, redes de computadores, etc.

Outras técnicas de pesquisa operacional, tais como teoria de estoque, teoria dos jogos e programação dinâmica, também têm sido aplicadas com sucesso a diversos contextos.

Roda Viva com Noam Chomsky (1996)

Decisões

“Amigos, há apenas duas coisas na vida que vocês tem que fazer. Vocês têm que morrer e fazer escolhas.  Dessas não há como escapar”

James C. Hunter, O Monge e o Executivo, Ed. Sextante, 13a Edição, 2004.

Modelos Analíticos e de Simulação

Prever o desempenho de um sistema, entender seu comportamento, observar prováveis falhas e erros, analisar o melhor caminho de sucesso do sistema, simular proposições e ambientes de sistemas e encontrar soluções exatas ou muito aproximadas para o sistema desejado. Tudo isso pode ser feito usando Modelos Analíticos e de Simulação.

Modelos Analíticos
Analíticos são como fórmulas, mostram exatamente ou muito aproximadamente, como se comporta o sistema analisado. Observe na Figura 1 obtida em.

Modelos de Simulação
Simulação são procedimentos ou algoritmos que vão mostrar numa escala de tempo como vai se comportar o sistema, desde o início ao fim da simulação.
Um programa que vai calcular os avanços até terminar o teste incrementalmente.

Níveis de Detalhamento dos Modelos Analíticos e de Simulação

Modelo de Desempenho ao Nível de Sistema
O nível de explicitação sobre o sistema é baixo, modelado como uma “caixa preta”. É analisado como um conjunto de componentes realizando a analise do funcionamento geral sem alto rigor de detalhes por componentes. Realiza analise dos componentes simultaneamente.

Modelo de Desempenho ao Nível de Componentes
Considera diferentes recursos do sistema e o modo como as requisições usam os diferentes componentes. Discos e redes são considerados pelo modelo, mais preciso sobre o sistema e mais lento lidando com os recursos representando-os como uma fila. 

Trabalho – fonte de insegurança e estresse

Não é de se estranhar que, no trabalho, haja ansiedade. Em meio a relações amistosas e cooperativas, convivemos com conflitos e rivalidades. Em vez de oferecer somente segurança, regularidade de renda e tranquilidade, o trabalho também é fonte de insegurança, estresse e ansiedade.
Trabalho é desigualdade, competição e hierarquia. As diferenças individuais se mostram mais claramente, as comparações entre as habilidades e as competências das pessoas se acentuam.
Há pressões de desempenho e metas desafiadoras.
A hierarquia limita a iniciativa e pressiona para a conformidade.
Ademais, o trabalho moderno tornou-se mais individualizado, o que incentivou a competição. A cada momento, torna-se mais difícil reviver o espírito de equipe e de relações solidárias.

Outras frequencias

Seria mais fácil fazer como todo mundo faz.
O caminho mais curto, produto que rende mais.
Seria mais fácil fazer como todo mundo faz.
Um tiro certeiro, modelo que vende mais.

Mas nós dançamos no silêncio,
choramos no carnaval.
Não vemos graça nas gracinhas da TV,
morremos de rir no horário eleitoral.
 
Seria mais fácil fazer como todo mundo faz,
sem sair do sofá, deixar a Ferrari pra trás.
Seria mais fácil, como todo mundo faz.
O milésimo gol sentado na mesa de um bar.

Mas nós vibramos em outra frequência,
sabemos que não é bem assim.
Se fosse fácil achar o caminho das pedras,
tantas pedras no caminho não seria ruim

AHP

http://www.123ahp.com/

O cachorro e a carne

Um cachorro, que carregava na boca um pedaço de carne, ao cruzar uma ponte sobre um riacho, vê sua imagem refletida na água. Diante disso, ele logo imagina que se trata de outro cachorro, com um pedaço de carne maior que o seu.
Então, ele deixa cair no riacho o pedaço que carrega, e ferozmente se lança sobre o animal refletido na água, para tomar a porção de carne que julga ser maior que a sua.

Agindo assim ele perdeu a ambos. Aquele que tentou pegar na água, por se tratar de um simples reflexo, e o seu próprio, uma vez que ao largá-lo nas águas, a correnteza levou para longe.

Autor: Esopo

Moral da História:
É um tolo e duas vezes imprudente, aquele que desiste do certo pelo duvidoso.

STATUS QUO (whatever you want live)

Aposto que você não sabia que a música era dessa banda!

Decisões

Embora pareçam corretas, as decisões em grupo não são, necessáriamente, as melhores.

Crenças

As pessoas agem para confirmar e perpetuar as próprias crenças.

Decisão

As pessoas não se libertam de decisões passadas porque, consciente ou inconscientemente, não querem reconhecer que cometeram um erro.

Um dos principais desafios das organizações está na sua capacidade de fazer escolhas certas e consistentes, de modo alinhado com seu direcionamento estratégico. Provavelmente, um dos maiores desafios intelectuais da ciência e tecnologia está em como tomar decisões certas, dada uma situação específica (TRIANTAPHYLLOU, 2002).

Múltiplos Critérios

O problema de decisões racionais é que quase sempre temos múltiplos critérios para tomar uma decisão

    - Pense na compra de um carro
          - Custo (Uno Mille?)
          - Estética (Dodge Viper)
          - Conforto (Cadillac?)
          - Utilidade (Dobló?)
          - Segurança (Hummer?)

Isto é "tomada de decisão com múltiplos critérios"

    - Multi-criteria decision making
    - Multi-objective decision making
    - Multi-atribute decision making

O problema é que os critérios são frequentemente conflitantes, neste caso temos tradeoffs. Dificilmente chegamos a uma solução ótima.

Another RIA Framework

https://vaadin.com/

A Difícil Arte de Simplificar

Textos Científicos são escritos numa linguagem de difícil compreensão para o grande público. Torna-se necessário simplificá-los tornando-os mais acessíveis. Observem abaixo os estágios desta SIMPLIFICAÇÃO:

TEXTO ORIGINAL:

O dissacarídeo de fórmula C12H22O11, obtido através da fervura e da evaporação de H2O do líquido resultante da prensagem do caule da gramínea Saccharus officinarum (Linnaeus), isento de qualquer outro tipo de processamento suplementar que elimine suas impurezas, quando apresentado sob a forma geométrica de sólidos de reduzidas dimensões e arestas retilíneas, configurando pirâmides truncadas de base oblonga e pequena altura, uma vez submetido a um toque no órgão do paladar de quem se disponha a um teste  organoléptico, impressiona favoravelmente as papilas gustativas, sugerindo impressão sensorial equivalente provocada pelo mesmo dissacarídeo em estado bruto que ocorre no líquido nutritivo da alta viscosidade, produzindo nos órgãos especiais existentes na Apis mellifira (Linnaeus). No entanto, é possível comprovar experimentalmente que esse dissacarídeo, no estado físico-químico descrito e apresentado sob aquela forma geométrica, apresenta considerável resistência a modificar apreciavelmente suas dimensões quando submetido a tensões mecânicas de compressão ao longo do seu eixo em conseqüência da pequena deformidade que lhe é peculiar.

 * PRIMEIRO ESTÁGIO DA SIMPLIFICAÇÃO:

A sacarose extraída da cana de açúcar, que ainda não tenha passado pelo processo de purificação e refino, apresentando-se sob a forma de pequenos sólidos tronco-piramidais de base retangular, impressiona agradavelmente o paladar, lembrando a sensação provocada pela mesma sacarose produzida pelas abelhas em um peculiar líquido espesso e nutritivo. Entretanto, não altera suas dimensões lineares ou suas proporções quando submetida a uma tensão axial em conseqüência da aplicação de compressões equivalentes e opostas.

* SEGUNDO ESTÁGIO DA SIMPLIFICAÇÃO:

O açúcar, quando ainda não submetido à refinação e, apresentando-se em blocos sólidos de pequenas dimensões e forma tronco-piramidal, tem sabor deleitável da secreção alimentar das abelhas; todavia não muda suas proporções quando sujeito à compressão.

* TERCEIRO ESTÁGIO DA SIMPLIFICAÇÃO:

Açúcar não refinado, sob a forma de pequenos blocos, tem o sabor agradável do mel, porém não muda de forma quando pressionado.

* QUARTO ESTÁGIO DA SIMPLIFICAÇÃO:

Açúcar mascavo em tijolinhos tem o sabor adocicado, mas não é macio ou flexível.

 * ESTÁGIO FINAL DA SIMPLIFICAÇÃO:

Rapadura é doce, mas não é mole, não.

(Não sei que é o autor.)